What it means
Lambda validates configuration parameters against fixed ranges before applying anything, and rejects the whole call when one is outside its bounds. Nothing is changed; the function keeps its previous configuration and carries on running.
The message is unusually complete. It names the parameter, the value you sent, and the exact bound that was violated — which means the fix requires no investigation at all. That is rare enough in this index to be worth saying.
There is one trap, and it is a historical one. The bounds have moved. Lambda's memory maximum was 3,008 MB for years before rising to 10,240 MB, and ephemeral storage was fixed at 512 MB before becoming configurable to 10 GB. A great many articles, cached Stack Overflow answers and — as the canonical message on this page shows — error texts from older accounts still quote the old numbers. If you are reading a bound from anywhere other than the error you just received, check it.
The other case worth knowing is an account quota that sits below the service maximum. A value inside the documented range can still be rejected because the account has not had its limits raised, which produces a template that deploys in one account and fails in another with nothing different about it. Service quotas are adjustable where the service limits are not, so distinguishing the two decides whether you change the template or file a request.
None of this appears in CloudWatch Logs. The configuration call fails, the existing function is untouched, and the only record is the API response.
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
The value exceeds the current maximum
Compare the number you sent against the bound in the message. Memory tops out at 10,240 MB and timeout at 900 seconds; ephemeral storage also caps at 10,240 MB. A value copied from a template written for a different service is the usual route in.
The value is below the minimum
Check for a bound phrased as "greater than or equal to". Memory has a floor of 128 MB, and a computed value — a fraction of some other setting, or a variable that resolved to zero — lands under it.
The account's quota is lower than the service maximum
Check the account's concurrency and memory quotas. A new account can have lower limits than the documented service maximum, so a value that is valid in one account is rejected in another with no difference in the template.
The bound in an old error or article is out of date
Note the number quoted in the message rather than trusting a remembered limit. Lambda's memory ceiling has risen over time — 3,008 MB was the maximum for years and is still what many articles and cached errors quote — so an error text found by searching may cite a bound that no longer applies.
Fixes
Read the bound out of the message and use it
The API tells you the parameter and the limit. This is one of the few errors where the fix is fully specified by the error itself.
yamlResources:
ReportFunction:
Type: AWS::Serverless::Function
Properties:
MemorySize: 10240 # maximum; minimum is 128
Timeout: 900 # maximum, in seconds
EphemeralStorage:
Size: 10240 # maximum; default 512
Check the account's quotas when the value looks legal
Where the value is inside the documented range and still rejected, the account's own quota is lower than the service maximum. That is adjustable, unlike the service limits.
bashaws service-quotas list-service-quotas --service-code lambda \
--query 'Quotas[].{Name:QuotaName,Value:Value}' --output table
Validate computed values before sending them
When a setting is derived rather than written literally, clamp it. A value computed from another variable is the version of this that appears intermittently.
bashMEM=$(( BASE_MEMORY * REPLICAS ))
if [ "$MEM" -lt 128 ] || [ "$MEM" -gt 10240 ]; then
echo "MemorySize ${MEM} is outside 128..10240" >&2
exit 1
fi
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.