你的SQS+Lambda方案完全可行，但要注意几个关键细节避免踩坑：

一、批量导出ID到SQS的正确姿势 #

别一次性把100万条ID读到内存，用游标分页（别用skip，大数据量下效率极低）分批处理：

• 用DocumentDB的find({筛选条件}, {_id: 1})查询只返回ID字段，减少数据传输量
• 每次用limit(1000)拉取一批，用游标迭代，每批拆分成10条一组批量发送到SQS（SQS单批次最多支持10条消息）
• 这种方式不会把所有数据塞到内存，ECS任务的内存压力会大幅降低

二、Lambda处理环节的优化 #

• 用findOneAndDelete替代先读再删：这个操作能在一次数据库请求里完成读取文档和删除，减少DB请求次数，降低CPU消耗
• 控制Lambda并发：别让Lambda同时跑几百个实例打满DocumentDB的CPU，通过SQS的BatchSize（比如设为10）和Lambda的预留并发来限制并发数，根据DB的CPU负载动态调整
• 容错处理：给SQS配置死信队列，把删除/发EventBridge失败的消息转进去，后续手动排查处理，避免无限重试消耗资源

三、替代方案：ECS分批处理 #

如果不想引入SQS+Lambda的复杂度，也可以直接改造原有ECS任务：

• 用游标遍历目标文档，每次拉取500-1000条
• 对每批文档，逐个执行「读文档→发EventBridge→删文档」（或用findOneAndDelete一步完成读删）
• 处理完一批后，主动清理变量释放内存，再取下一批
• 这种方式不用新增服务，直接优化原有逻辑就能解决内存和CPU问题

监控建议 #

全程监控这几个指标：

• DocumentDB的CPU使用率、连接数
• SQS的消息堆积量（若用SQS方案）
• Lambda的执行错误率、并发数（若用Lambda方案）
• ECS任务的内存、CPU使用率

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