Introduction

This Lambda error means the total uncompressed size of your function code plus all attached layers is larger than 262144000 bytes, which is 250 MiB. The important detail is that AWS checks the extracted contents, not just the ZIP file size you upload. To fix it, you need to reduce what ships with the function or switch packaging strategies entirely.

What Counts Toward the Limit

For ZIP-based Lambda deployments, the size check applies to the unzipped contents of:

• your function package
• every attached Lambda layer
• native libraries and binaries included in those packages

That means a small compressed archive can still fail if it expands into a large dependency tree. Python scientific stacks, Node.js bundles with heavy native modules, and Java fat JARs are common offenders.

A useful first step is to inspect the extracted size locally:

1rm -rf /tmp/lambda-unpack
2mkdir -p /tmp/lambda-unpack
3unzip -q function.zip -d /tmp/lambda-unpack
4du -sh /tmp/lambda-unpack
5find /tmp/lambda-unpack -type f -exec du -h {} + | sort -hr | head -20

That quickly shows which files are driving the package size.

Remove What Lambda Does Not Need

A large share of deployment bloat comes from files that are useful in development but irrelevant in production. Typical candidates include:

• tests
• documentation
• type stubs
• source maps you do not need at runtime
• unused locales or assets
• cached build artifacts

For Python, package only the production dependencies into a clean directory:

1python -m venv .venv
2source .venv/bin/activate
3pip install -r requirements.txt --target build/
4cp lambda_function.py build/
5cd build && zip -r ../function.zip .

For Node.js, bundle the function so only used modules are included:

1npx esbuild index.js \
2  --bundle \
3  --platform=node \
4  --target=node20 \
5  --outfile=dist/index.js
6cd dist && zip ../function.zip index.js

Bundling is often a major improvement because it drops large dependency trees that were never actually imported.

Use Layers Carefully

Layers help reuse dependencies, but they do not bypass the 250 MiB unzipped limit. The combined extracted size of the function and its layers still matters.

So layers are good when:

• several functions share the same dependency set
• you want independent deployment of code and dependencies
• the total extracted size still fits within the limit

Layers are not the answer when the problem is simply that the whole runtime footprint is too large.

Move Large Assets Out of the Package

If the package contains models, media files, large dictionaries, or static datasets, they probably should not live inside the deployment ZIP.

Better options include:

• storing assets in S3 and loading them at startup or on demand
• using EFS when the function needs shared file access
• packaging only a small bootstrap artifact and downloading the rest lazily

This changes the cold-start profile, so test it, but it is often the correct architectural fix.

Consider Lambda Container Images

If you genuinely need a larger runtime footprint, Lambda container images are usually the cleaner escape hatch. ZIP deployments have the 250 MiB extracted limit, while container-image functions can use a much larger image size budget.

A minimal Python example:

1FROM public.ecr.aws/lambda/python:3.12
2
3COPY requirements.txt ./
4RUN pip install -r requirements.txt
5
6COPY app.py ${LAMBDA_TASK_ROOT}
7CMD ["app.handler"]

Build and push the image, then configure the Lambda function to use the ECR image instead of a ZIP archive.

This does not remove the need to keep the image lean. Large images still hurt transfer time and cold starts. But it is the right packaging mode when ZIP limits are the bottleneck.

Common Sources of Bloat

In real projects, the biggest size spikes often come from:

• 'numpy, pandas, scipy, torch, and similar binary-heavy packages'
• headless browser binaries
• duplicated dependencies across function code and layers
• bundling the whole virtual environment or entire node_modules tree
• compiled files for the wrong platform or architecture

Inspecting file sizes is more productive than guessing. Usually one or two directories explain most of the problem.

Common Pitfalls

A common mistake is checking only the compressed ZIP size. Lambda cares about the extracted size.

Another mistake is assuming layers do not count toward the limit. They do.

People also often ship development files and entire dependency trees without verifying which modules are actually required at runtime.

Finally, do not move huge artifacts into the package just because it simplifies deployment. If the function needs large models or datasets, S3, EFS, or container images are often better fits.

Summary

• The error means the extracted size of the function package plus layers is over 250 MiB
• Measure the unzipped contents locally to find the real source of the bloat
• Remove development files and unused dependencies from the runtime package
• Layers help reuse dependencies but do not avoid the combined unzipped size limit
• Store large assets outside the ZIP package when possible
• If the runtime footprint is genuinely large, use a Lambda container image instead of ZIP packaging