Aravindh Raju

Software engineer, avid reader, sports enthusiast, and lifelong learner who enjoys exploring new ideas and challenges.

2 minute read

When you’re working with AWS Lambda at scale, you eventually hit limits you didn’t expect.
For us, it happened when we tried to deploy a new function and got this error:

An error occurred: HelloLambdaFunction - Code storage limit exceeded. (Service: AWSLambda; Status Code: 400; Error Code: CodeStorageExceededException; Request ID: ...)

At first glance, you might think this means the account-wide Lambda code storage quota (75 GB) had been hit.
But in reality, this was about the deployment package size limit:

  • Uncompressed package size limit: 250 MB (.zip or .jar)
  • Compressed zip size (direct upload): 50 MB
  • If uploaded via S3: up to 250 MB uncompressed

We weren’t over 75 GB — instead, our per-function package (code + dependencies) had simply grown too large.

The Problem: Duplicate Dependencies Everywhere

As we investigated, we realized the issue wasn’t the business logic itself — it was the dependencies.

Every Lambda function in our stack was bundling the same libraries (e.g., AWS SDK, utilities, common packages). This duplication caused our deployment packages to balloon past the 250 MB limit.

The Solution: Lambda Layers

Enter Lambda Layers.

Instead of packaging the same dependencies into each Lambda, we created a shared layer that contained all the common packages.

Benefits:

  • ✅ Reduced package size — each Lambda only carries its business logic.
  • ✅ Single point of update — updating a dependency in the Layer automatically applies to all Lambdas that use it.
  • ✅ No duplication — shared libraries live in the Layer instead of being bundled repeatedly.

Alternatives (If Layers Aren’t Enough)

While Lambda Layers solved our issue, there are other approaches too:

  1. Container Image Lambdas
    • Build your Lambda as a Docker image and push it to ECR.
    • Supports images up to 10 GB (much bigger than 250 MB zips).
    • Great for heavy workloads (ML, data processing).
  2. Trim Dependencies
    • Audit your code — sometimes we include entire libraries when we only need a subset.
  3. Multiple Layers
    • Each Lambda can use up to 5 layers, with each compressed layer up to 50 MB.
    • Helpful if one layer starts getting too large.

Why Lambda Layers Made Life Easier

The biggest win? Maintaining dependencies.

Instead of updating packages in every single Lambda one by one (and redeploying each time), we just update the dependency in the Lambda Layer.

  • Security vulnerability in lodash? Fix it once in the Layer → all Lambdas pick up the update.
  • New version of aws-sdk? Update it once → instantly applied everywhere.

This not only saves time but also ensures consistency across our stack. Every Lambda is always running with the same dependency versions, reducing drift and hidden bugs.

Final Thoughts

By moving to Lambda Layers, we eliminated duplicate code, reduced package sizes, and simplified dependency management.

The scary CodeStorageExceededException turned out to be less about hitting AWS’s global quota — and more about us packaging too much into each function.

Layers not only fixed the error but also made our architecture leaner and easier to maintain.

Have you hit the same 250 MB Lambda package size wall?
If so, did you solve it with Layers, container images, or another trick? I’d love to hear your approach!

You May Also Enjoy