Run the Lambda list-functions command with all versions included and filter on the runtime identifier. Repeat it per region and per account, then rank the results by recent invocations. AWS Trusted Advisor and AWS Config can also list affected functions across many regions or accounts.
Step 1: Decide which runtimes to hunt
Start from the AWS supported runtimes table, which lists deprecation dates, plus the block create and block update dates. At the time of writing it shows Node.js 20 and Python 3.9 as already deprecated, and Python 3.10 with a deprecation date of 31 October 2026. Check the table again before you act, because AWS says its dates are for planning and subject to change.
Step 2: List the functions
The AWS documentation gives this command. It includes every published version, not just $LATEST:
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='python3.10'].FunctionArn"
Three caveats from the same page:
- Run it once per region where you have functions, and once per account.
- Omit the all-versions flag if you want just $LATEST.
- It does not return Lambda Web Functions, and container image functions have no runtime field to match, since you choose the base image yourself.
Step 3: Use the account level tools
AWS sends an email, a Health Dashboard notice and a Trusted Advisor check at least 180 days before a runtime is deprecated. The emails and dashboard list $LATEST versions. Trusted Advisor lists both $LATEST and published versions and updates as your functions change. AWS Config advanced queries can aggregate across regions and accounts, but return $LATEST only.
Step 4: Rank by what is actually used
Not every function deserves the same urgency. The AWS page suggests checking the last invocation time from the CloudWatch log group and counting invocations over the last 14 days. A function nobody calls is a candidate for deletion, which removes the problem entirely.
| Signal | What it tells you | Action |
|---|---|---|
| Invoked in the last 14 days, high count | Live dependency | Upgrade first |
| Invoked rarely | Lower exposure, still reachable | Schedule the upgrade |
| No invocations, old log streams | Likely dead code | Confirm owner, then delete |
Step 5: Do not forget old versions and container images
Published versions are immutable, so an old version can sit on a deprecated runtime after you upgrade $LATEST. For container image functions, AWS notes that deprecation notifications are not available, so track base image support dates yourself.
Step 6: Plan the upgrade with a rollback
AWS recommends testing with the new runtime first and using versions and aliases for safe deployment with rollback. Once updates are blocked you cannot return to the deprecated runtime, so keep your test window before that date.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how findings are grouped and ranked. A runtime inventory deserves the same treatment as a vulnerability list.
Quick check
Will AWS stop my function when its runtime is deprecated?
No. AWS says you can keep invoking functions on a deprecated runtime indefinitely, but it may stop applying security patches, and creating or updating functions is eventually blocked.
Does Trusted Advisor cover old published versions?
Yes. The AWS documentation says the Trusted Advisor list shows both $LATEST and published versions, while the email and Health Dashboard lists show $LATEST.
Safeguard's asset discovery and SBOM scanning can help you keep an inventory of what you deploy, and a free scan is available at gold.safeguard.sh/scan.
Sources
- AWS Lambda runtimes
- Retrieve data about functions that use a deprecated runtime
- Manage Lambda function versions
Last reviewed: 19 October 2026.
