AWS CloudWatch告警无法触发Auto Scaling Group扩容EC2实例故障

核心结论：告警持续显示Insufficient Data是扩缩容不触发的直接原因——告警没有拿到有效CPU监控数据，始终无法进入阈值突破状态，无论怎么修改缺失数据处理策略都不会触发扩缩容动作，按以下顺序排查即可：

1. 优先排查CloudWatch告警配置错误 #

这是该类问题最高发的原因：

• 核对告警的命名空间与维度：CPU利用率基础指标属于AWS/EC2命名空间，监控ASG维度的CPU时必须选择AutoScalingGroupName维度，值准确匹配你创建的ASG名称；不要误选不存在的实例ID、可用区等额外过滤维度，也不要选错到CloudWatch Agent的CWAgent自定义命名空间（除非你明确配置了Agent的CPU采集规则）。
• 核对告警的周期与统计方式：你配置的是连续60秒高于阈值触发，必须把告警周期设为1分钟，不能用默认的5分钟周期；统计方式选择Average，不要选SampleCount、Sum这类和CPU利用率不匹配的统计值。

2. 排查EC2实例的监控数据上报链路 #

回到EC2控制台，找到ASG中正在运行的实例，切换到监控标签页，查看是否能看到正常的CPU利用率曲线：

• 如果控制台监控页也看不到CPU数据：
  • 检查实例所在子网的网络连通性：私有子网必须配置NAT网关或者CloudWatch VPC端点（com.amazonaws.[你的可用区域].monitoring），实例绑定的安全组出站规则要放开443端口访问CloudWatch服务的权限，否则监控数据无法上报。
  • 检查实例绑定的IAM角色权限：基础监控需要实例具备上报监控数据的最小权限，不要给角色绑定显式拒绝cloudwatch:PutMetricData的自定义策略；如果是用CloudWatch Agent采集指标，需要给角色附加CloudWatchAgentServerPolicy托管策略。
• 如果控制台监控页能看到正常的CPU数据，仅告警页显示数据不足：回到告警配置页删除多余的过滤条件，确认指标匹配范围完全覆盖ASG下的运行实例即可。

3. 排查ASG侧的配置拦截 #

• 检查ASG的容量配置：确认ASG设置的最大实例数大于当前运行实例数，如果最大容量设为1，哪怕告警正常触发也不会新增实例。
• 核对扩缩容策略绑定关系：进入ASG的自动扩缩容策略页，确认策略绑定的告警ARN和你创建的CPU告警ARN完全一致，不要绑定到其他重名的无效告警上。
• 查看ASG活动历史：如果之前有触发扩缩容但启动实例失败，活动历史里会留下明确的报错（比如启动模板权限不足、可用区资源不足等），按报错修正配置即可。

快速验证方式 #

配置修正后不需要重复跑CPU压测脚本，直接在CloudWatch告警详情页选择「操作-测试告警操作」，手动将告警置为告警状态，如果ASG能正常触发新增实例的流程，说明ASG侧配置无问题，只需要等待监控数据正常上报即可自动触发。

内容的提问来源于stack exchange，提问作者rust1001