Lambda Python 3.10 Is Deprecated Today: Find Every Function and Move to 3.13

As of October 31, 2026, the Lambda python3.10 runtime is deprecated: AWS may stop applying security patches, the functions lose technical support, and you can no longer edit them in the console. They keep running. Creating new python3.10 functions is blocked from July 29, 2027 and updating them from August 31, 2027, so the move to python3.13 starts now.

What happened, and what did not

Lambda deprecates a runtime when a major component reaches end of community support. For python3.10 that is the language itself, on top of Amazon Linux 2, which reached end of life on June 30, 2026. AWS kept patching critical and selected important AL2 issues for the AL2-based runtimes until each runtime's own deprecation date. For Python 3.10 that date was today.

What deprecation means, per AWS's runtime page: AWS "may no longer apply security patches or updates," functions are "no longer eligible for technical support," and console create and edit stop. You can still deploy through the CLI, SAM and CloudFormation until the block dates. AWS also warns that deprecated runtimes "may also experience degraded performance or other issues, such as a certificate expiry." That last clause is the one that bites quietly: a CA bundle that never gets refreshed.

Python 3.10 is not alone on the old base. The AL2 schedule, as of October 2026:

Fix the python3.11 functions in the same pass: same AL2023 gotchas, eight months later.

Step 1: find every function, in every region and account

The AWS email and the Health Dashboard list only $LATEST versions. Trusted Advisor's "AWS Lambda Functions Using Deprecated Runtimes" check includes published versions, but you still need it per account. The CLI query from AWS's own docs, wrapped in a region loop:

# Every version on python3.10 or python3.11, every region in this account
$ for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
    aws lambda list-functions --function-version ALL --region "$r" --output text \
      --query "Functions[?Runtime=='python3.10' || Runtime=='python3.11'].[FunctionArn, Runtime]"
  done

# Across an organization: AWS Config advanced query against an aggregator ($LATEST only)
$ aws configservice select-aggregate-resource-config \
    --configuration-aggregator-name org-aggregator \
    --expression "SELECT accountId, awsRegion, resourceName, configuration.runtime \
      WHERE resourceType = 'AWS::Lambda::Function' AND configuration.runtime = 'python3.10'"

The query misses container image functions, which have no Runtime field, so grep Dockerfiles for public.ecr.aws/lambda/python:3.10. Then prioritize: AWS's guide suggests pulling 14 days of Invocations so busy functions go first and dead ones get deleted, not migrated.

Step 2: the IaC diff is one line, the rebuild is not

Changing the identifier is trivial in every tool:

# template.yaml (SAM)
Globals:
  Function:
    Runtime: python3.13   # was python3.10
    AutoPublishAlias: live

In CDK it is runtime: lambda.Runtime.PYTHON_3_13; in Terraform, runtime = "python3.13" on aws_lambda_function and the same value in compatible_runtimes on every aws_lambda_layer_version the function uses. Pick python3.13 if any dependency still lacks 3.14 wheels; otherwise python3.14. Both carry the same June 30, 2029 deprecation date, so 3.14 buys no extra lifetime, only newer language features.

The trap is that the line looks complete. It is not, because every compiled dependency in your zip or layer was built for CPython 3.10.

Step 3: what breaks moving from AL2 to AL2023

Native wheels built for 3.10. AWS's layer docs say to build the layer with the same Python version the function uses. A pydantic-core, numpy or cryptography wheel carries a cp310 ABI tag and will not import on 3.13. You get a cold-start failure in the form Runtime.ImportModuleError: Unable to import module 'lambda_function': .... Rebuild, from a Linux-compatible wheel set:

$ pip install -r requirements.txt --platform manylinux2014_x86_64 \
    --only-binary=:all: --python-version 3.13 -t python/
$ zip -r layer.zip python/
$ aws lambda publish-layer-version --layer-name deps-py313 \
    --zip-file fileb://layer.zip --compatible-runtimes python3.13

