SNS redrive到Dead letter queue不工作 消息未送达DLQ问题排查

你遇到的问题核心是SNS订阅级死信队列的触发逻辑，与Lambda端点的异步调用重试是两套完全独立的机制，你观测到的3次重试属于Lambda侧行为，不会触发SNS侧的DLQ投递：

• SNS向作为订阅端点的Lambda投递消息时，只要Lambda服务成功接收异步调用请求（返回202 Accepted状态码），SNS就会判定本次投递完成，不再跟踪后续消息处理结果。
• 你日志里看到的3次执行（1次首次执行+2次重试），是Lambda异步调用的默认重试机制触发的，整个重试流程完全由Lambda服务管控，SNS感知不到这些执行失败，自然不会触发订阅上配置的重驱动策略往DLQ发消息。
• 你当前配置的SNS订阅DLQ，仅会在SNS侧无法完成投递时触发，比如Lambda函数被删除、SNS缺失Lambda调用权限、Lambda服务持续返回5xx错误等SNS根本无法把调用请求送达Lambda的场景。

你提到的官方示例使用SQS作为端点能正常工作，是因为SNS向SQS投递时，只有SQS明确返回接收成功响应，SNS才会判定投递完成，投递失败的重试、DLQ流转全由SNS侧管控，和Lambda端点的投递判定逻辑有本质区别。

如果需要收集Lambda处理SNS消息失败的死信，你需要配置Lambda函数自身的异步调用DLQ，而非SNS订阅的DLQ：

• 给目标SQS队列更新访问策略，新增允许lambda.amazonaws.com服务主体执行sqs:SendMessage的权限，同时添加条件校验源ARN为你的Lambda函数ARN，避免其他资源越权往队列发消息。
• 在Lambda函数的异步调用配置项中，将死信队列目标设置为你的SQS队列ARN。
• 你可以根据业务需求调整Lambda异步调用的重试次数，默认的2次重试（合计3次执行）规则支持自定义修改。

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