AWS账号购买 AWS 弹性伸缩策略设计教程：动态伸缩、定时伸缩与预测性伸缩怎么选与怎么配
用户搜索这个主题，通常不是想知道 Auto Scaling 是什么，而是在实际上线前遇到了几个直接影响成本和稳定性的问题：业务有固定高峰时，应该用定时伸缩还是动态伸缩；CPU 阈值设置多少才不会频繁扩缩容；预测性伸缩到底能不能用于电商、内容站或 API 服务；配置完成后为什么组容量不变化，或者实例已经扩容但流量没有切过去。下面的内容围绕这些实际问题展开，重点放在控制台操作、参数填写和故障排查。
先回答决策时最容易卡住的 4 个问题
1. 什么时候优先选动态伸缩
如果流量波动不固定、受活动投放或外部请求影响较大，优先使用动态伸缩。典型场景包括 API 服务、SaaS 控制台、Web 应用、爬虫入口服务。动态伸缩依赖 CloudWatch 指标，适合根据 CPUUtilization、RequestCountPerTarget、TargetResponseTime、内存或自定义业务指标实时调整容量。
2. 什么时候必须加定时伸缩
如果业务高峰时间可预测，例如每天 09:00 上班打卡高峰、20:00 内容分发高峰、每月结算日 00:00 批处理，单靠动态伸缩往往来不及。此时应在高峰前 10 到 30 分钟提前扩容，使用定时伸缩把最小实例数和期望实例数提前抬高，避免冷启动导致首波请求超时。
AWS账号购买 3. 预测性伸缩适合哪些业务
预测性伸缩更适合具有周期性规律的负载，例如稳定电商、资讯站点、教育直播预约页面、工作日固定峰值的企业系统。如果你的业务经常突然被社交媒体带爆，预测性伸缩不能替代动态伸缩，应作为提前预热容量的补充。
4. 三种策略会不会互相冲突
会，但可以设计得可控。常见做法是：定时伸缩负责“提前抬底座”，动态伸缩负责“跟随实时波动”，预测性伸缩负责“提前准备高峰容量”。不要让多个策略同时直接修改同一个极窄容量区间，否则容易出现扩完马上缩、缩完马上扩的抖动。
实施前需要准备什么
在进入控制台前，先确认下面这些前置项，否则后续策略看起来“配置成功”，但实际上不会生效。
| 准备项 | 要求 | 说明 |
| AWS 账号权限 | EC2、Auto Scaling、CloudWatch、IAM、ELB 权限 | 至少需要创建启动模板、ASG、告警和查看活动历史的权限 |
| 镜像与启动模板 | 已准备 AMI 或标准镜像 | 推荐先做启动模板，不直接用旧版启动配置 |
| 子网与可用区 | 至少 2 个可用区 | 避免单可用区容量不足或故障时无法扩容 |
| 负载均衡 | ALB/NLB 按业务准备 | Web/API 场景建议挂 ALB，并使用 Target Group 指标做伸缩 |
| 健康检查 | EC2 + ELB 健康检查 | 只用 EC2 健康检查会导致应用层异常不易剔除 |
| 监控指标 | CloudWatch 指标可见 | 如需内存指标，需安装 CloudWatch Agent |
建议先准备的基线参数
- 最小实例数 Min：至少满足低谷稳定运行，例如 2 台。
- 最大实例数 Max：根据预算和配额预留上限，例如 10 台或 20 台。
- 期望实例数 Desired：通常等于当前业务启动时所需容量，例如 2 或 3 台。
- 实例预热时间 Instance Warmup：Java、Node、PHP、Python 应用差异大，通常从 120 到 300 秒开始测试。
- 健康检查宽限期 Health Check Grace Period：应用启动慢时建议 180 到 300 秒。
AWS账号购买 控制台配置实操：先创建可用的 Auto Scaling Group
步骤1：创建启动模板
进入 AWS 控制台，打开 EC2，左侧点击“Launch Templates”，然后点击“Create launch template”。
重点参数建议如下：
| 参数 | 填写建议 | 注意事项 |
| AMI | 选已验证的 Linux 或 Windows 镜像 | 不要直接用临时测试镜像上线生产 |
| Instance type | Web 层可从 t3.medium、m6i.large 起步 | 突发型实例要注意 CPU 积分耗尽风险 |
| Key pair | Linux 选 SSH 密钥；Windows 用密码解密 | 批量扩容实例也要可登录排障 |
| Network settings | 安全组至少放通业务端口 | SSH 22、RDP 3389 建议限制来源 IP |
| User data | 写入初始化脚本 | 确保新实例启动后自动安装 Agent、拉取配置、注册服务 |
| IAM role | 挂载实例角色 | 拉取 SSM 参数、写日志到 CloudWatch 都依赖角色 |
如果是 Linux，建议在 User data 中完成应用初始化。例如安装 CloudWatch Agent、拉取配置文件、加入目标组前进行本地健康检查。Windows 实例则建议提前封装 AMI，避免每次扩容都做大量安装动作。
步骤2：创建 Auto Scaling Group
AWS账号购买 进入 EC2 控制台，点击“Auto Scaling Groups”后选择“Create Auto Scaling group”。选择刚创建的启动模板。
关键配置要点：
- 名称：按环境区分，例如 prod-web-asg。
- VPC 与子网：至少选择两个可用区子网，避免实例只能在单一区域扩容。
- Load balancing：如果是网站或 API，关联 ALB Target Group。
- Health checks：同时启用 EC2 和 ELB。
- Group size：先设置 Min=2、Desired=2、Max=6 作为初始值，后续再压测调整。
- Default instance warmup：建议 180 秒起步。
如果你已经知道应用启动需要 4 分钟才可接流量，就不要把预热时间设成 60 秒，否则动态伸缩会误判容量不足，继续扩容，形成过度扩容。
步骤3：配置动态伸缩
在 ASG 页面进入“Automatic scaling”，点击“Create dynamic scaling policy”。这里优先推荐两种方式：Target tracking 和 Step scaling。
Target tracking 适合大多数场景
选择“Target tracking scaling policy”，常见指标建议如下：
| 业务类型 | 推荐指标 | 目标值建议 |
| Web 网站 | ALB RequestCountPerTarget | 每目标每分钟 800-1500，根据压测定 |
| API 服务 | TargetResponseTime 或 CPU | 响应时间阈值优先，CPU 目标 45%-60% |
| 通用应用 | Average CPUUtilization | 先用 50%，再根据扩缩容频率微调 |
| 内存敏感服务 | 自定义内存指标 | 内存目标 60%-70% |
注意：如果服务瓶颈主要在连接数或响应时间，只看 CPU 很容易误判。很多用户扩容失败，不是 ASG 不工作，而是选错了伸缩指标。
Step scaling 用于明显分级的波动
如果业务流量常出现阶梯式增长，比如活动开始后 5 分钟内从 2 台打满到 6 台，可用 Step scaling。示例：
- CPU > 60% 持续 3 分钟：+1 台
- CPU > 75% 持续 3 分钟：+2 台
- CPU < 30% 持续 10 分钟：-1 台
缩容阈值要比扩容阈值更保守，并且观察时间要更长，这样可以降低抖动。
步骤4：配置定时伸缩
AWS账号购买 在 ASG 的“Automatic scaling”中选择“Create scheduled action”。
典型做法不是直接在高峰时扩容，而是在高峰前预热。
| 时间点 | 操作 | 示例 |
| 08:40 | 提高 Min 和 Desired | 从 2 调到 4 |
| 09:00-11:00 | 保留动态伸缩继续工作 | 峰值时可再扩到 6 |
| 11:30 | 降低 Min | 从 4 降回 2 |
参数填写时，注意时区问题。很多用户设置了 cron 后没有生效，实际原因是按 UTC 执行，而不是本地时间。跨境业务尤其要核对运行时区。
步骤5：配置预测性伸缩
在支持预测性伸缩的 ASG 配置页面，选择“Predictive scaling”。如果控制台中未显示，可检查当前区域、负载均衡集成方式和策略条件。
建议这样使用：
- 模式：先使用 Forecast only，先看预测曲线是否接近真实峰值。
- 观察周期：至少观察 7 到 14 天，再切换为 Forecast and scale。
- 最小容量边界：避免预测值把低谷容量压得过低。
- 与动态伸缩并用：预测负责提前准备，动态负责实时修正。
如果业务刚上线、历史数据不足，预测性伸缩参考价值有限，不建议一开始就完全依赖它。
三种策略怎么组合，才不容易出问题
组合方案一：内容站/企业门户
工作日白天流量稳定，晚上较低。建议：定时伸缩抬高白天底座，动态伸缩跟随热点文章突发流量，预测性伸缩可选。
| 策略 | 建议 |
| 定时伸缩 | 工作日 08:30 调整 Min=3，18:30 恢复 Min=2 |
| 动态伸缩 | ALB RequestCountPerTarget 目标跟踪 |
| 预测性伸缩 | 观察 2 周后决定是否启用 |
组合方案二：电商促销页
活动时间明确，但峰值陡增。建议：高峰前 30 分钟定时扩容，活动中使用 Step scaling，活动后延迟缩容。
这里最常见的错误是活动结束立即缩容，导致支付回调、订单查询、物流同步等尾流量被打爆。活动后至少保留 20 到 40 分钟缓冲。
组合方案三：API/微服务
如果请求量和响应时间直接相关，优先用 ALB TargetResponseTime 或自定义每实例请求数，不要只看 CPU。因为很多 IO 型服务 CPU 不高，但线程池、连接池已满，用户仍然会感觉服务“卡住”。
不同用户的配置建议
| 用户类型 | 推荐策略 | 实例建议 | 重点关注 |
| 个人开发者 | 动态伸缩为主 | Min 1，Max 2-3 | 控制成本，避免误扩容 |
| 企业用户 | 定时 + 动态 | Min 2，跨 2 AZ | 可用性与发布时间窗口 |
| 跨境业务 | 定时 + 动态 + 时区校验 | 按目标市场分区域部署 | 时区、延迟、区域容量 |
| 网站应用 | ALB 指标驱动 | 中小流量从 2-4 台起 | 目标组健康检查、会话保持 |
| 数据库业务前端 | 前端可扩，数据库单独限流 | 不要只扩应用层 | 避免扩容后数据库成为瓶颈 |
AWS账号购买 策略不生效时，优先检查这几项
AWS账号购买 1. 已触发告警，但实例没扩容
先看 ASG 的 Activity 页面。如果看到“max group size reached”，说明不是策略无效，而是 Max 太小。如果提示“launch failed”，继续看 EC2 启动失败原因，常见是子网无可用 IP、实例类型容量不足、配额不足、启动模板镜像权限异常。
2. 实例扩出来了，但流量没上去
重点看 Target Group 健康检查。很多新实例虽然创建成功，但应用没启动完成、端口没监听、Nginx/Apache/服务进程没拉起，导致目标组一直 unhealthy。解决方式是延长健康检查宽限期，并把应用初始化脚本做成幂等。
3. 频繁扩容又缩容
这是典型抖动。通常是阈值过近、冷却时间太短、指标选择不合适。处理方法：
- 扩容阈值与缩容阈值拉开。
- 缩容评估时间设得比扩容更长。
- 增加实例预热时间。
- 将 CPU 指标改为更贴近业务的请求量或响应时间指标。
4. 定时伸缩没有按预期执行
先检查 cron 时间表达式与时区，再看是否修改的是 Min、Max 还是 Desired。很多人只改了 Min，没有同步 Desired，导致当前实例数没有立刻变化。
5. 预测值看起来不准
先确认历史数据是否足够、业务是否具有明显周期性、节假日和活动流量是否与平日差异过大。预测性伸缩不能替代活动运营计划，活动前仍应手工或定时提高底座容量。
常见故障处理案例
案例：CPU 很低，但用户响应慢，ASG 不扩容
这是 API 服务里很常见的错误案例。应用瓶颈可能在数据库连接池或下游接口等待，CPU 只有 25%，但平均响应时间已从 200ms 升到 2s。解决方法不是继续盯 CPU，而是改用 ALB TargetResponseTime 或自定义业务指标触发扩容，同时检查数据库连接数上限。
后续优化建议
安全优化
- SSH 22 和 RDP 3389 不要对 0.0.0.0/0 开放，使用堡垒机、SSM Session Manager 或固定办公 IP。
- 安全组只开放必要业务端口，如 80、443、应用端口。
- 实例角色最小权限，避免扩容实例默认获得过大访问权。
性能优化
- Web 类服务优先用 ALB 请求数、响应时间等接近业务体验的指标。
- 实例启动慢时提前封装 AMI，减少每次扩容安装依赖的时间。
- 跨可用区部署时，关注会话状态、缓存一致性和数据库连接延迟。
成本优化
- 低谷时通过定时伸缩主动降低 Min，避免整夜保留高峰容量。
- 基础容量可评估 Savings Plans 或预留实例，高峰弹性容量用按需实例。
- 对可中断业务可考虑混合实例策略与 Spot，但前提是服务支持快速替换。
稳定性优化
- 最少跨两个可用区。
- 新版本发布前先验证新 AMI 或启动模板版本，避免扩容时批量拉起错误版本。
- 定期检查 ASG 活动历史、CloudWatch 告警、目标组健康状态和实例启动日志。
如果你的业务已经有明显的日周期，推荐的落地顺序通常是：先把启动模板、健康检查、日志和监控打通；再上动态伸缩；随后加定时伸缩解决高峰前预热；最后再评估预测性伸缩是否值得接入。这样能先解决最常见的容量跟不上和扩缩容抖动问题，而不是一开始就把策略堆满导致排障困难。
