AWS 最近 宣布了 Lambda 的自管理代码存储，允许函数和层直接引用客户自有 S3 存储桶中的部署包，而非 Lambda 托管存储。这一变更移除了每个区域的代码存储配额（以前需要通过支持工单提升），并将 Lambda 托管存储的默认值从 75 GB 提升至 300 GB。AWS 公告及后续社区讨论中的表述容易引发误解。

AWS Serverless 首席开发者布道者 Julian Wood 在 LinkedIn 上总结称：“无存储限制：可在存储桶允许范围内存储任意多的函数和层代码”，同时在客户自己的账户中实现单一事实来源，并通过现有的 S3 指标和生命周期规则实现完全可见性。

这一表述引发了 serverless 团队真正关心的问题。一位评论者询问该变更是否意味着现在可以在函数包中部署更大的模型。另一位开发者的回答直截了当：

不，同样的限制依然适用。现在 AWS 也能向您收取存储和检索费用了。

这种区别很重要：自管理存储改变了部署包的存放位置并移除了账户聚合上限，但并未改变 单个函数包的限制——zip 格式函数仍为压缩 50 MB、解压 250 MB，容器镜像则为 10 GB。遇到单个函数大小瓶颈的团队与之前相比并无变化。

在操作层面，变更影响的是复制步骤。AWS Serverless Hero Darryl Ruggles 在 X（原 Twitter）上指出，Lambda 不再创建中间副本：

通过此变更，您可以直接从自有存储桶引用源代码，Lambda 不再创建中间副本。这可加快创建和更新后的函数激活速度。

Ruggles 补充道，除了标准的 S3 存储费用及可能的跨区域传输费用外，Lambda 本身不产生额外费用，这将存储成本从 Lambda 侧隐性配额转变为客户 S3 账单上的可见条目。

部署流程本身保持不变。在 Reddit 上，一位实践者询问，既然替换 S3 对象后仍需调用 UpdateFunctionCode，那么该变更的意义何在。引用是在更新时解析，而非持续解析，因此将 Lambda 指向存储桶并不会将其转变为实时代码源。另一位评论者直接说明了其价值：

这是一个原生选项，可突破托管存储限制，且大多数团队永远不会触及该限制。

Infrastructure-as-code 支持仍在追赶：7 月 15 日提交的 Terraform Provider 增强请求要求在 aws_lambda_function 上增加 s3_object_storage_mode 属性，目前仍处于开放状态且未实现。已标准化使用 Terraform 的团队需等待，或改用当前已支持该参数的 CLI 和 SDK。

自管理代码存储已在所有商业 AWS 区域可用，且不产生额外 Lambda 费用。

关于作者

Steef-Jan Wiggers