# AWS Lambda can now reference deployment packages directly from your S3 bucket Lambda’s new self-managed code-storage mode lets zip-based functions and layers reference versioned objects in customer-owned S3 instead of copying them into Lambda-managed storage, removing code-storage quota pressure while shifting artifact availability and access control onto the builder. AWS has added a `REFERENCE` mode for Lambda deployment packages. It eliminates duplicate managed copies, raises the default managed-storage quota to 300GB, and gives teams direct control over encryption, lifecycle and audit policy—but a deleted or inaccessible source object can now make a function inactive. - Status: Active - Published: 2026-08-22T22:56:00+12:00 - Updated: 2026-08-22T22:56:00+12:00 - Categories: Cloud & Infrastructure, Cloud Platforms, Deployment & DevOps - Tags: Amazon S3, AWS, AWS Lambda, serverless - Canonical HTML: https://beyondthe.news/dossiers/aws-lambda-self-managed-s3-code-storage-reference-mode ## What changed On July 15, 2026, AWS Lambda added self-managed S3 code storage for zip-based functions and layers. Instead of always copying a deployment package into Lambda-managed storage, builders can set `S3ObjectStorageMode=REFERENCE` so Lambda reads a specific versioned object directly from a customer-owned S3 bucket. AWS also raised the default Lambda-managed code-storage quota from 75GB to 300GB per Region per account. ## Why it matters This changes both scale limits and the trust boundary around Lambda deployment artifacts. Large function fleets can avoid consuming Lambda’s managed code-storage quota, while security and compliance teams can apply their own KMS keys, Object Lock, access logging, lifecycle rules and replication to the canonical artifact. The trade-off is operational responsibility: in reference mode the S3 object must remain available and readable, so deleting it, changing bucket policy or disabling a KMS key can push the function into an inactive state and break future cold starts or re-optimization. ## Reference mode removes Lambda’s intermediate copy Historically, Lambda copied zip deployment packages from a customer S3 bucket into internal Lambda-managed storage. With `REFERENCE`, the object in the builder’s bucket becomes the source Lambda reads directly. The deployment package no longer counts against Lambda-managed code storage, and AWS says function creation or update can be modestly faster because the copy step disappears. ## The artifact becomes part of your production control plane Customer ownership of the source object unlocks normal S3 controls such as versioning, SSE-KMS or DSSE-KMS, Object Lock, lifecycle configuration, CloudTrail or access logging, and cross-Region replication. That makes deployment code auditable and governable in the same account as the rest of a team’s release artifacts. ## Availability responsibility moves with the control Reference mode is not just a storage optimization. Lambda periodically needs the source object when re-optimizing function code. AWS documents that if the object becomes unavailable because it was deleted, permissions changed or a KMS key was disabled, the function can transition to `Inactive`. Restoring access and updating the function is then required to recover it. ## The old copy path still exists The default remains `COPY`, and builders can switch existing functions back and forth by updating function code. That makes the new mode opt-in rather than a forced migration, which is useful for teams that value Lambda-managed artifact durability over direct control. ## Key details - Self-managed S3 code storage launched July 15, 2026. - The feature applies to zip-based Lambda functions and layers, not container-image deployments. - Set `S3ObjectStorageMode` to `REFERENCE` to avoid the Lambda-managed copy. - The default Lambda-managed code-storage quota increased from 75GB to 300GB per Region per account. - Reference-mode packages do not consume the Lambda-managed storage quota. - S3 versioning is required for self-managed code storage. - Customer-managed encryption, Object Lock, access logging and replication can be applied to the canonical artifact. - If Lambda loses access to the referenced object, the function can become inactive. - There is no additional Lambda charge; ordinary S3 storage/request and applicable cross-Region transfer costs still apply. ## Builder takeaways - Use reference mode for large function fleets, many published versions or compliance-sensitive environments where Lambda-managed copies create quota or governance friction. - Treat the referenced S3 object as production infrastructure: require versioning, prevent accidental deletion and make bucket/KMS policy changes go through the same review path as application deploys. - If disaster recovery matters, replicate the artifact and test the runbook for repointing functions when the primary object or Region is unavailable. - Do not infer that storage control is free operationally; include S3 retention, replication and transfer costs plus the blast radius of bucket-policy mistakes in the decision. - Keep `COPY` for workloads where eliminating an external artifact dependency is more valuable than quota relief or direct security controls. ## What to watch - Whether AWS expands self-managed storage to container-image workflows or other Lambda artifacts. - Whether deployment frameworks make `REFERENCE` a first-class or default option for large fleets. - Operational reports on failures caused by source-object deletion, KMS changes or bucket-policy drift. - Whether AWS raises or reworks managed code quotas further as reference mode adoption grows. ## Uncertainties - AWS provides vendor testing showing faster function creation in reference mode, but BTN did not find independent benchmark data across fleet sizes and package distributions. - The practical availability risk depends heavily on each team’s S3/KMS controls and replication design, so there is no universal reliability advantage over `COPY` mode. ## Sources - [AWS Lambda announces self-managed code storage](https://aws.amazon.com/about-aws/whats-new/2026/07/lambda-self-managed-code-storage/) — AWS · primary · 2026-07-15T00:00:00+12:00. Official launch announcement covering reference mode, quota increase, availability and pricing. - [Introducing self-managed Amazon S3 buckets for AWS Lambda function code](https://aws.amazon.com/blogs/compute/introducing-self-managed-amazon-s3-buckets-for-aws-lambda-function-code/) — AWS Compute Blog · primary · 2026-07-17T00:00:00+12:00. Detailed explanation of lifecycle, permissions, performance, compliance controls and failure modes. - [Self-managed S3 code storage](https://docs.aws.amazon.com/lambda/latest/dg/configuration-self-managed-storage.html) — AWS Lambda Developer Guide · primary. Current product documentation for configuration and operational constraints.