DynamoDB向SNS发送存量/新增数据低延迟方案咨询

1. Kinesis Data Streams（KDS）与DynamoDB Streams适配性结论 #

追求最低传输延迟的场景下，增量链路优先选DynamoDB Streams，不建议复用现有KDS作为主传输层，核心原因如下：

• 延迟表现差距明显：DynamoDB Streams是DynamoDB原生的变更捕获机制，表内的写入、更新、删除事件会在数据落盘后百毫秒级推送到流端，没有额外网络跳转；如果走KDS链路，你需要先把DynamoDB的变更自行写入KDS，再消费KDS发SNS，多了两次序列化/反序列化和网络传输，典型延迟会升到200ms~1s，不符合低延迟要求。
• 不存在哪个流天然覆盖存量历史数据：两个流服务都只会存储主动写入的增量数据，存量历史数据必须通过DynamoDB并行Scan单独迁移，和流选型无关。
  你现有KDS资源如果需要给其他下游系统提供数据，可以在处理逻辑里做异步双写，不要让到SNS的主链路绕经KDS增加延迟。

2. 流到SNS是否必须部署Lambda中转 #

不是强制要求，但Lambda是当前延迟、运维成本综合最优的选择，没有之一：

• DynamoDB Streams没有直接投递SNS的原生集成，可选的中转方案只有三类：自建KCL消费程序跑在EC2/ECS/EKS上、用EventBridge Pipes做转发、用Lambda做消费处理。
• 自建消费端需要自己维护扩缩容、版本升级、故障兜底，资源预留不足时的延迟波动远大于Lambda，运维成本极高；EventBridge Pipes的转发延迟比Lambda触发高50~150ms，不适合极致低延迟场景。
• Lambda只要配置得当，端到端从DynamoDB写入到SNS消息投递可以稳定在200ms以内，不需要自己维护服务器，是性价比最高的选择。

3. 故障处理最佳实践与DLQ配置 #

可以通过DLQ实现失败记录的重试与重驱动，这也是AWS官方推荐的标准方案，具体配置要避开新手常见坑：

• 重试逻辑分层配置：Lambda的DynamoDB Streams事件源映射默认自带指数退避重试，可配置最长24小时的重试窗口，覆盖网络抖动、服务临时限流这类偶发故障。
• DLQ一定要配置在事件源映射层面，不要只配Lambda函数自身的DLQ：流触发是事件源映射主动拉取记录调用Lambda，函数级DLQ只覆盖异步调用场景，配错位置会导致失败记录无法进入DLQ造成数据丢失。DLQ选标准SQS队列即可，超过最大重试次数的失败批次会自动投递到队列中。
• 坏消息隔离：代码层面要做格式校验，对解析失败、字段非法的确定性坏消息，不要触发整个批次重试避免卡住整个分片的消费进度，单独投递到专门的坏消息队列人工排查即可。
• DLQ运维配套：配置CloudWatch告警监控DLQ队列深度，有消息堆积时及时触发通知；需要重驱动时直接用Lambda原生的SQS重驱动功能即可，不需要自行编写脚本搬运消息。

新手架构优化建议 #

• 存量+增量同步不要混跑：先开启DynamoDB Streams捕获实时增量，记录开启时间点，再启动分段并行Scan扫存量数据，存量扫描时控制并发不要打满表的预置读容量，扫到的存量数据和流里的增量数据用同一套逻辑投递SNS，通过记录主键+时间戳去重，避免重复发消息，扫完存量后切到纯流处理增量即可，全程无数据丢失。
• Lambda配置压减延迟：选arm64架构，内存配置1024MB以上（该配置下CPU、网络性能性价比最高，执行耗时最短），开启预置并发消除冷启动尖刺，所有资源部署在同一区域，避免跨区调用增加延迟。
• 前置限流兜底：提前申请SNS主题的发布配额，避免业务突增时触发SNS限流导致投递失败。
• 核心监控必配：重点监控DynamoDB Streams的IteratorAge指标（直接反映流处理延迟，超过1秒必须告警）、Lambda错误率、DLQ队列深度、SNS发布失败数。

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