并发AWS Lambda共享数据存储选型：DynamoDB与CloudWatch适用性咨询

先把这个场景的核心判断维度理清楚，所有选型都看和这几个要求的匹配度：

• 支撑多Lambda并发的短数据读写：单条数据是<1KB的JSON，需要支持读取最近写入的条目、写入新的最新条目
• 临时生命周期：所有并发Lambda执行完成后，存储内的全部数据需要即时清空，不需要长期留存
• 适配无持久化要求的状态共享场景，不需要数据库级的容灾、长期归档能力

DynamoDB是不是最优选择？ #

能用，但不是这个场景下的最优解，属于能力超配的选择。

• 它能满足基础功能要求：DynamoDB本身支持高并发低延迟读写，1KB级的小对象读写可以做到个位数毫秒延迟，开启强一致读就能避免最终一致带来的读不到刚写入数据的问题；数据删除也很灵活，可以给所有条目配置和任务超时对齐的TTL自动过期，或者任务全部完成后批量删除条目，甚至直接删除为这个场景临时新建的表，操作成本很低。
• 它的劣势也很明显：本质上DynamoDB是为持久化业务数据设计的，自带的自动扩缩、跨区复制、长期可靠性这些能力，对这个纯临时交换数据的场景完全用不上。成本层面，不管是预留还是按需计费模式，哪怕你只存几KB的临时数据，都会产生固定的基础开销，算下来比同性能的临时存储方案高不少；而且任务执行完如果忘记清表，残留的测试数据还会持续产生费用。

能不能用CloudWatch满足需求？ #

完全不匹配，不建议用。
根本原因是CloudWatch的设计目标和你的场景完全错位：

• 读写模型不对：CloudWatch Logs/Metrics是为监控场景设计的追加型存储，只支持按时间维度检索历史数据，没有“读取最新写入的单条数据”的能力——Lambda写进去的日志有1分钟级的投递延迟，并发高了还会出现日志乱序，你根本没法稳定读到“最近写入的最新条目”，要是硬拉日志流做过滤，延迟高到完全没法支撑并发交互的需求。
• 生命周期控制不对：CloudWatch的日志保留周期最短是1天，就算你手动触发日志流删除，数据也会有小时级的残留，根本做不到“最后一个Lambda执行完成就即时清空所有条目”。
• 成本更高：按摄入和存储字节数计费的模式下，同样存1KB的JSON，CloudWatch的单条成本是DynamoDB的3-5倍，完全没有性价比。

这个场景的实际最优解 #

• 首选ElastiCache Serverless for Redis：内存级毫秒读写，天然适配并发读写共享状态的需求，最后一个任务跑完直接执行FLUSHDB指令就能全量清空数据，没有任何残留；按实际使用的资源量计费，任务结束就自动释放资源，没有闲置成本，整体成本比DynamoDB低70%以上。
• 如果并发规模很小（比如最多10个并发Lambda，没有极致延迟要求），甚至直接用独立的临时S3桶就行：把JSON存成小对象，读最新条目就是列桶内key按修改时间排序取最新，任务跑完直接清空桶，成本几乎可以忽略。

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