Introduction

RequestEntityTooLargeException in AWS Lambda usually means the artifact you are uploading exceeds one of Lambda package limits. Many teams try to "increase" this limit directly, but the practical solution is to change packaging strategy. This guide explains the limits and shows architecture patterns that remove deployment-size bottlenecks.

Core Topic Sections

Understand the relevant Lambda limits

There are several size-related constraints:

1. Direct zipped upload through API or console has a strict size cap.
2. Unzipped code plus dependencies must remain below Lambda runtime extraction limit.
3. Lambda layers also have their own size limits and count limits per function.
4. Container-image Lambda has different limits than zip-based Lambda.

Because limits differ by packaging mode, the right fix depends on how you deploy.

First-line fixes for zip deployments

Start by reducing package size:

1. Remove dev dependencies.
2. Exclude test assets and docs from artifact.
3. Strip debug symbols where safe.
4. Prefer smaller runtime dependencies.

Example for Node.js package pruning:

npm ci --omit=dev
zip -r function.zip index.js node_modules

For Python, build from a clean environment and include only runtime packages:

pip install -r requirements.txt -t build/
cp app.py build/
cd build && zip -r ../function.zip .

Move heavy dependencies into Lambda Layers

If many functions share large libraries, place them in a layer and keep function zip minimal.

mkdir -p layer/python
pip install pandas -t layer/python
cd layer && zip -r ../layer.zip python

Then attach the layer to function and deploy smaller function package. This improves reuse and reduces duplicate upload size across services.

Use S3-based deployment for larger zipped artifacts

Even when direct upload fails, Lambda can pull package from S3 during update.

1aws s3 cp function.zip s3://my-deploy-bucket/function.zip
2aws lambda update-function-code \
3  --function-name my-fn \
4  --s3-bucket my-deploy-bucket \
5  --s3-key function.zip

This does not bypass all Lambda limits, but it avoids direct request payload size constraints on update calls.

Switch to container image for very large dependencies

If your dependency stack cannot fit zip and layer constraints cleanly, Lambda container image is often the right model.

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

Build and push image to ECR, then point function to image URI. This is useful for ML and native-library workloads.

Reduce package bloat in build pipelines

Common artifact bloat sources:

1. Packaging local virtual environments accidentally.
2. Including source maps and test fixtures by default.
3. Bundling unused transitive dependencies.

Use bundlers and exclusion lists.

For Node.js with esbuild:

npx esbuild src/handler.ts --bundle --platform=node --target=node20 --outfile=dist/index.js

Bundling can drastically shrink final artifact.

CI guardrails for size regressions

Add pipeline checks so package growth is caught before deploy:

1MAX_BYTES=50000000
2SIZE=$(stat -c%s function.zip)
3if [ "$SIZE" -gt "$MAX_BYTES" ]; then
4  echo "artifact too large"
5  exit 1
6fi

This prevents release-day failures from unnoticed dependency growth.

Decision guide

Choose packaging path by workload:

1. Small to medium functions: zip + pruning.
2. Shared heavy libs: layers.
3. Very large runtime stack: container image.
4. Deployment call too large but package acceptable: S3-based code update.

Treat this as architecture choice, not emergency workaround.

Common Pitfalls

• Assuming AWS provides a simple quota increase for all Lambda package size errors.
• Uploading direct zip from CI without artifact-size validation.
• Duplicating heavy dependencies in every function instead of shared layers.
• Moving to container image without considering cold start and image optimization.
• Packaging development artifacts and test data into production deployment bundles.

Summary

• RequestEntityTooLargeException is solved by packaging strategy, not only retries.
• Prune artifacts first, then use layers for shared heavy dependencies.
• Use S3-based updates to avoid direct upload request-size issues.
• Move to Lambda container images when zip and layer constraints are not sufficient.
• Add CI size checks to keep deployments reliable as dependencies evolve.