如何减少ECS任务失败反复重启触发的重复SNS告警

ECS任务启动失败后触发无限重启、每次重启都推送告警的问题，有三类落地成本从低到高的方案，可根据实际场景选择：

方案1：EventBridge规则+SNS原生能力做粗粒度去重 #

无需新增额外资源，仅调整现有配置即可实现基础去重：

• 收紧EventBridge事件匹配规则，仅捕获真正需要告警的启动失败事件，过滤无效事件，参考匹配规则如下：

{
  "source": ["aws.ecs"],
  "detail-type": ["ECS Task State Change"],
  "detail": {
    "lastStatus": ["STOPPED"],
    "desiredStatus": ["STOPPED"],
    "stopCode": ["TaskFailedToStart"]
  }
}

上述规则会过滤掉正常停止、手动停止、运行中异常退出的非启动失败类事件，仅保留容器启动失败的场景。

• 将现有普通SNS主题替换为FIFO类型SNS主题，以事件中携带的任务ARN作为消息去重ID，设置5~15分钟的去重窗口，同一失败任务在窗口内重复触发的事件会被SNS自动丢弃，不会推送到Slack。
• 该方案优势是配置简单无额外成本，缺点是去重逻辑固定，无法自定义告警频次、升级告警等复杂规则。

方案2：新增Lambda中间层实现灵活去重逻辑 #

如果需要自定义判断逻辑、实现更精准的告警抑制，在EventBridge和SNS之间增加一层轻量Lambda即可，完全可以实现条件判断、循环去重类需求：

• 调整现有链路为：ECS事件 -> EventBridge规则 -> Lambda函数 -> SNS -> Slack
• Lambda核心处理逻辑：
  • 从事件中提取去重维度key：组合ECS集群名、服务名/任务定义名、失败原因作为唯一标识
  • 配置自定义静默窗口（比如10分钟、30分钟），判断该key在窗口内是否已经推送过告警：未推送则调用SNS发告警，同时记录该key的静默标记；已推送则直接丢弃事件不触发通知
  • 可扩展额外逻辑：统计同个失败原因在1小时内的重启次数，达到阈值时推送升级告警，提醒运维人员及时介入，避免漏报
• 该方案代码量极小，单请求运行时长通常在100ms以内，运行成本几乎可以忽略，是生产环境的主流实现方式。

方案3：调整ECS重启策略从根源减少无效事件 #

除了告警链路的调整，还可以直接修改ECS任务配置，减少无效重启的事件触发：

• 修改任务定义中的重启策略，将默认无限制重试（maximumRetryCount: -1）调整为有限次重试，比如设置为3次，达到重试上限后任务会彻底停止，不再循环触发事件，参考配置片段：

"restartPolicy": {
  "enabled": true,
  "maximumRetryCount": 3,
  "ignoredExitCodes": []
}

• 注意不要完全关闭重启策略，避免偶发故障导致业务完全不可用。

所有去重配置都需要留兜底机制：静默窗口到期后如果任务仍处于失败状态，需要重新触发告警，避免真实故障被长期抑制。

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