Use manylinux2014_aarch64 for arm64 functions; the arm64 side has its own native-library surprises, which we went through in what broke in our Graviton migration.

No yum in container images. AL2023-based Lambda images use microdnf (symlinked as dnf). A Dockerfile that runs yum install on top of python:3.10 fails on python:3.13 with /bin/sh: yum: command not found. Change the package manager, and check package names: the AL2023 minimal image ships far fewer packages.

Missing shared libraries. A layer that bundles a binary, or dlopens something AL2 shipped by default, can fail with error while loading shared libraries: ... cannot open shared object file: No such file or directory. AL2023 moves glibc from 2.26 to 2.34, which helps wheels, but the slimmer base image means you vendor what you used to inherit.

Behavior changes from Python itself. Python 3.12 and later Lambda runtimes return Unicode characters unescaped in JSON responses, where 3.11 and earlier returned \u escapes. A caller comparing raw bytes will notice. Also, from Python 3.11 the runtime-included boto3 lives in /var/lang/lib/python3.x/site-packages, not /var/runtime. Your zip and layers still take precedence over it, so if you bundle an SDK dependency such as urllib3, bundle boto3 too, as AWS recommends, or the runtime's SDK and your copy drift apart.

Step 4: roll out with versions and aliases, not in place

AWS recommends versions and aliases for exactly this, because after August 31, 2027, "rolling back to the deprecated runtime may be blocked." Publish the 3.13 build as a new version and shift a slice of traffic with a weighted alias first. Our first Lambda deploy walkthrough covers the basics.

$ aws lambda publish-version --function-name orders-api        # say this returns 8; 7 is the 3.10 build
$ aws lambda update-alias --function-name orders-api --name live \
    --function-version 7 --routing-config 'AdditionalVersionWeights={"8"=0.1}'
# watch Errors and Duration for alias "live", then:
$ aws lambda update-alias --function-name orders-api --name live \
    --function-version 8 --routing-config 'AdditionalVersionWeights={}'

Watch init duration too, since rebuilt layers change package size; our notes on measuring Lambda cold starts cover what to graph.

Where this breaks

Weighted aliases do not help functions invoked through $LATEST; those cut over on the next deploy with no canary. Functions owned by third-party stacks may need the vendor to ship a new template. And python3.15 is in public preview today with GA targeted for November 2026: preview runtimes are not covered by the Lambda SLA, so do not jump straight to it for production.

Questions people ask

Will my python3.10 Lambda functions stop working on October 31, 2026?

No. AWS says you can keep invoking functions on a deprecated runtime indefinitely. What stops is security patching, technical support and console editing. You can still update code and configuration through the CLI, SAM or CloudFormation until August 31, 2027, and create new python3.10 functions until July 29, 2027. The risk grows over time: unpatched OS libraries and expiring certificates.

Should I move to python3.12, 3.13 or 3.14?

Use python3.13 or python3.14. Both run on Amazon Linux 2023 and are supported until June 30, 2029, while python3.12 is deprecated on October 31, 2028. Choose 3.13 if a compiled dependency has no 3.14 wheel yet. Avoid python3.15 for production until it leaves public preview, which AWS targets for November 2026.

Why does my Lambda layer fail to import after changing the runtime?

Compiled packages are built for one CPython version. A layer built for Python 3.10 contains cp310 extension modules that Python 3.13 cannot load, which surfaces as Runtime.ImportModuleError on cold start. Rebuild the layer with pip using the matching --python-version and a manylinux platform tag, publish it as a new layer version, and point the function at it.

The call we'd make

Run the region loop today, delete what has had zero invocations in 14 days, and move the rest to python3.13 with rebuilt layers behind weighted aliases, taking python3.11 along in the same change. The caveat: if a function is a container image you rebuild from your own base, the runtime table does not apply to you, and the real deadline is whenever your base image stops getting patches.

Sources

• AWS Lambda runtimes and deprecation schedule
• Retrieve data about Lambda functions that use a deprecated runtime
• Deploy Python Lambda functions with container images
• Comparing AL2 and AL2023