AWS Lambda Overcomes One of Its Biggest Limitations: How Self-Managed Code Storage Works

AWS has introduced one of the most exciting updates for those developing large-scale serverless applications. With the arrival of Self-Managed Code Storage for AWS Lambda, functions are no longer required to store their code within the managed storage provided by the service. Instead, they can be executed by referencing artifacts stored directly in a customer-owned Amazon S3 bucket. The change may seem small, but it removes a long-standing limitation of Lambda and opens new possibilities for teams managing hundreds or thousands of functions.

The highlights of AWS Lambda Self-Managed Code Storage in 20 seconds

• AWS allows Lambda to reference code stored directly in a customer’s Amazon S3 bucket.
• The practical code storage limit is eliminated, now depending solely on the capacity of the bucket.
• The managed Lambda storage quota has been increased from 75 GB to 300 GB per region and account.
• Deployment can be faster, and customers retain greater control over security, encryption, and disaster recovery.

For years, code storage was barely a concern for small projects. However, as serverless architectures have grown, many organizations have ended up managing hundreds of Lambda functions, multiple shared layers, increasingly heavy libraries, and even dependencies related to AI or data processing. In these scenarios, the historic limit of 75 GB per region and account could become a bottleneck, often requiring quota increases via support. Although AWS had already raised this limit to 300 GB, the new functionality takes a further step and nearly removes that restriction altogether.

What really changes with Self-Managed Code Storage

Until now, when a Lambda function was created or updated using a ZIP package stored in Amazon S3, Lambda would copy that package into its internal managed storage. That copy was then used to execute the function and consumed part of the quota.

With Self-Managed Code Storage, Lambda stops making that copy and instead references the object directly from the customer’s bucket.

Practically, the difference can be summarized as follows:

Traditional Model (COPY)

CI/CD
   │
   ▼
Amazon S3
   │
   ▼
Lambda copies ZIP
   │
   ▼
Internal Lambda storage
   │
   ▼
Execution

New Model (REFERENCE)

CI/CD
   │
   ▼
Amazon S3
   │
   ▼
Lambda directly references the object

This change reduces an entire step in the deployment process and makes the S3 bucket the single source of truth for the code.

AWS also reports that, in their tests with a Python 3.13 function of about 200 MB, creating the function took roughly five seconds less using the REFERENCE mode compared to traditional mode.

From 75 GB limit to almost unlimited storage

The most obvious benefit is related to available space.

Previously, all versions of functions and layers stored by Lambda consumed part of the regional quota. In organizations with continuous deployments, multiple environments, or several active versions, that space could grow rapidly.

With the new REFERENCE mode, storage stops depending on Lambda and relies solely on the Amazon S3 bucket.

Additionally, AWS has concurrently increased the Lambda managed storage quota from 75 GB to 300 GB per region and account. This means that even those continuing to use the traditional mode will have four times more space available.

COPY vs REFERENCE: what are the differences?

This change is more than just increasing storage capacity; it shifts responsibility for artifact lifecycle management.

A change that fits particularly well with CI/CD pipelines

For many DevOps teams, this new approach feels quite natural.

Most modern pipelines already generate artifacts, store them in Amazon S3, and then deploy infrastructure.

Now, the same artifact can be used directly as the copy for Lambda, avoiding unnecessary duplication.

This simplifies common operations like:

• Rolling back to a previous version of the S3 object;
• Centralizing all deployment artifacts;
• Applying the same encryption and retention policies;
• Maintaining a single source of truth for all code.

In organizations using multiple accounts via AWS Organizations, it’s also easier to centralize deployment packages in a dedicated tooling account and control access from production accounts using bucket policies.

Enhanced security and compliance control

One of the less obvious but highly valuable benefits for many companies is security management.

Since the storage resides with the customer, they can directly apply their own policies to Amazon S3, such as:

• Encryption with SSE-KMS;
• Object Lock;
• Versioning;
• Auditing;
• Specific IAM policies;
• Object retention.

This makes it easier to meet internal security requirements or regulatory obligations without relying solely on Lambda-managed storage.

Furthermore, if S3 Cross-Region Replication (CRR) is used, it can automatically maintain copies of the code in another region as part of a disaster recovery strategy.

New responsibilities also emerge

An important aspect is that the customer becomes responsible for keeping the code accessible.

With the REFERENCE mode, the bucket must have versioning enabled, and Lambda needs permissions to access objects via s3:GetObject and s3:GetObjectVersion.

If a customer-managed KMS key is used, Lambda will also need permissions for kms:Decrypt.

Additionally, it’s important to note that if the object is deleted, the bucket policy changes, or the encryption key becomes unavailable, Lambda will no longer be able to access the code. In such cases, the function may enter an Inactive state—something that didn’t happen when Lambda stored its own copy internally.

For this reason, it is advisable to set up lifecycle policies to delete old versions of the code in a controlled manner, always keeping some versions available to facilitate potential rollbacks.

Terraform is still catching up

At the time of announcing this feature, AWS confirmed support via AWS CLI and AWS CloudFormation.

However, the official hashicorp/aws provider for Terraform has not yet incorporated the s3_object_storage_mode parameter. For now, many teams will need to combine Terraform with CloudFormation or the CLI to deploy functions using the new REFERENCE mode.

Support is expected to be included in future provider releases.

When is using REFERENCE worthwhile?

Organizations don’t need to switch immediately.

The traditional mode remains perfectly valid for many projects.

REFERENCE is especially useful when:

• Managing hundreds or thousands of Lambda functions;
• Many shared layers exist;
• CI/CD pipelines already use Amazon S3 as an artifact repository;
• Advanced security or compliance policies are required;
• A single source of truth for the code is desired.

COPY continues to be a good choice when:

• The project is small;
• The functions occupy little space;
• The 300 GB limit is sufficient;
• Maximum operational simplicity is preferred;
• The integrated code editor in the Lambda console is used frequently.

A logical evolution of the serverless model

Self-Managed Code Storage doesn’t change how AWS Lambda executes code but does modify how deployment artifacts are managed. Storage is no longer exclusively Lambda’s responsibility but falls under the control of the customer, especially suited for organizations already working with infrastructure as code and automated deployment pipelines.

Besides virtually eliminating the historical code storage limit, this feature provides greater control over security, disaster recovery, and software governance. At the same time, it requires more careful management of the lifecycle of objects stored in Amazon S3.

For teams already using S3 as a central artifact repository, transitioning to REFERENCE is nearly seamless. For others, the quota increase to 300 GB offers a significant upgrade without needing to modify existing architectures.

Frequently Asked Questions

What is AWS Lambda Self-Managed Code Storage?

It’s a new feature that allows AWS Lambda to use code directly stored in a customer-owned Amazon S3 bucket, without copying it into Lambda’s managed storage first.

Does this eliminate Lambda’s storage limit?

Lambda’s managed storage increases from 75 GB to 300 GB per region and account. When using REFERENCE, the practical limit becomes the capacity of the Amazon S3 bucket.

Is bucket versioning mandatory?

Yes. The REFERENCE mode requires the bucket to have versioning enabled to ensure Lambda always references a specific, immutable version of the artifact.

Are there additional costs?

AWS does not charge extra for using Self-Managed Code Storage, but since storage depends on Amazon S3, standard S3 costs apply, along with potential charges for requests and data transfers between regions if applicable.