Lambda故障超24小时时，如何避免DynamoDB Stream记录永久丢失？

一、直接给Lambda加重试和DLQ解决不了你的核心问题 #

Lambda处理DynamoDB Stream的逻辑和SQS完全不一样，自带的重试机制是基于流的检查点，不是SQS那种消息确认模式：

• 当Lambda执行失败，它会在重试窗口（默认6小时，可调至最长6小时，最多10000次重试）内反复拉取同一批事件重试。
• 如果重试窗口内还是没成功，Lambda会放弃这批事件，但它们只会留在DDB Stream里直到24小时到期，不会自动转到DLQ。

所以你参照SQS思路加的DLQ，根本接不到超时未处理的流事件，没法防止24小时后的丢失。

二、DDB Stream和SQS的核心行为差异 #

• 数据留存：DDB Stream最多存24小时；SQS标准队列默认4天（最长14天），FIFO队列最长14天。
• 消费逻辑：
  • DDB Stream是分片消费，Lambda跟踪每个分片的检查点，只有成功处理完一批事件才会推进检查点，失败就从上次检查点重拉。
  • SQS是单条/批量消息确认，消费后必须主动确认，未确认的消息会重回队列，超过重试次数就进DLQ。
• 重试规则：
  • DDB Stream的Lambda重试有时间上限（最长6小时），超时后事件留在流里等过期，不会进DLQ。
  • SQS的重试可以通过可见性超时、重试次数配置，超阈值的消息自动转DLQ。

三、避免DDB Stream事件永久丢失的可行方案 #

要解决Lambda故障超24小时丢事件的问题，得从数据持久化或中转入手：

1. 用Kinesis Data Firehose中转
   把DDB Stream的数据转发到Firehose，Firehose会自动把数据持久化到S3（或其他存储），同时可以配置Lambda处理。就算Lambda长期故障，数据先存在S3，之后随时能批量重新处理。
2. 自定义消费+提前备份
   不用Lambda直接消费流，改用EC2、ECS或者Lambda自己拉取流数据，处理前先把事件备份到S3或SQS。处理失败的话，直接从备份里恢复重试。
3. 拉满Lambda重试窗口+监控告警
   把Lambda的MaximumEventAgeInSeconds设到最大值21600秒（6小时），MaximumRetryAttempts设到10000次，同时配CloudWatch告警，一旦Lambda失败次数飙升立刻通知，确保在24小时内修复故障，不让事件过期。

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