AWSLambda取消代码存储配额，别误会：函数大小限制没变

亚马逊云科技最近宣布为 Lambda 推出自管理代码存储，让函数和层可以直接引用客户自有 S3 存储桶中的部署包，而不必将其存放在 Lambda 管理的存储空间中。这一变化取消了每个区域的代码存储配额，过去，运行大规模函数集群的团队通常需要通过提交支持工单来提高这一配额；同时，Lambda 管理的存储空间默认配额也从 75 GB 提高到 300 GB。事实证明，亚马逊云科技公告中的表述以及随后社区的反应很容易被误读。

亚马逊云科技无服务器计算首席开发者布道师 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 费用。