Lambda adds self-managed S3 code storage

AWS added self-managed code storage to Lambda on July 15. Functions and layers can reference deployment packages in a customer’s S3 bucket rather than requiring Lambda to create an intermediate copy.

Artifact ownership becomes explicit

The announcement describes a reference mode for S3 objects and the bucket permissions Lambda needs to read them. It also raises the default Lambda-managed code-storage quota to 300 GB per account per Region, giving teams a separate option when the immediate problem is capacity.

For release engineering, direct references make the artifact bucket a more visible part of the deployment contract. Storage administration, application deployment, and rollback procedures must agree on how long referenced packages remain available.

Our analysis: artifact cleanup should be based on reachability from retained releases, not simply age. A package that looks old to a storage lifecycle rule may still be needed by a function version or a recovery procedure.

Test retention and restoration together

Inventory the tools that upload packages, set bucket policies, and delete obsolete objects. Establish which team can change each part, and make the effect on deployments understandable before adopting the reference mode.

Run a deployment and rollback exercise with a known previous artifact. Verify that the release process identifies the intended object unambiguously and that a storage-policy change cannot silently undermine the recovery plan.

Track activation behavior with the team’s actual package sizes if faster updates are part of the motivation. The announcement describes removing a copy step; it does not establish a measured deployment improvement for every application. Start with one function and its layers, document the artifact lifecycle, and extend the pattern after that lifecycle survives a rollback rehearsal.