AWS Lambda's Self-Managed Code Storage Lifts the Account Quota, Not the Function Size Limit
Steef-Jan Wiggers · rss · 2026-07-30 source ↗ Reader 🖥️
AWS Lambda's new self-managed code storage removes the per-Region account-level code storage quota and makes storage costs visible on the customer's own S3 bill, but it leaves the per-function package size limits (50 MB zipped / 250 MB unzipped / 10 GB container) completely unchanged, so the announcement should not be read as lifting the ceiling on how large an individual function can be.
theoretical · expository — A news explainer that reports and corrects a misreading of an AWS feature announcement. It doesn't argue for an action; it argues for an accurate understanding of what changed and what didn't, assembling quotes from AWS staff and community reaction to draw the line precisely.
Structure
| Part | Role |
|---|---|
| The announcement and its most quotable framing (Julian Wood's 'no storage limits' LinkedIn summary) | context |
| The community's misreading and its correction (the model-size question, the blunt 'No, the same limits still apply' reply) | evidence — establishes the specific distinction the article is built around |
| Darryl Ruggles' technical detail on the removed intermediate copy step and the S3-bill cost-visibility shift | evidence — operational mechanics of what actually changed |
| The Reddit exchange on UpdateFunctionCode still being required | evidence — clarifies the deployment workflow is unchanged, not a live code feed |
| The open Terraform provider issue for s3_object_storage_mode | context — tooling maturity gap around the new feature |
Key terms
- self-managed code storage
A Lambda configuration mode where a function or layer references a deployment package directly in a customer-owned S3 bucket, instead of Lambda copying and holding the package in its own managed storage. - account-level code storage quota
The aggregate ceiling (formerly 75 GB, now 300 GB by default under managed storage) on total deployment-package storage across all functions/layers in a Region, which is what self-managed storage removes. - per-function package size limit
The fixed ceiling on any single function's or layer's deployment package (50 MB zipped, 250 MB unzipped, 10 GB for container images), which self-managed storage does not touch.
Propositions
- explicitSelf-managed code storage removes the per-Region account-level code storage quota by letting deployment packages live in a customer-owned S3 bucket instead of Lambda-managed storage.conf: high
- explicitThe per-function package size limits (50 MB zipped, 250 MB unzipped, 10 GB container images) are unaffected by self-managed storage, so a single function still cannot be larger than before.conf: high
- explicitAWS's own promotional framing of the feature ('no storage limits') is easy to misread as lifting the per-function size ceiling, when it actually only lifts the account-wide aggregate ceiling.conf: high
- explicitSelf-managed storage converts what was an invisible, Lambda-side capacity constraint into a visible, itemized cost on the customer's own S3 bill.conf: high
- explicitSelf-managed storage changes the deployment package's location and copy mechanics but not the deployment workflow itself — UpdateFunctionCode still must be called, and the S3 reference is resolved only at update time, not continuously.conf: high
- explicitInfrastructure-as-code tooling (specifically Terraform) has not yet caught up to this feature: an enhancement request for an s3_object_storage_mode attribute has been open since July 15 with no implementation, leaving Terraform-standardized teams to use the CLI/SDKs instead.conf: high
Arguments
Self-managed code storage is a niche fleet-management feature for teams running many large functions/layers against the account quota, not a way to ship larger individual functions. strength: high
Explicit premises:
- It removes the account-level aggregate quota, which is what large fleets historically hit.
- It does not change the per-function package size limits.
- One commenter states most teams will never reach the managed storage limit at all.
Implicit premises:
- The audience most likely to misread the announcement (as raising the per-function ceiling) is not the audience it actually serves (large fleets bumping the account quota) — these are different populations of Lambda users with different pain points.
- AWS's marketing framing ('no storage limits') is optimized for headline appeal rather than precision, so practitioners must read past it to the docs to know what actually changed.
Inferences:
- For the median Lambda user — who the article notes will never hit the account-wide storage limit — this feature has essentially no practical effect beyond cost-model transparency.
Narratives
- A commenter asks on LinkedIn whether the change means larger ML models could now ship inside a function package; another developer replies bluntly that the same limits still apply and AWS can now also bill for storage and retrieval.
→ This exchange is the concrete instance of the misreading the whole article exists to correct — it shows, rather than states abstractly, how the account-quota/function-limit distinction gets lost in practice. - A Reddit practitioner asks what the actual benefit is, given that UpdateFunctionCode still has to be called after replacing the S3 object — implying they expected something closer to live, continuous code updates.
→ Supports the proposition that the deployment workflow is unchanged; also implicitly reveals a second, distinct misreading (mistaking the feature for a live code feed) beyond the first (mistaking it for a size-limit increase).
Questions addressed
- ✅ Does self-managed code storage let an individual Lambda function or layer be larger than before?
No — per-function package limits (50 MB/250 MB/10 GB) are unchanged; only the account-wide aggregate quota is removed. - ✅ What operational behavior changes when a function references code in a self-managed bucket instead of Lambda-managed storage?
Lambda no longer makes an intermediate copy of the package (potentially speeding activation after creates/updates), and the customer sees storage/transfer costs directly on their S3 bill instead of an invisible Lambda-side allocation. - ✅ Is the S3 reference live, or does Lambda still require an explicit update step to pick up new code?
Still requires UpdateFunctionCode; the reference resolves at update time, not continuously — replacing the S3 object alone does not deploy new code. - ⭕ Is this feature widely useful, or does it serve a narrow segment of Lambda users?
The article quotes a commenter saying 'most teams will never reach it,' but doesn't quantify what fraction of AWS's Lambda customer base actually hits the account-wide quota today, so the practical reach of the change is asserted rather than measured.
Gaps
- incompleteThe article never states what fraction of Lambda users actually hit the old 75 GB (or new 300 GB) account-level storage quota in practice — the 'most teams will never reach it' claim comes from a single anonymous commenter, not from AWS usage data. Without that, it's unclear whether this is a headline feature for a small population of large fleets or something more broadly relevant.
Read next: AWS re:Invent or Lambda team blog posts with aggregate usage statistics on function fleet sizes, or case studies from large serverless deployments (e.g. media transcoding, ML inference fleets) that specifically hit the old code storage ceiling. - incompleteThe article doesn't explore the cost trade-off in the other direction: self-managed S3 storage now bills at S3 rates (plus cross-Region transfer) rather than being bundled into Lambda's managed allocation. For teams near the account quota, is self-managed storage actually cheaper, more expensive, or roughly neutral compared to what they were paying implicitly before? The piece asserts visibility ('a visible line on the customer's own S3 bill') without addressing whether visibility comes with a net cost change.
Read next: AWS Lambda and S3 pricing documentation, and any published cost-comparison or migration case study for teams that have switched fleets to self-managed code storage.