Lambda's S3-Backed Storage Removes Account Caps but Keeps Per-Function Size Limits

AWS has introduced self-managed code storage for Lambda, enabling functions to fetch deployment packages from a customer's own S3 bucket instead of AWS-managed storage. While the move lifts account-level quota ceilings and doubles the default managed storage from 75 GB to 300 GB, it has sparked some confusion in the developer community about what the feature actually enables.

What Changes: Account Limits and Storage Location#

The key shift is architectural rather than functional. Teams can now point Lambda at their own S3 buckets, sidestepping the per-Region code storage quota that previously required support tickets to raise. Rather than storing all function code in AWS's managed infrastructure, deployments live directly in customer-controlled S3, offering single-source-of-truth benefits and native integration with S3 lifecycle policies and CloudWatch metrics.

AWS principal developer advocate Julian Wood highlighted on LinkedIn that teams can now "store as much function and layer code as your bucket allows."

What Doesn't Change: Individual Function Sizes#

However, the announcement has been widely misinterpreted as enabling bigger deployment packages. The per-function size limits remain identical: 50 MB zipped and 250 MB unzipped for zip-based functions, and 10 GB for container images. Teams attempting to ship large machine-learning models or other bulky payloads inside a function remain blocked by the same constraints, with the added twist that S3 storage and retrieval now appear on their own bill rather than counting against a hidden Lambda quota.

Operational Impact#

The practical benefit centers on deployment efficiency. AWS Serverless Hero Darryl Ruggles noted on X that Lambda "no longer creates an intermediate copy" of packages, potentially accelerating function activation after deployment. Cost visibility also improves: rather than bumping against opaque account limits, teams see storage expenses as line items on their S3 invoice.

The deployment workflow itself is largely unchanged—teams still call UpdateFunctionCode after uploading to S3, and reference resolution occurs at update time rather than continuously. As one Reddit commenter observed, self-managed storage is simply "a native option that overcomes the managed storage limit, and most teams will never reach it."