Which strategy should I use for AWS Lambda Python 3.9 Runtime Migration Before Update Block on September 30,?

Plan a Python 3.9 to 3.11 or 3.12 Lambda migration before AWS blocks function creates and updates in late 2026, including dependency, layer, and native-library compatibility.

Move Python 3.9 functions to Python 3.11 first unless you've already validated layers, wheels, and native libs on 3.12 and want one migration that lasts.

Blockers

Who this is for

Candidates

Move Python 3.9 functions to Python 3.11 first

AWS lists Python 3.9 on Lambda as deprecated on December 15, 2025, with create blocked on August 31, 2026 and updates blocked on September 30, 2026. As of 2026-04-09, Python 3.11 remains supported on Amazon Linux 2 until June 30, 2027, with create blocked on July 31, 2027 and updates blocked on August 31, 2027. This is the lower-blast-radius path when your current functions, layers, and native wheels were built for Amazon Linux 2. It keeps the OS family the same while still getting off the expiring Python 3.9 runtime.

When to choose

Use this when you need the fastest safe migration off Python 3.9 and have layers or dependencies already validated on Amazon Linux 2. It is the practical choice if your main risk is native-package rebuild work rather than runtime longevity.

Tradeoffs

Lower migration risk now because Python 3.11 stays on Amazon Linux 2, but it only buys about one more year before the next Lambda create and update blocks in 2027.

Cautions

Package all dependencies explicitly, including Boto3, because Lambda updates the runtime-included SDK and mixing your own urllib3 or other SDK dependencies with the runtime copy can break functions. Rebuild any layer with the same Python version as the target runtime, and ensure native wheels match Linux plus the function architecture. No runtime-specific Lambda price delta was verified in this search pass; check official Lambda pricing docs for your region.

Move directly from Python 3.9 to Python 3.12

As of 2026-04-09, Python 3.12 on Lambda runs on Amazon Linux 2023 and stays supported until October 31, 2028, with create blocked on November 30, 2028 and updates blocked on January 10, 2029. This gives materially more runway than Python 3.11 and aligns with AWS guidance to upgrade to Amazon Linux 2023-based runtimes as soon as possible because Amazon Linux 2 reaches end of life on June 30, 2026. Python 3.12 also changes Lambda JSON response behavior to return unescaped Unicode characters, and it improves graceful shutdown behavior for functions with external extensions. The migration is bigger because native dependencies and layers may need rebuilding for the Amazon Linux 2023 environment.

When to choose

Use this when you want one migration instead of a short-term stopgap and you can retest layers, wheels, and downstream callers now. It is the better choice when long support runway and Amazon Linux 2023 alignment matter more than minimizing immediate change.

Tradeoffs

Best support horizon and OS modernization, but higher compatibility risk because compiled packages may need rebuilding for Amazon Linux 2023 and Python 3.12 behavior differs from 3.11 in response encoding.

Cautions

Amazon Linux 2023-based Python runtimes use a newer GLIBC baseline than Amazon Linux 2, so binary packages built for older assumptions may fail unless rebuilt in a Lambda-compatible environment. Build layers with the same Python version as the target runtime and ensure they declare compatible runtimes and the correct architecture. If callers expect escaped Unicode in JSON responses, update either the function or the caller before cutover. No runtime-specific Lambda price delta was verified in this search pass; check official Lambda pricing docs for your region.

Facts updated: 2026-04-09
Published: 2026-04-10

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Which strategy should I use for AWS Lambda Python 3.9 Runtime Migration Before Update Block on September 30,?"
Missing something? Request coverage