AWS will drop Python 3.10 support on Lambda after October 31, 2026

What AWS is doing

AWS has set October 31, 2026 as the deprecation date for the Python 3.10 runtime on Lambda, according to a post on dev.to. Functions still using the runtime will keep executing past that date, but they will no longer receive security patches, and the AWS console will stop allowing edits to them.

The timeline hardens further in 2027. On July 29, 2027, AWS will block the creation of new Python 3.10 functions, and on August 31, 2027, updates to existing ones will be blocked as well, the post explains. The net effect is that the runtime becomes frozen: runnable, but unmaintainable.

Why the runtime is being retired

The dev.to write-up links AWS's move to the upstream Python release cycle. Once a Python version reaches end-of-life and stops receiving maintainer patches, AWS will not keep supporting a runtime with no upstream source of fixes. Python 3.10's exit therefore follows a mechanical pattern rather than an arbitrary decision: no upstream patches leads AWS to drop support, which in turn leaves users carrying the security risk.

What breaks in Python 3.12

The article emphasizes that jumping from 3.10 to 3.12 or newer is not a simple version bump. Three classes of breakage stand out:

• distutils is gone in Python 3.12. Older setup.py scripts and libraries that import it will fail with a ModuleNotFoundError. The suggested fix is to move to setuptools or the packaging library.
• The standard-library modules cgi, crypt and telnetlib, removed under PEP 594, disappear in Python 3.13. Code depending on them has to be rewritten around modern alternatives; the post points to hashlib as a stand-in for crypt.
• Hidden transitive dependencies can bite. The article calls out scikit-learn versions below 1.3 as examples of libraries that pull in distutils indirectly and then break, so pinned dependencies may need updating even when your own code is clean.

The Amazon Linux 2023 shift

The less obvious hazard, according to the post, is the operating system change underneath the runtime. Python 3.12 and later on Lambda run on Amazon Linux 2023 rather than Amazon Linux 2. Because AL2023 ships a newer glibc, compiled wheels and layers built for AL2, with numpy, psycopg2 and cryptography named as typical examples, can fail at runtime with import errors or segmentation faults. Anything with compiled dependencies needs to be rebuilt for AL2023.

Python 3.11 is not a way out

Python 3.11 might look like a lower-effort stopgap, but the post argues against it. The 3.11 runtime still runs on AL2 and is itself scheduled for deprecation on June 30, 2027, so teams that move to it will face the same operating-system migration shortly afterwards. Going directly to 3.12 or newer avoids doing the work twice.

Finding affected functions

To inventory what needs migrating, the article suggests a one-liner against the AWS CLI: aws lambda list-functions --function-version ALL --query "Functions[?Runtime=='python3.10'].FunctionName,Version" --output text

That returns every function, across all published versions, still pinned to python3.10, which is the natural starting point for a migration inventory.

Why it matters

Serverless functions have a reputation for being low-maintenance, which is exactly why runtime deprecations are dangerous: workloads nobody has touched in years quietly keep running on old runtimes. After October 31, 2026, every unaddressed CVE in the Python 3.10 stack becomes a permanent, unfixable weakness in those functions, and the console edit block means even quick hotfixes get harder. The later creation and update blocks turn a slow-burn security problem into a hard operational wall for CI/CD pipelines. Teams running Python on Lambda should inventory their functions now, budget time for rebuilding compiled layers against Amazon Linux 2023, and treat the 2026 deadline as the real cutoff rather than waiting for the 2027 API blocks.