如何处理EventBridge规则目标Lambda重试耗尽后的自动重处理？

方案1：EventBridge死信队列+重处理Lambda #

• 给你的EventBridge Cron规则配置死信队列（选SQS或者SNS都行），当Lambda自带的所有重试耗尽后，原事件会自动投递到这个队列里。
• 新建一个Lambda函数，把它设为SQS的触发器——这个函数的逻辑很简单：读取队列里的原事件，直接调用目标Lambda进行重处理。
• 给SQS配置合理的参数：比如可见性超时设为目标Lambda的超时时间再加几分钟缓冲，最大接收次数设为你需要的重跑次数，超过次数的消息可以转到存档队列或者触发告警。

方案2：用Step Functions编排全流程 #

• 放弃直接用EventBridge触发Lambda，转而创建一个Step Functions状态机，把Lambda的执行、重试逻辑都编排进去。
• 在状态机里加错误处理分支：如果Lambda执行失败，针对可重试的错误（比如网络超时）设置指数退避的重试策略；如果自定义重试次数也耗尽了，就把事件丢去SQS兜底，或者直接触发重处理流程。
• 让EventBridge的Cron规则触发这个状态机，整个流程可视化，调整重试逻辑也更灵活。

方案3：Lambda内部写队列做本地重试 #

• 在目标Lambda里加判断逻辑：如果处理失败（且是可重试的错误），就把原请求体写入一个SQS队列（注意要做幂等，别重复写同一条事件）。
• 同样建一个监听这个SQS的Lambda，负责读取消息并重新调用目标Lambda。
• 这种方式适合需要在函数内部精准控制失败场景的情况，比如只对特定错误码的请求重跑。

• 必须做幂等：Lambda一定要设计成幂等的，重跑同一事件不能产生副作用，比如重复写入数据库、重复调用收费API。
• 错误分类处理：区分可重试错误（临时网络问题、资源占满）和不可重试错误（参数错误、数据格式不对），只重跑前者，后者直接存档告警。
• 加监控告警：给死信队列、Step Functions、SQS配CloudWatch告警，一旦消息堆积或者重跑次数超标，立刻通知运维查问题。
• 合理配置重试策略：用指数退避的重试间隔，避免短时间内大量重试压垮系统；同时设置最大重试次数，防止无限循环。
• 失败事件存档：多次重跑还失败的事件，要存到S3或者DynamoDB里留底，方便后续排查，别直接丢了。

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