基于SQS消息数的CloudWatch扩缩容告警配置合理性咨询

关于“是否总有一个告警处于触发状态” #

从逻辑上说，SQS的可见消息数是非负整数——要么是0，要么≥1。如果两个告警基于同一个准确的消息数指标，那≥1和<1（即等于0）这两个条件确实互斥且覆盖所有可能，理论上总有一个告警会触发。

但你的配置里存在关键问题：两个告警用了不同的SQS指标：

• 扩容告警用的是ApproximateNumberOfMessagesVisible（SQS默认提供的近似可见消息数，完全能满足日常扩缩容需求）
• 缩容告警用的是ExactNumberOfMessagesVisible（这个指标需要额外开启SQS的精确指标功能才会生成，默认状态下不会上报数据）

如果没开启精确指标，缩容告警会一直处于INSUFFICIENT_DATA状态，根本无法触发；就算开启了，两个指标的统计逻辑不同，数值可能出现偏差，反而可能出现两个都不告警或者同时告警的异常情况。

这种状态是否正常？ #

如果是基于同一指标的正确配置，这种“总有一个告警触发”是逻辑上的必然，但从实际扩缩容需求来看，这种阈值设置非常不合理：

• 当消息数≥1时，扩容告警会持续触发，不断尝试把ECS任务数扩容到上限，这显然不符合实际场景——你应该设置一个更合理的扩容阈值（比如消息数≥5），避免少量消息就触发扩容；
• 当消息数为0时，缩容告警持续触发，会把任务数缩到最小，这部分逻辑合理，但同样建议设置多个评估周期（比如evaluation_periods = 2），避免瞬时消息清零就触发缩容。

额外优化建议 #

• 统一使用ApproximateNumberOfMessagesVisible指标，无需开启精确指标，足够满足扩缩容需求；
• 调整阈值：比如扩容阈值设为5，缩容阈值设为0，同时把evaluation_periods改成2或3，减少误触发；
• 给Auto Scaling Policy配置冷却时间（cooldown），防止短时间内反复扩缩容，浪费资源。

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