为何AWS S3删除对象远慢于创建？Lambda循环场景答疑

这事儿我之前踩过类似的坑，太能理解你的崩溃了——几分钟生成几十万张图，删起来却要几十分钟。核心原因在于S3对写入（创建对象）和删除对象的底层处理逻辑完全不同，再加上批量操作的限制，才会出现这么大的速度差：

• 创建对象是高并发友好的分布式操作
  你的Lambda函数触发生成缩略图时，是多实例并发执行的——AWS Lambda可以瞬间拉起成百上千个实例同时向S3写文件。而S3的存储架构是分布式分区的，每个对象的写入请求会被路由到就近的存储节点，写入操作本身只需要完成数据存储和基础元数据记录，不需要全局协调太多资源，所以能支撑极高的并发写入速率，短时间生成60万张图完全没问题。

• 删除对象需要更多的全局协调与元数据开销
  删除对象可不是简单的“删掉文件”：

  1. S3需要更新全局索引，标记该对象已删除；
  2. 哪怕你没开版本控制，底层也要处理对象的生命周期标记（后续后台才会真正清理存储块，但前端删除请求需要等待索引更新确认）；
  3. 如果是批量删除，S3的DeleteObjects API一次最多只能处理1000个对象，60万张图就得拆成600次API调用，每一次都要等待服务端的处理响应；
  4. 删除操作的一致性要求更高，需要确保所有存储节点的索引同步，这比写入时的“最终一致性”要耗时更多。

• AWS控制台的批量删除有额外的UI层限制
  你用控制台删除时，前端会分批发起删除请求，还要同步更新进度条、处理界面反馈，这又额外增加了延迟。如果换成用AWS CLI或者SDK写脚本批量调用DeleteObjects，速度会快一些，但还是赶不上创建的速度——毕竟底层的删除逻辑开销摆在那儿。

简单来说：创建是“分布式撒种子”，多线程多节点同时干活；删除是“集中收摊子”，得挨个更新账本、协调资源，自然慢很多。

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