Lambda runtime deprecations in late 2026 - python3.10, dotnet8, provided.al2 and nodejs20.x: find affected functions and upgrade

#Dates that matter now

From the Lambda runtimes page (dates can move; check the page before planning):

What deprecation means:

• AWS stops applying security patches to the runtime, and the functions lose technical support.
• From the deprecation date you can't create or update functions on that runtime in the console; the CLI, SAM and CloudFormation still work until the block dates.
• After block update, you can still change the function to a supported runtime, but you may not be able to roll back.

Many older blog posts quote earlier block dates for nodejs20.x and python3.9 (August/September 2026). The current table shows July/August 2027.

#1. Find affected functions in every region

for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  aws lambda list-functions --region "$r" \
    --query "Functions[?contains(['python3.9','python3.10','nodejs18.x','nodejs20.x','dotnet8','provided.al2'], Runtime)].[FunctionName,Runtime,LastModified]" \
    --output text | sed "s/^/$r\t/"
done

list-functions returns $LATEST. Published versions that aliases still point at can run an older runtime. Use Trusted Advisor's AWS Lambda Functions Using Deprecated Runtimes check, which includes published versions, or run list-versions-by-function for important functions.

Across an organisation, run the loop per account with a read-only role, or use AWS Config advanced queries on AWS::Lambda::Function with configuration.runtime.

Container image functions don't show a runtime here. Check their base image tags (public.ecr.aws/lambda/python:3.10 and so on) in your Dockerfiles. AWS doesn't send deprecation notices for container images.

#2. Pick the target

AL2023 runtimes use a different OS image: no yum (it's dnf), different system library versions, and a smaller base. Functions that shell out to OS tools or ship native libraries need the most testing.

#3. Upgrade safely

# 1. update runtime on $LATEST
aws lambda update-function-configuration --function-name orders-api --runtime python3.13
aws lambda wait function-updated --function-name orders-api

# 2. deploy code built for the new runtime, then publish a version
aws lambda update-function-code --function-name orders-api --zip-file fileb://build.zip --publish

# 3. shift a small share of traffic to the new version
aws lambda update-alias --function-name orders-api --name live \
  --function-version 7 --routing-config 'AdditionalVersionWeights={"6"=0.9}'

Here version 6 (old) keeps 90% and version 7 (new) gets 10%. Watch errors and duration on the alias, then move to 100%. Keep the old version until you're confident; it still runs on the old runtime.

Update your IaC (SAM, CDK, Terraform) in the same change, or the next deployment will set the old runtime again.

#4. Stop it happening again

• Add a CI check that fails a build when a template uses a runtime within six months of deprecation.
• Route AWS Health scheduled-change events to the owning team (see AWS Health scheduled changes with EventBridge).

#Checklist

• Inventory across all accounts and regions, including published versions and container images
• Target runtime chosen per function; native dependencies rebuilt for AL2023
• Upgrades rolled out through aliases with weighted traffic
• IaC updated to the new runtime
• CI guard for runtimes near deprecation

#Sources

• AWS Lambda: Lambda runtimes (supported and deprecated tables)