讲解 AWS EC2 Auto Scaling Group、启动模板、目标跟踪、容量范围、预热、健康检查和缩容排空。
EC2 Auto Scaling 通过 Auto Scaling Group 管理实例容量。完整方案至少包括启动模板、最小/期望/最大容量、子网、健康检查、伸缩策略、预热时间和缩容行为；只配置 CPU 告警并不能形成可靠弹性。
适合多数网站的起点：先在“EC2 → 启动模板”固化 AMI、实例类型、安全组和 IAM 角色，再进入“EC2 → Auto Scaling 组”创建跨两个可用区的伸缩组。把目标跟踪指标设为能代表真实瓶颈的 CPU 或负载均衡请求量，最小容量至少覆盖故障后仍需保留的实例数。Auto Scaling 组本身通常不收费，但新 EC2、EBS、负载均衡和监控会计费。
先让应用可以横向扩展
- 会话放到共享存储或由客户端携带；
- 上传文件不只保存在实例本地；
- 实例可由启动模板和 User Data 重建；
- 任务调度具备幂等与分布式锁；
- 实例终止前能停止接流并排空连接。
三组容量值
| 参数 | 含义 | 风险 |
|---|---|---|
| Minimum | 最低保有容量 | 太低无法承受故障或突发 |
| Desired | 当前目标容量 | 会被策略动态调整 |
| Maximum | 允许扩展上限 | 太低会阻止继续扩容 |
目标跟踪策略
选择随容量增加而下降的指标，例如平均 CPU 或 ALB 每目标请求数，并设置具有突发余量的目标值。多个目标跟踪策略同时存在时，AWS 倾向优先保障可用性：任一策略需要扩容即可扩容，而缩容通常要求相关策略都允许。
预热与健康检查
默认实例预热用于避免新实例尚未接流时的临时指标干扰伸缩。预热时间应覆盖系统启动、应用加载和健康检查；长初始化可结合生命周期钩子。ALB 健康检查与 EC2 状态检查的含义不同，应按业务选择。
缩容安全
缩容前确认注销延迟、生命周期钩子、任务与长连接处理。数据库、单机队列或持久文件未外置时，不应直接进入自动缩容。
验证方法
- 用受控负载触发扩容；
- 检查 Activity history 和失败原因；
- 验证新实例按时进入 InService 并接收请求；
- 降低负载观察缩容是否过早；
- 模拟单个可用区容量不足并核对替代规格策略。
创建启动模板前要清掉什么
启动模板不能包含临时登录凭据、固定主机名或只适用于旧实例的本地状态。AMI 必须先用独立实例验证，用户数据要可重复执行，安全组只开放负载均衡和运维来源。实例类型若可能缺货，可在组内配置多个兼容规格；ARM 与 x86 不能混用同一份不兼容镜像。
中文控制台创建伸缩组
- 进入“EC2 → 启动模板 → 创建启动模板”，选择已验收 AMI，并配置实例类型、密钥、网络、安全组和角色。
- 打开“Auto Scaling 组 → 创建 Auto Scaling 组”，选启动模板和版本。
- 选择 VPC，并至少选择两个可用区的私有子网；需要对外服务时关联现有负载均衡目标组。
- 设置最小、所需和最大容量。新系统先把最小值设为当前稳定容量，最大值按预算和下游承载力限制。
- 添加目标跟踪策略，选择平均 CPU 或 ALB 每目标请求数，并填写实例预热时间。
预热时间怎么定
预热应覆盖“实例启动、用户数据执行、应用启动、加入目标组并通过健康检查”的完整时间。默认可从实际部署记录的高分位耗时开始，而不是固定照抄 300 秒。设得过短会把尚未就绪的实例计入指标并连续扩容；设得过长会延迟下一次合理扩容。数据库迁移等一次性动作不要放进每台实例启动流程。
不扩容或反复扩缩的分支
- 活动历史显示容量限制：检查最大容量、服务配额和目标可用区的实例容量。
- 新实例立即不健康：检查目标组端口、健康检查路径、安全组和应用启动日志。
- CPU 很低但网站慢：瓶颈可能在数据库、EBS 或外部 API，改用更合适的指标，不能盲目降低目标值。
- 频繁扩缩：增加合理预热和缩容冷却，检查指标是否被定时任务或单个热点请求扰动。
验证与安全回退
把测试流量逐步提高，确认活动历史创建实例、目标组健康、应用会话和文件不依赖本机。再手动终止一台组内实例，验证系统能补回容量。修改策略前保存旧启动模板版本和三项容量值；异常时暂停动态扩缩，切回上一启动模板版本并把所需容量恢复到稳定值。不要在仍承载唯一数据副本时缩容。
上线前最后核对
确认伸缩组终止实例时不会删除唯一上传文件、会话或本地任务状态。上传文件应进入对象存储，共享会话进入外部存储，后台任务要有可重试的队列。再检查最大容量不会超过数据库连接数和预算上限；自动扩容只能增加计算节点，不能自动消除下游瓶颈。
联系 Telegram 客服 