业务访问量开始不稳定时，AWS Auto Scaling 通常是 EC2 架构里最先要补上的能力。它能根据负载自动增加或减少实例，避免高峰期机器不够用，也减少低峰期空跑资源。配置不难，难点在于：扩多少、什么时候扩、扩完怎么接入流量，以及预算怎么控。
这篇文章按实际落地顺序讲 AWS Auto Scaling 怎么配置。你可以用它检查现有架构，也可以作为新业务上线前的扩容清单。
什么时候该用 AWS Auto Scaling？
如果你的业务流量稳定，比如内部系统每天固定几十人访问，手动扩容也能应付。真正适合 Auto Scaling 的场景，是访问量有波动，而且波动会影响用户体验。
常见情况有几类。电商活动、内容平台推荐、游戏开服、API 服务突发调用，都会让 CPU、请求数或连接数在短时间内升高。只靠人工盯监控再加机器，很容易慢半拍。另一种情况是海外业务，用户分布在不同时区，白天和夜间负载差异明显。一直按峰值买 EC2，成本会被拉高。
判断是否需要自动伸缩，可以看两个信号：负载是否经常接近瓶颈，业务是否允许提前扩容或自动扩容。 如果两者都满足，就值得配置 Auto Scaling Group。
Auto Scaling 的核心不是“自动加机器”，而是保持容量
很多人第一次接触 AWS Auto Scaling，会把它理解成“CPU 高了就加一台”。这只是其中一种结果。它真正做的是维持一组 EC2 实例的目标容量。
在 EC2 Auto Scaling 里，你会设置三个容量值：最小容量、期望容量、最大容量。最小容量保证服务底线，期望容量是当前希望运行的实例数量，最大容量用来防止无限扩容。扩容策略触发后，期望容量会增加；缩容触发后，期望容量会减少，但不会低于最小容量。
这三个值要认真定。最小容量太低，单台实例故障时可能影响服务；最大容量太高，策略写错会带来额外成本。刚上线的业务可以保守一点，把最大容量限制在你能接受的预算范围内，再根据监控慢慢调整。
配置前先准备这几件事
Auto Scaling 不是单独工作的。它通常和启动模板、负载均衡、CloudWatch 指标一起使用。动手前，先把这几个基础项理清。
第一是 AMI 和启动配置。你要确认新拉起的 EC2 实例能自动进入可服务状态。代码、运行环境、启动脚本、日志采集、配置文件，都要提前处理好。否则扩容出来的实例虽然是“Running”，但业务并不能用。
第二是网络和安全组。Auto Scaling Group 会把实例放进你指定的 VPC 子网。生产环境建议分布在多个可用区，提高可用性。安全组要允许负载均衡器或上游服务访问应用端口，不要为了省事开放过大的入站范围。
第三是负载均衡。Web 服务通常会配合 Application Load Balancer 使用。这样新实例启动后，可以注册到目标组，等健康检查通过后再接流量。没有负载均衡时，Auto Scaling 也能加机器，但流量分发要你自己处理，运维复杂度会高很多。
如果你还在确认实例规格、区域和计费方式，可以先看站内的云服务器选型思路，把基础资源定稳，再配置自动伸缩。
AWS Auto Scaling 怎么配置？按这个顺序做更稳
下面以 EC2 Auto Scaling 为例。AWS 控制台界面可能会调整，具体名称和入口以 AWS 官方最新说明为准，但整体步骤基本一致。
1. 创建启动模板
打开 EC2 控制台，找到启动模板相关入口，创建一个新的 Launch Template。这里决定了扩容出来的 EC2 长什么样。
你需要确认这些内容：
- AMI：选择已经验证过的系统镜像，最好包含基础运行环境。
- 实例类型：按业务负载选择，例如计算型、通用型或内存型实例。
- 密钥对：用于必要时登录排查，不建议依赖人工登录完成部署。
- 安全组：只开放业务需要的端口。
- 用户数据：如果需要自动拉代码、启动服务，可以写入初始化脚本。
启动模板不要只在测试环境跑通一次就直接上生产。更稳的做法是先用它手动创建一台 EC2，确认应用能启动、日志正常、健康检查能通过，再交给 Auto Scaling Group 使用。
2. 创建 Auto Scaling Group
进入 EC2 Auto Scaling Groups，选择刚才的启动模板。接下来要选 VPC、子网和可用区。生产业务建议至少选择多个可用区内的子网，避免所有实例集中在一个位置。
容量设置要贴近业务现实。比如新业务刚上线，可以先设置较低的最小容量和期望容量，再给最大容量留出增长空间。已有业务迁移到 Auto Scaling 时，期望容量可以参考当前线上实例数量，不要一次改得太激进。
如果你的服务要通过负载均衡访问，就把 Auto Scaling Group 关联到对应的 Target Group。这样扩容出来的新实例会自动注册，健康检查通过后才会接收请求。
3. 设置健康检查
健康检查决定实例是否算“可用”。EC2 状态检查只能判断底层实例是否正常，不能判断你的应用是否真的能响应请求。Web 服务更常用负载均衡器健康检查，比如访问某个健康检查路径，返回正常状态码后再放入流量池。
健康检查路径要轻量，不要访问数据库重查询，也不要依赖复杂外部服务。它的目的不是测试全部业务链路，而是判断实例是否能稳定接流量。
健康检查宽限期也要设置合理。应用启动慢时，如果宽限期太短，Auto Scaling 可能误判实例不健康，然后反复替换实例。Java 应用、容器初始化较慢的服务，尤其要留意这一点。
4. 选择扩缩容策略
扩缩容策略有多种。实际项目里，最常用的是目标跟踪扩缩容。你设一个目标值，比如平均 CPU 利用率维持在某个区间，Auto Scaling 会根据指标自动调整容量。具体指标和阈值要结合业务压测结果，不建议照搬别人的数字。
如果你的流量有固定规律，比如每天晚上八点访问量明显上升，可以用计划扩缩容。它适合已知高峰，能在高峰来之前先加机器，避免等指标升高后才扩容。
步进扩缩容适合更精细的控制。比如负载略高时加少量实例，负载很高时加更多实例。它更灵活，也更容易配置复杂。没有足够监控数据前，不建议一开始就写得太细。
如果你是新业务，优先用目标跟踪策略；如果你有固定活动时间，配合计划扩容会更稳；如果流量变化很剧烈，再考虑步进策略。
5. 验证扩容和缩容结果
配置完成后，不要等真实高峰来验证。可以在测试环境或低风险时间段做压测，观察 CloudWatch 指标、Auto Scaling 活动记录、负载均衡目标组状态。
重点看三个结果：新实例是否按预期启动，是否顺利加入 Target Group，压力下降后是否能缩容。扩容只成功一半不算完成。很多问题出在启动脚本、健康检查、安全组或应用启动时间上。
缩容也要单独检查。实例被移出时，连接是否能平滑结束，任务是否会中断，日志是否已经采集。对于处理队列任务、长连接或有本地状态的应用，缩容前要设计好退出逻辑。
扩容指标怎么选？别只盯 CPU
CPU 是最容易想到的指标，但它不一定代表真实压力。计算密集型服务看 CPU 没问题，可很多 Web 应用瓶颈在连接数、请求延迟、数据库连接池或下游接口。
如果你的服务在 ALB 后面，可以关注每个目标的请求数、响应时间和健康目标数量。API 服务可以结合错误率和延迟判断是否需要扩容。队列消费类服务则更适合看队列积压长度或消费延迟，这类指标通常需要接入 CloudWatch 自定义指标。
指标选择的原则很简单：它要能提前反映服务变慢，而不是等用户已经大量报错才触发。阈值要来自压测或线上观察。没有数据时，先保守配置，再按监控调整。
成本怎么控？最大容量和缩容策略要一起看
Auto Scaling 能帮你减少低峰空跑，但它不会自动帮你省钱。策略配置不当，也可能让实例数量长时间维持在高位。
控制成本先看最大容量。最大容量不是技术上能扩到多少，而是预算上允许扩到多少。活动前可以临时调高，活动后再恢复。生产环境最好有人负责复核这个值，避免测试策略留在线上。
再看缩容。缩容太快，负载稍微下降就删机器，下一波请求又要扩容，服务会来回抖动。缩容太慢，资源会多跑很久。可以结合实例预热时间、冷却时间和业务波峰间隔来调。
EC2 的购买方式也会影响成本。稳定基础容量可以评估更长期的计费选择，突发容量再用按需实例承接。具体适合哪种方式，要看业务稳定性、预算周期和账户情况，价格与折扣以咨询和 AWS 官方最新说明为准。需要核算账单时，也可以结合站内的成本优化方案做一轮梳理。
常见配置坑，很多都出在上线前没验证
Auto Scaling 最怕“看起来配置好了”。控制台里资源都创建成功，不代表生产高峰就没问题。
启动模板版本是一个常见坑。你更新了 AMI 或用户数据，但 Auto Scaling Group 仍然使用旧版本模板，新扩容出来的实例就不会包含新配置。每次变更后，要确认 ASG 使用的是正确版本。
健康检查也容易误判。路径写错、端口不通、应用启动慢，都会让实例一直被替换。遇到这种情况，不要只看 EC2 状态，要同时看 Target Group 的健康状态和应用日志。
还有一种情况是实例扩出来了，但流量没有进来。原因可能是没有绑定目标组、安全组不允许 ALB 访问、子网路由不通，或应用监听地址配置错误。排查时按链路走：负载均衡器、目标组、实例安全组、应用端口。
账户和充值要提前准备，别卡在扩容当天
Auto Scaling 会根据策略创建更多 EC2 实例。账户权限、付款方式、服务配额和账单状态都可能影响扩容结果。企业在做活动前，最好提前检查账户是否能正常创建所需资源，相关配额是否满足预期。
对于没有国际信用卡，或希望统一处理 AWS 国际站账户注册、充值和账单支持的团队，可以通过进化云处理账号注册与代充值。我们提供 AWS 账户注册、代充值、折扣申请和技术支持服务；具体到账时间、折扣和费用以咨询为准。这样做的重点不是替代你的架构设计，而是减少账户和付款环节对上线节奏的影响。
如果你已经有 AWS 账户，也建议在配置 Auto Scaling 前确认 IAM 权限。负责运维的人至少要能管理 EC2、Auto Scaling、Launch Template、Load Balancer 和 CloudWatch 相关资源。权限不完整时，配置到一半会很浪费时间。
一套更稳的落地顺序
从业务增长到弹性扩容，建议按这个顺序推进：
- 先确认业务瓶颈，是 CPU、请求数、延迟，还是队列积压。
- 准备可重复启动的 AMI 或启动脚本，确保新实例不靠人工配置。
- 配好负载均衡和健康检查，让新实例自动接入流量。
- 创建 Auto Scaling Group，设置合理的最小、期望和最大容量。
- 选择扩缩容策略，新业务先用目标跟踪更容易维护。
- 做压测和故障演练，确认扩容、缩容、实例替换都能按预期运行。
- 上线后持续观察 CloudWatch 指标，再调整阈值和容量范围。
这套流程看起来多一步，但能减少很多线上问题。Auto Scaling 的价值，不在于把机器数量变多，而是在访问量变化时，让服务和成本都保持在可控范围内。
FAQ
AWS Auto Scaling 和 EC2 Auto Scaling 是一回事吗？
日常说的 AWS Auto Scaling 可能指多种自动扩缩容能力。本文主要讲 EC2 Auto Scaling，也就是通过 Auto Scaling Group 自动管理 EC2 实例数量。
AWS Auto Scaling 一定要配负载均衡吗？
不是必须。但 Web 服务通常建议配合 ALB 或其他负载均衡使用，这样新实例通过健康检查后再接收流量，整体更稳。
Auto Scaling 会不会让账单突然变高？
有可能。它会按策略增加实例。如果最大容量设置过高，或者缩容策略不合理，成本会增加。建议设置预算可接受的最大容量，并持续看账单和监控。
没有国际信用卡可以用 AWS Auto Scaling 吗？
技术上 Auto Scaling 是 AWS 的云服务能力，关键是账户和付款方式要正常。没有国际信用卡的团队，可以咨询进化云的 AWS 国际站账户注册与代充值服务，具体流程和费用以咨询为准。
如果你准备给现有 EC2 服务接入 Auto Scaling，下一步可以先整理当前实例规格、峰值指标、可接受预算和账户状态。资料齐全后，再决定启动模板、容量范围和扩缩容策略，会比直接在控制台里试错更稳。
