🚨 AWS Error Guide: 'CodeStorageExceededException' — Reclaim Lambda Code Storage Quota

Overview

AWS Lambda gives each account a per-region code-storage quota (75 GB by default) that covers the sum of all deployment packages across every function version and layer. Every publish of a new version keeps the previous versions’ code too, so on a busy account the total creeps upward until a deploy fails with CodeStorageExceededException — “Code storage limit exceeded.” The failing call is usually CreateFunction, UpdateFunctionCode, or PublishVersion.

You will see it from the CLI or SDK:

An error occurred (CodeStorageExceededException) when calling the UpdateFunctionCode operation: Code storage limit exceeded.

CloudFormation/SAM surfaces the same during a deploy:

Resource handler returned message: "Code storage limit exceeded. (Service: Lambda, Status Code: 400)"

It occurs when the account’s accumulated function versions and layers — mostly old, unaliased versions nobody prunes — reach the 75 GB (or raised) code-storage quota.

Symptoms

• Deploys that previously worked start failing with CodeStorageExceededException on UpdateFunctionCode/PublishVersion.
• Every function in the account fails to deploy, not just one — because the quota is account-wide per region.
• CI/CD pipelines that publish a new version per commit fail after months of accumulation.
• get-account-settings shows CodeSizeUnzipped/TotalCodeSize near the CodeSizeUnzipped/account limit.

aws lambda update-function-code --function-name checkout-api --zip-file fileb://build.zip

An error occurred (CodeStorageExceededException) when calling the UpdateFunctionCode operation: Code storage limit exceeded.

Common Root Causes

1. Accumulated old function versions

Every PublishVersion retains the old versions’ code. Publishing on every commit for months stores hundreds of stale versions.

aws lambda list-versions-by-function --function-name checkout-api \
  --query 'length(Versions)' --output text

214

214 retained versions, almost all unaliased and unused, each holding a full package.

2. The account is at the code-storage quota

The account-wide TotalCodeSize has reached the 75 GB default limit.

aws lambda get-account-settings \
  --query 'AccountUsage.TotalCodeSize,AccountLimit.TotalCodeSize' --output text

80530636800	80530636800

Usage equals the limit (75 GB) — no new code fits until you reclaim or raise it.

3. Large deployment packages

Oversized packages (bundled node_modules, vendored binaries, ML models) consume the quota far faster than lean ones.

aws lambda list-functions \
  --query 'reverse(sort_by(Functions,&CodeSize))[:5].[FunctionName,CodeSize]' --output text

ml-inference	248901120
report-render	190221312

A couple of 200 MB+ functions, multiplied across versions, dominate the storage.

4. Abandoned functions never deleted

Functions from decommissioned services still hold all their versions’ code.

aws lambda list-functions --query 'Functions[?LastModified<`2025-01-01`].[FunctionName,CodeSize]' --output text

legacy-webhook	52428800
old-cron        41943040

These have not been touched in over a year but still count against the quota.

5. Large or duplicated layers

Layer versions also count, and a heavy layer republished repeatedly adds up.

aws lambda list-layers --query 'Layers[].LatestMatchingVersion.[LayerVersionArn,Description]' --output text

arn:aws:lambda:us-east-1:REDACTED:layer:pandas-numpy:41	big data layer

Version 41 means 40 older layer versions may still be stored.

Diagnostic Workflow

Step 1: Confirm you are actually at the quota

aws lambda get-account-settings \
  --query '{used:AccountUsage.TotalCodeSize, limit:AccountLimit.TotalCodeSize, funcs:AccountUsage.FunctionCount}' \
  --output json

If used is at or near limit, this is a genuine quota exhaustion, not a per-function issue.

Step 2: Rank functions by stored size and version count

for fn in $(aws lambda list-functions --query 'Functions[].FunctionName' --output text); do
  n=$(aws lambda list-versions-by-function --function-name "$fn" --query 'length(Versions)' --output text)
  echo "$n	$fn"
done | sort -rn | head

The functions with the most versions are usually where the reclaimable space is.

Step 3: Identify which versions are actually referenced

aws lambda list-aliases --function-name checkout-api \
  --query 'Aliases[].[Name,FunctionVersion]' --output text

Any version not pointed to by an alias (and not $LATEST) is a candidate for deletion.

Step 4: Check for abandoned functions and layers

aws lambda list-functions --query 'Functions[?LastModified<`2025-06-01`].FunctionName' --output text
aws lambda list-layers --query 'Layers[].LayerName' --output text

Old functions and stacked layer versions are additional reclaimable storage.

Example Root Cause Analysis

A team’s SAM pipeline that published a version on every merge began failing every deploy with CodeStorageExceededException. No single function was large.

Account settings confirmed the account was pinned at the 75 GB limit:

aws lambda get-account-settings --query 'AccountUsage.TotalCodeSize' --output text

80530636800

Version counts revealed the cause — the pipeline never pruned versions, so a dozen functions had 150–250 retained versions each:

aws lambda list-versions-by-function --function-name checkout-api --query 'length(Versions)' --output text

214

Only the versions behind the live and previous aliases were in use; the other ~210 were dead weight. Deleting every unaliased, non-$LATEST version across the account reclaimed tens of gigabytes and deploys resumed. The durable fix was a pipeline post-step that keeps only the last N versions:

aws lambda list-versions-by-function --function-name checkout-api \
  --query 'Versions[?Version!=`$LATEST`].Version' --output text | tr '\t' '\n' | sort -n | head -n -5 \
  | xargs -I{} aws lambda delete-function --function-name checkout-api:{}

Prevention Best Practices

• Add a CI post-deploy step that prunes old function versions, keeping only the last few plus any alias-referenced versions.
• Alarm on AccountUsage.TotalCodeSize approaching the AccountLimit, so you reclaim before deploys fail.
• Keep deployment packages lean — externalize heavy dependencies into shared layers, drop dev dependencies, and use container images for very large payloads.
• Delete functions for decommissioned services promptly; a dead function still consumes the quota with all its versions.
• Prune old layer versions too, and request a code-storage quota increase via Service Quotas when the workload legitimately needs more.

Quick Command Reference

# Account code-storage usage vs limit
aws lambda get-account-settings \
  --query 'AccountUsage.TotalCodeSize,AccountLimit.TotalCodeSize' --output text

# Version count per function (find the worst offenders)
aws lambda list-versions-by-function --function-name <fn> --query 'length(Versions)' --output text

# Which versions are aliased (keep these)
aws lambda list-aliases --function-name <fn> --query 'Aliases[].FunctionVersion' --output text

# Delete old, unaliased versions keeping the last 5
aws lambda list-versions-by-function --function-name <fn> \
  --query 'Versions[?Version!=`$LATEST`].Version' --output text | tr '\t' '\n' | sort -n | head -n -5 \
  | xargs -I{} aws lambda delete-function --function-name <fn>:{}

# Request a quota increase
aws service-quotas request-service-quota-increase \
  --service-code lambda --quota-code L-2ACBD22F --desired-value 150000

Conclusion

CodeStorageExceededException means the account’s per-region Lambda code-storage quota is full. The usual root causes:

1. Accumulated old function versions from per-commit publishing.
2. The account sitting at the 75 GB TotalCodeSize limit.
3. Oversized deployment packages multiplied across versions.
4. Abandoned functions never deleted.
5. Stacked, heavy layer versions.

Confirm usage with get-account-settings, prune unaliased old versions and dead functions to reclaim space, keep packages lean, and automate version cleanup in CI (raising the quota only when the workload genuinely needs it).