What it means
AWS supports each managed runtime for a defined period and then retires it in stages. The stage this error belongs to is the one where existing functions continue to run untouched, but the control plane stops accepting create and update calls for that runtime. Your code keeps serving traffic; you simply cannot change it.
That combination is what makes this land badly. Nothing fails on the deprecation date. Metrics stay flat, no alarm fires, and the function carries on exactly as before — so a team with no process for tracking runtime end-of-support has no reason to notice. The failure arrives later, the first time somebody tries to deploy, and by construction that is often during an incident, against the one function they most urgently need to fix.
The migration itself is rarely a single line. Moving from nodejs16.x to a current runtime skips several major Node versions, and the AWS SDK situation changes with them: v2 is no longer present in modern runtimes, so any code doing require('aws-sdk') compiles fine, deploys fine, and fails on its first invocation with an import error. Python migrations hit the equivalent problem where standard-library modules have been removed between versions. Both of those are runtime failures that appear after a successful deployment, which is why testing against the target runtime's base image before switching is worth the extra step.
There is one detail worth being precise about, because it changes how much time you have. Blocking updates is not the last stage — AWS eventually blocks invocations too, on a separate, later date. Being unable to deploy is the warning shot. If you are reading this because a deployment failed, the function is still serving traffic, and that is the window to migrate in.
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 runtime reached end of support and nobody was watching the date
Compare the function's configured runtime against AWS's deprecation schedule. Every managed runtime has a published end-of-support date, and the transition is not announced by anything in your own tooling — the first signal most teams get is a deployment failing.
An infrastructure template pins the old runtime explicitly
Search your templates for the runtime string. It is usually written once per function and copied forward for years, so a repository can contain dozens of references to a runtime nobody has thought about since it was current.
A base container image is pinned to a deprecated tag
Check the FROM line for image-packaged functions. The same deprecation applies to the AWS base images, and a Dockerfile pinned to an old tag hits this at build or deploy time rather than in the function configuration.
Only some functions were migrated
List every function in the account by runtime rather than checking the ones you remember. A migration that covered the actively-developed services routinely misses the quiet ones, which are exactly the functions nobody touches until something breaks.
Fixes
Find every function on a deprecated runtime, account-wide
Do this before migrating anything. The list is almost always longer than expected, and knowing its size decides whether this is an afternoon or a project.
bashaws lambda list-functions \
--query 'Functions[].{Name:FunctionName,Runtime:Runtime}' --output text |
sort -k2 | awk '{ print $2, $1 }'
Move the runtime forward in the template, not the console
Changing it in the console works and is undone by the next deployment. The runtime belongs in the same place as the rest of the function's configuration.
yamlResources:
WebhookFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: nodejs22.x # was nodejs16.x
Handler: index.handler
Test the upgrade rather than assuming it is a version bump
A runtime jump crosses several major language versions at once and brings real changes with it — on Node, the AWS SDK moved from v2 to v3 and is no longer bundled in the old form; on Python, several standard-library modules have been removed. Both surface as an import failure on the first invocation after deploying, not at deploy time.
bash# The AWS base image for the target runtime is the environment your
# function will actually execute in.
docker run --rm --platform linux/amd64 \
-v "$PWD":/var/task \
public.ecr.aws/lambda/nodejs:22 \
node --check /var/task/index.js
Migrate before you need to, not during an incident
The reason this error is disruptive is timing. Nothing breaks on the deprecation date, so it goes unnoticed — and then it is discovered while trying to ship a fix to the very function that cannot be updated. Treat the published end-of-support dates as deadlines with lead time rather than as warnings.
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
- AWS Lambda Developer Guide — Lambda runtimes and deprecation schedule
- AWS Lambda Developer Guide — Troubleshoot deployment issues
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.