What it means
Lambda gives each account a per-region budget for stored function code — 75 GB by default — and that budget covers every version of every function, not just the current one. Publishing a version takes a permanent snapshot of the deployment package at that moment. Nothing expires it. Nothing garbage-collects it. It is there until someone deletes it.
That makes this the most predictable outage in the whole index. Any pipeline that publishes a version on every merge is accumulating storage monotonically, and the date it runs out is arithmetic: package size, times deployments per week, against the quota. It is invisible for a year or two and then stops all deployments across the entire region at once — because the quota is per account and region, not per function.
The scale is easy to underestimate. A modest 50 MB package deployed twenty times a week reaches a gigabyte a year from one function. A 200 MB package — quite ordinary for anything with a heavy dependency tree — reaches the same in a couple of months. Multiply across a service with a few dozen functions and 75 GB stops sounding generous.
Cleanup is straightforward but has one genuine hazard: aliases. Deleting a version an alias points at breaks every caller that invokes through that alias, and it does so immediately. Any script that prunes versions has to read the aliases first and exclude what they reference — which the snippet above does, and which is the part most one-liners found online omit.
None of this touches CloudWatch Logs. The functions already deployed keep running exactly as before; what fails is your ability to deploy anything new. The error exists only in the deployment's own output, which is why it tends to arrive as a complete surprise during an urgent release.
Where you'll see it
Deployment output
Not in CloudWatchThis failure happens before the function runs, so nothing about it reaches CloudWatch Logs — there is no invocation, and no log group entry to find. Once the deployment succeeds and the function starts running, the rest of this index covers what you will see there.
Causes, most likely first
Published versions accumulate and are never deleted
List versions for your busiest functions and count them. A pipeline that publishes a version on every merge produces hundreds per function per year, and every one retains a full copy of its deployment package. Nothing removes them automatically.
Packages are large and the version count multiplies them
Multiply a function's package size by its version count. A 200 MB package with 300 versions is 60 GB from one function — most of an entire account's quota, from a single service that looks unremarkable in the console.
A deleted function's versions are still counted until the function is deleted
Check for functions that are no longer used but were never removed. Deleting an alias or leaving a function idle frees nothing; storage is released when the versions or the function are deleted.
Container images are stored in ECR and are not the cause
Check whether the account's large functions are zip- or image-packaged. Image-based functions consume ECR storage, not this quota, so a mixed account can look enormous while the actual pressure comes from a few zip functions.
Fixes
Delete old versions, keeping the ones an alias points at
This is the immediate relief. The important part is not deleting a version that an alias still references — doing so breaks whatever invokes through that alias, so the aliases have to be read first rather than assumed.
bashFN=orders-fn
KEEP=$(aws lambda list-aliases --function-name "$FN" \
--query 'Aliases[].FunctionVersion' --output text)
aws lambda list-versions-by-function --function-name "$FN" \
--query 'Versions[?Version!=`$LATEST`].Version' --output text |
tr '\t' '\n' | sort -n | head -n -5 |
while read -r V; do
case " $KEEP " in *" $V "*) continue ;; esac
echo "deleting $FN:$V"
aws lambda delete-function --function-name "$FN" --qualifier "$V"
done
Find where the storage has actually gone
Before deleting anything, find the functions responsible. It is usually a small number of them, and the totals are rarely where people expect.
bashaws lambda list-functions \
--query 'Functions[].{Name:FunctionName,Size:CodeSize}' --output text |
sort -k2 -rn | head -20
Stop publishing a version on every deployment
Versions are needed for aliases, gradual deployments and rollback. Publishing one on every merge regardless of whether anything references it is what fills the quota — publish when you will actually use the version.
Request a quota increase when the usage is legitimate
The 75 GB default is adjustable. Where a large account genuinely needs more, raising it is reasonable — but do the cleanup first, because an account that fills 75 GB with unreferenced versions will fill a larger quota the same way.
bashaws service-quotas get-service-quota \
--service-code lambda --quota-code L-2ACBD22F
Also seen as
The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.
Related errors
Errors that show up alongside this one, or that people mistake for it.
References
This one happens before there are any logs.
LogStitch reads CloudWatch, and a deployment that fails never writes to it — so this is not an error it can find for you. Once the function deploys and starts running, the free web stitcher groups its invocations in your browser, and the Mac app does the same across every function in your account.