处理S3历史数据导入DynamoDB：运行Lambda还是编写脚本更优？

这个场景下编写独立脚本处理确实比直接复用现有事件触发型Lambda更合适，原因和对应优势如下：

直接使用现有Lambda的核心问题 #

你调研到的限制刚好命中了历史批量导入场景的痛点：

• Lambda函数默认超时时间通常较短，哪怕调整到最大支持的15分钟上限，单文件40万条记录如果用单条PutItem写入，大概率会触发超时；且你当前设置的512MB内存上限虽然足够承载20-25MB的文件解析，但无法支撑批量写入的并发优化，进一步拉长执行时间。
• 现有Lambda是S3事件触发模式，要处理全量历史文件需要手动触发所有对象的事件通知，不仅操作繁琐，还没有全局进度监控、断点续传能力，一旦执行中断很难定位已处理范围，容易出现漏写、重复写的问题。
• 直接复用业务Lambda处理历史导入，还可能和后续上线后的正常业务事件抢占Lambda并发配额，影响业务流程。

独立脚本的适配优势 #

针对一次性历史导入场景，独立脚本的灵活性远高于Lambda：

• 不受运行时长、内存配置限制，可以自由实现多线程/进程并发处理，搭配DynamoDB的BatchWriteItem接口（单次请求最多写入25条记录），可以大幅提升导入效率，同时可以自主控制写入速率，避免触发DynamoDB的吞吐量节流。
• 可以便捷实现断点续传逻辑：只需要记录已经处理完成的月份文件夹、文件名、甚至行号，执行中断后可以直接从断点继续，无需全量重跑。
• 错误处理更灵活：可以单独记录格式异常、写入失败的记录，后续批量重试，不会因为单条记录异常导致整个文件导入失败。
• 部署成本更低：脚本可以直接在本地设备、或者低成本的EC2小型实例上运行，无需修改现有线上Lambda的配置，也不会占用线上业务的运行资源。

如果确实想使用Serverless架构处理导入，也可以额外编写专用的导入Lambda，配合SQS队列做历史文件的任务调度，但改造和调试成本远高于一次性的导入脚本，非特殊需求不推荐。

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