你的CloudWatch告警配置核心问题出在滚动评估窗口逻辑以及DatapointsToAlarm和EvaluationPeriods的组合上，直接导致了告警恢复延迟和重复通知的问题，咱们一步步拆解：

为什么错误率下降后还持续收到邮件？ #

你的配置里：

• EvaluationPeriods: 20（评估最近20个周期，每个周期5分钟，总共100分钟）
• DatapointsToAlarm: 1（只要这20个周期里有1个数据点的5XX错误率≥10%，就触发告警）

CloudWatch告警的评估是基于滚动窗口的：当某个周期触发告警后，后续每5分钟的评估都会包含这个触发的周期数据，直到这个数据点被移出20个周期的窗口（也就是100分钟后）。在这之前，滚动窗口里始终存在至少1个满足阈值的数据点，所以告警会一直保持Alarm状态。

如果你的SNS Topic配置了在告警处于Alarm状态时重复发送通知，就会每5分钟收到一封邮件，直到滚动窗口完全脱离触发的那个周期。

为什么告警状态很快切回OK？ #

你看到的"3分钟后切回OK"大概率是单个最新数据点的状态，而非CloudWatch告警的整体状态。CloudWatch告警的状态是基于整个20个周期的滚动窗口判断的，不是单个数据点——哪怕最新的1-2个数据点恢复正常，只要窗口里还有之前触发的那个数据点，告警就会保持Alarm状态。

配置调整建议 #

针对你的需求（错误过多时收到通知，恢复后停止通知），可以调整以下参数：

1. 缩小评估窗口，平衡触发灵敏度和恢复速度 #

把EvaluationPeriods从20降到更小的数值，比如3或5，同时调整DatapointsToAlarm匹配你的需求：

• 如果你想快速触发，同时快速恢复：

  EvaluationPeriods: 3
  DatapointsToAlarm: 1
  

  这样评估窗口是15分钟，只要15分钟内有1个周期错误率超标就触发，当连续3个周期（15分钟）错误率都低于阈值时，告警切回OK，不会出现100分钟的延迟。

• 如果你想减少误报，需要连续多个周期超标才触发：

  EvaluationPeriods: 3
  DatapointsToAlarm: 3
  

  这样需要连续3个周期（15分钟）错误率都≥10%才触发，恢复也需要连续3个周期正常，能避免偶发的峰值误报。

2. 配置OK状态通知（可选） #

如果你想在告警恢复时收到通知，可以添加OKActions参数，指向同一个SNS Topic：

OKActions: "some SNS topic"

这样当告警从Alarm切回OK时，会收到恢复通知，明确知道问题已经解决。

3. 检查SNS Topic的通知设置 #

确认你的SNS Topic没有配置重复发送规则——默认情况下CloudWatch只会在状态转换时发送一次通知（OK→Alarm，Alarm→OK），如果每5分钟都收到邮件，可能是SNS的订阅设置了重复推送，或者告警状态在频繁切换（比如滚动窗口里一会儿有超标数据，一会儿没有）。

你可以在CloudWatch控制台的告警历史里查看状态变化记录，确认告警是否在Alarm和OK之间反复波动。

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