亚马逊云科技最近宣布，为 AWS Lambda 引入了一项重大更新，允许函数和层直接引用客户自有 S3 存储桶中的部署包，取消了每个区域的代码存储配额。这一变化不仅提高了默认的存储空间配额，从 75 GB 增加到 300 GB，还简化了部署流程，不再需要创建中间副本。然而，这一改变引发了社区对是否意味着可以打包更大模型到函数包中的讨论。

--91likeyou---

亚马逊云科技无服务器计算首席开发者布道师 Julian Wood 在 LinkedIn 上总结了这一变化，称其“不再有存储限制：函数和层代码想存多少都可以，只要存储桶装得下”，同时还可以在客户自己的账户中建立单一事实来源，并通过现有的 S3 指标和生命周期规则获得完全的可见性。

这种表述引出了无服务器团队真正关心的问题。一位评论者询问，这一变化是否意味着现在可以将更大的模型打包到函数包中。另一位开发者的回答十分直截了当：

不，原有的限制仍然适用。现在亚马逊云科技还可以向你收取存储和检索费用了。

这一区别很重要，因为自管理存储改变了部署包的存放位置，并取消了账户层面的总量上限。但它并没有改变单个函数的包大小限制：基于 zip 的函数仍为压缩后 50 MB、解压后 250 MB，容器镜像仍为 10 GB。对于因单个函数大小达到上限而受阻的团队来说，情况与以前完全相同。

在运维层面，真正发生变化的是复制步骤。AWS Serverless Hero Darryl Ruggles 在 X 上指出，Lambda 不再创建部署包的中间副本：

有了这一变化，你可以直接引用自己存储桶中的源代码，Lambda 也不再创建中间副本。这可以加快函数在创建和更新后的激活速度。

Ruggles 补充说，除了标准的 S3 存储费用和可能产生的跨区域传输费用外，不会产生额外的 Lambda 费用。这使存储成本从一个不可见的 Lambda 端配额，转变为客户自己的 S3 账单上一项清晰可见的费用。

部署工作流本身并未改变。在 Reddit 上，一位从业者询问这一功能究竟有什么好处，因为替换 S3 中的对象后仍然必须调用 UpdateFunctionCode。该引用是在更新时解析的，而不是持续解析的，因此，将 Lambda 指向一个存储桶并不会让该存储桶变成实时的代码源。另一位评论者直白地概括了其价值：

这是一个能够突破托管存储限制的原生选项，而大多数团队永远都不会达到这个限制。

基础设施即代码支持仍在跟进：7 月 15 日提交的一项 Terraform 提供程序增强请求，要求为 aws_lambda_function 增加 s3_object_storage_mode 属性，目前仍处于开放状态，尚未实现。已经将 Terraform 标准化的团队需要继续等待，或者改用目前已经支持该参数的 CLI 和 SDK。

自管理代码存储已在所有亚马逊云科技商业区域推出，不收取额外的 Lambda 费用。

：

🔥 热词：#aws lambda 函数即服务 · #aws lambda 服务实例配置文件