如何识别Lambda已从DynamoDB Streams处理过的TTL删除数据记录

DynamoDB Stream本身没有内置属性标识某条记录是否已被特定Lambda函数消费处理，你需要结合Stream自带的固有属性，自行实现消费状态的跟踪逻辑。

可直接利用的DynamoDB Stream原生属性 #

• 每条Stream记录都带唯一标识字段SequenceNumber：该值在单个分片中严格递增，加上分片ID后可作为全流唯一的记录ID
• TTL自动触发的删除记录可通过userIdentity字段过滤：只要Records[].userIdentity.type为Service，且Records[].userIdentity.principalId为dynamodb.amazonaws.com，即可确认该删除操作是TTL触发，而非人为/业务代码调用删除接口产生

识别已处理记录的两种实现方案 #

方案1：用Lambda事件源映射内置Checkpoint机制（仅需避免重复处理时优先选） #

如果是用AWS原生的Lambda DynamoDB Stream事件源映射，Lambda服务会默认在服务端维护消费 checkpoint，自动记录每个分片已成功消费到的序列号位置。只要Lambda函数返回处理成功，该批次的记录就不会被重复推送给函数，天然避免重复消费，不需要额外开发状态跟踪逻辑。

注意：该Checkpoint由Lambda服务内部维护，你无法直接查询某条特定记录是否已经被消费，仅能保证不会重复推送。

方案2：自建轻量状态表（需要主动查询已处理记录时选） #

如果你的业务需要明确查询某条TTL删除记录的处理状态，可以自建一个DynamoDB状态表，参考设计如下：

• 分区键：使用shard_id:SequenceNumber组合作为唯一键（解决SequenceNumber仅单分片唯一的问题）
• 可选属性：processed_timestamp（处理完成时间戳）、target_location（转发到的S3/Firehose路径标识）、original_item_key（原DynamoDB表的主键，方便关联业务数据）
• 配套TTL配置：状态表的TTL可以设为和你的DynamoDB Stream保留时长一致（最长24小时），自动清理过期的状态数据，避免存储浪费

处理逻辑：

1. Lambda收到Stream批次后，先过滤出TTL触发的删除记录
2. 处理每条记录前先查询状态表，若对应唯一键已存在直接跳过
3. 确认转发到S3/Firehose成功后，写入对应状态记录到状态表

成本评估补充（针对你提到的目标存储选型） #

• 数据量较大且无近实时处理需求时，直接转发到S3成本更低
• 如果后续需要对数据做清洗、转换、自动加载到数据仓库/数据湖，Kinesis Firehose的内置集成能力可以省掉自己写缓冲、重试的开发成本，整体TCO反而更低

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