AWS Lambda Drops Its 75GB Code Storage Limit — Here Is What Changes

AWS Lambda raised its per-account code storage limit from 75GB to 300GB per Region and introduced a new REFERENCE mode that lets functions point directly to S3 objects, bypassing the quota entirely, effective July 15. The change, announced by AWS, reduces function creation time by roughly five seconds for a 200MB Python 3.13 package and requires S3 versioning and specific IAM permissions. Terraform support for the new mode remains an open enhancement request with no ship date.

AWS quietly fixed one of Lambda’s most annoying operational headaches last month: the 75GB per-account code storage ceiling is now 300GB by default, and a new REFERENCE mode lets you sidestep the quota entirely by pointing Lambda at your own S3 bucket. If you are on Terraform, hold off — provider support for the new flag is still an open enhancement request with no ship date. The Quota That Bit Large Teams The 75GB limit applied to Lambda-managed storage — the internal copy the service kept of every function zip and layer you uploaded. It was account-level, not per-function, which meant teams with dozens of functions and accumulated unpublished versions chewed through it faster than expected. The error “Code storage limit exceeded” blocks deployments until you manually purge old versions, which is exactly as painful as it sounds. AI agent workloads made this worse. Teams bundling embedding models, LLM runtimes, or heavy ML preprocessing libraries into Lambda packages saw function sizes balloon to 200MB–1GB. A few dozen such functions, each with several versions sitting around, and you hit the wall. The standard advice — delete old unpublished versions with a script — is a workaround, not a solution. Two Changes Shipped on July 15 AWS delivered a quota bump and a new deployment mode simultaneously. The managed default rose from 75GB to 300GB per Region per account. That kicks in automatically for every account — no configuration required. For most teams, that buys meaningful runway, but it does not remove the ceiling. REFERENCE mode is the more interesting change. When you set S3ObjectStorageMode=REFERENCE on a function or layer, Lambda pins to a versioned S3 object and never makes an internal copy. Your S3 object becomes the authoritative source; Lambda reads it directly on cold start. The account quota no longer applies to artifacts stored this way. AWS reported roughly five seconds faster function creation https://aws.amazon.com/blogs/compute/introducing-self-managed-amazon-s3-buckets-for-aws-lambda-function-code/ for a 200MB Python 3.13 package in REFERENCE mode, because the copy step disappears. You pay only standard S3 storage rates — no additional Lambda storage charge. Two requirements are non-negotiable. The S3 bucket must have versioning enabled — Lambda pins to a specific object version, not the latest. And the Lambda service principal needs s3:GetObject and s3:GetObjectVersion permissions on the bucket. Update an existing function to REFERENCE mode aws lambda update-function-code \ --function-name my-ai-agent \ --s3-bucket my-artifacts \ --s3-key agent.zip \ --s3-object-version abc123def456 \ --s3-object-storage-mode REFERENCE Cross-account and cross-Region buckets both work. Cross-Region adds transfer cost and deployment latency, so pair it with S3 Cross-Region Replication https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html if you need a multi-Region Lambda setup. The replication approach finally gives Lambda deployments a real disaster recovery story: your artifact archive is durable, version-controlled, and retrievable from multiple Regions. Terraform Teams: Wait on This One REFERENCE mode is available today through the AWS CLI, CloudFormation, SAM, and the AWS SDKs. The Terraform AWS provider does not yet expose the s3 object storage mode attribute on aws lambda function . An enhancement request was filed the same day the feature shipped — July 15 — and it remains open with no announced implementation timeline. If your Lambda stack is Terraform-managed, the practical options are unpleasant: escape-hatch to the CLI for REFERENCE mode updates, use a null resource to invoke the AWS CLI from within Terraform, or mix CloudFormation for the function resource. None of these are clean. The safer play is to wait for provider support before migrating production functions to REFERENCE mode. The 300GB default increase is yours immediately with zero IaC changes. Who Should Migrate Now REFERENCE mode is the right call if you manage Lambda artifacts through a CI/CD pipeline that already writes to S3, if you are running large AI workloads where function packages regularly exceed 100MB, or if you want immutable, version-controlled rollbacks without manual Lambda version management. Rollback under REFERENCE mode is clean: update the function to point at the previous S3 object version and you are done — no Lambda version purging, no scripts. If your primary IaC is Terraform, adopt the 300GB bump and revisit REFERENCE mode once provider support ships. The official AWS announcement https://aws.amazon.com/about-aws/whats-new/2026/07/lambda-self-managed-code-storage/ and the Lambda self-managed storage docs https://docs.aws.amazon.com/lambda/latest/dg/configuration-self-managed-storage.html have the complete configuration reference when you are ready.