AWS recently announced self-managed code storage for Lambda, letting functions and layers reference deployment packages directly in a customer-owned S3 bucket rather than in Lambda-managed storage. The change removes the per-Region code storage quota that teams running large function fleets have historically raised through support tickets, and raises the default for Lambda-managed storage from 75 GB to 300 GB. The framing in AWS's announcement, and in the community reaction that followed, has proven easy to misread.
Julian Wood, principal developer advocate for serverless at AWS, summarized the change on LinkedIn as "no storage limits: store as much function and layer code as your bucket allows," alongside a single source of truth in the customer's own account and full visibility through existing S3 metrics and lifecycle rules.
That phrasing prompted the question serverless teams will actually care about. One commenter asked whether the change meant larger models could now ship inside a function package. The answer from another developer was blunt:
No, the same limits still apply. Now AWS can bill you for the storage and retrieval costs too.
The distinction matters as self-managed storage changes where the deployment package lives and removes the aggregate account ceiling. Yet it does not change the per-function package limits, which remain 50 MB zipped and 250 MB unzipped for zip-based functions and 10 GB for container images. Teams hitting a size wall on an individual function are in exactly the same position as before.
What does change operationally is the copy step. Darryl Ruggles, an AWS Serverless Hero, noted on X that Lambda no longer creates an intermediate copy of the package:
With this change you can reference source code directly from your own buckets and Lambda no longer creates an intermediate copy. This can speed up function activation after creates and updates.
Ruggles added that there are no extra Lambda charges beyond standard S3 storage and any cross-Region transfer, which shifts the storage cost from an invisible Lambda-side quota to a visible line on the customer's own S3 bill.
The deployment workflow itself is unchanged. On Reddit, a practitioner asked what the benefit was given that UpdateFunctionCode still has to be called after replacing the object in S3. The reference is resolved at update time rather than continuously, so pointing Lambda at a bucket does not turn that bucket into a live code feed. Another commenter framed the value plainly:
It is a native option that overcomes the managed storage limit, and most teams will never reach it.
Infrastructure-as-code support is still catching up: a Terraform provider enhancement request filed on July 15 asks for an s3_object_storage_mode attribute on aws_lambda_function, and remains open with no implementation. Teams standardized on Terraform will need to wait or reach for the CLI and SDKs, where the parameter is available today.
Self-managed code storage is available in all commercial AWS Regions at no additional Lambda charge.