AWS于2026年11月10日宣布，Amazon CloudWatch使用PromQL的告警现可触发Amazon EC2和Application Auto Scaling的简单及分步扩缩容策略。采用OpenTelemetry指标的团队，可以让监控查询直接参与容量调整。
目标跟踪扩缩容策略目前不在这项支持范围内。迁移现有策略时，不能仅因为告警能够创建就假定所有策略类型都可触发。
新增动作覆盖哪些扩缩容策略
本次更新把PromQL告警与EC2 Auto Scaling和Application Auto Scaling动作连接起来，支持简单扩缩容及分步扩缩容。团队可用与看板和告警相同的PromQL指标观察负载，再把越过阈值的情况交给扩缩容策略处理。
先确认目标资源使用的是受支持的策略类型。已有目标跟踪策略需要另行评估，不能将其直接列入此次新增能力。
PromQL查询必须满足什么条件
AWS明确要求用于告警的查询返回单条时间序列，并与阈值比较。对于分步扩缩容，指标越过阈值的幅度决定应用哪一个步骤。返回多条时间序列的查询不能按此要求直接用作扩缩容告警。
上线前应核对标签聚合方式，确保查询结果确实收敛为一条可与阈值比较的序列，再检查每个分步区间的动作。
与OpenTelemetry指标如何配合
AWS将此能力定位于使用CloudWatch OpenTelemetry指标的EC2 Auto Scaling工作负载。运维人员可继续在看板中使用熟悉的PromQL表达式，减少为扩缩容另建传统指标告警的需求。
查询能用于图表不代表它满足告警动作要求。图表可以展示多条序列，扩缩容告警仍须遵守单序列与阈值限制。
可以通过哪些入口配置
创建或编辑CloudWatch告警时，可在控制台添加EC2 Auto Scaling或Application Auto Scaling动作；AWS也列出PutMetricAlarm API、AWS CLI、SDK及CloudFormation作为配置入口。功能在已提供CloudWatch PromQL告警的AWS区域可用，按标准CloudWatch告警价格计费。
正式启用前应核对所在区域的PromQL告警可用性，并检查告警动作指向的策略与资源。
上线时怎样控制误扩缩容风险
建议先记录当前指标、阈值和扩缩容活动，再用单条序列的PromQL查询创建告警，核对阈值越界后关联的简单或分步策略是否符合容量计划。需要关注冷却、业务峰值和指标异常对动作的影响。
验收标准应包含实际告警状态与目标策略动作的对应关系。只验证查询语法通过，不足以证明扩缩容链路完整。
