Python 3.10 end of life: why Lambda's dates keep moving

Python 3.10 end of life arrived on 1 October 2026, when PEP 619 recorded that 3.10.22 "was the final security release". AWS Lambda deprecates the python3.10 runtime on 31 October, yet still lets you create functions on it until 29 July 2027. By the end of this post you will know which dates are real, why the pages you find disagree, and which version to move to.

The surprising part is not the deadline. It is that AWS has rewritten the python3.10 schedule at least three times in ten months, and the gap between "unsupported" and "blocked" is now almost a year. That gap is where unpatched code lives.

Python 3.10 end of life: the dates that actually apply

Two bodies set dates here, and they set different things. The Python Software Foundation decides when CPython stops getting fixes. AWS decides when its managed runtime stops getting patches and when it stops accepting deployments. As of 26 October 2026, the primary sources say this:

Event	Date	Source
Final CPython 3.10 release (3.10.22)	1 October 2026	PEP 619
CPython 3.10 end of life	1 October 2026	Python devguide
Lambda python3.10 deprecated	31 October 2026	Lambda runtimes
Lambda blocks new python3.10 functions	29 July 2027	Lambda runtimes
Lambda blocks python3.10 code and config updates	31 August 2027	Lambda runtimes

PEP 619 is blunt about what end of life means upstream: the 3.10 codebase "is now frozen and no further updates will be provided nor issues of any kind will be accepted on the bug tracker." Security releases since 3.10.12 in June 2023 were source-only, so if you have been running 3.10 from a vendor build, your patch stream already depended on that vendor.

Why the python3.10 Lambda dates you find disagree

If a blog or tracker gives you different block dates, it may not be wrong so much as stale. Archived copies of the AWS runtimes page show the python3.10 row changing repeatedly:

AWS page as captured	Deprecation	Block create	Block update
26 December 2025	30 Jun 2026	31 Jul 2026	31 Aug 2026
15 April 2026	31 Oct 2026	30 Nov 2026	15 Jan 2027
17 September 2026	31 Oct 2026	1 Feb 2027	3 Mar 2027
26 October 2026 (live)	31 Oct 2026	29 Jul 2027	31 Aug 2027

So a forum post quoting a February and March 2027 cut-off was accurate when written. AWS explains the pattern in its own policy: for some runtimes it is "delaying the block-function-create and block-function-update dates beyond the usual 30 and 60 days after deprecation" in response to customer feedback, and it "will not start blocking function creates or updates before the dates given in these tables" (AWS). Note what that promise does not say: the dates can move later, and in every archived version we checked, they did. Plan against the live table, not a screenshot of it.

Watch for one more mislabel. Some trackers present 31 August 2027 as the end of support. It is not. Support, meaning patches and technical support, ends at deprecation on 31 October 2026. The August date is only when deployments stop.

What happens to Lambda functions on python3.10 after 31 October

On the deprecation date, AWS says it "may no longer apply security updates or other updates," functions "are no longer eligible for technical support," and you "can no longer create or update functions using the deprecated runtime in the Lambda console." You can still create and update them "through the AWS CLI, AWS SAM, or CloudFormation" (Lambda runtime deprecation policy). Invocation never stops: "you can continue to invoke your functions indefinitely."

That is why this deadline is easy to miss. Pipelines keep deploying, nothing fails, and the only visible change is in the console. Two things make the quiet period worse than it sounds:

• The base OS is already past its own end. AWS states that Amazon Linux 2 was scheduled for end of life on 30 June 2026, and that the python3.10 and python3.11 runtimes get only "critical and selected important" Amazon Linux 2 patches until their deprecation dates.
• Rollback disappears on 31 August 2027. After updates are blocked you can still move a function to a supported runtime, but "rolling back to the deprecated runtime may be blocked" (AWS). AWS recommends function versions and aliases so a bad upgrade can be reverted without the old runtime.

Container-image functions get no warning at all: "Deprecation notifications are not available for functions using container images" (AWS). If you deploy python3.10 as a container image, you are responsible for noticing.

How to find every Lambda function on a deprecated runtime

AWS sends an email and a Health Dashboard notice at least 180 days before deprecation, and lists affected functions in the Trusted Advisor deprecated runtimes check. Those notices cover only $LATEST versions (AWS). To catch published versions too, AWS documents this command, which you repeat per region and per account (AWS docs):

aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='python3.10'].FunctionArn"

The same page notes this "doesn't return Lambda Web Functions", and that AWS Config advanced queries can aggregate across regions and accounts but return only $LATEST. If you have adopted the newer function type we covered in AWS Lambda Web Functions, inventory those separately. Then rank what you find by recent invocations, using the CloudWatch log stream and Invocations metric approach AWS describes on the same page.

Which Python version should you upgrade to?

Skip python3.11. It runs on Amazon Linux 2 as well, and Lambda deprecates it on 30 June 2027, so you would repeat this exercise within a year. The real choice is among the Amazon Linux 2023 runtimes:

Runtime	OS	Lambda deprecation	CPython end of life
python3.11	Amazon Linux 2	30 Jun 2027	2027-10
python3.12	Amazon Linux 2023	31 Oct 2028	2028-10
python3.13	Amazon Linux 2023	30 Jun 2029	2029-10
python3.14	Amazon Linux 2023	30 Jun 2029	2030-10

Lambda dates come from the runtimes table; CPython dates from the devguide, which already lists both 3.12 and 3.13 as security-only. On Lambda, python3.13 buys eight months over python3.12 for the same migration work. Python 3.14 gets no extra Lambda time today but a longer upstream tail. Choose python3.12 only if a dependency you cannot replace has not shipped wheels for 3.13. Lambda disables the 3.13 JIT compiler and free-threading in its builds (AWS), so neither is a reason to pick a version.

Python 3.10 to 3.12 migration: the breaking changes that bite

The jump crosses three CPython releases of removals. From the official "What's New" pages:

• 3.11 removed the @asyncio.coroutine decorator and the binhex module (What's New in 3.11).
• 3.12 removed distutils, asynchat, asyncore and imp, dropped unittest aliases such as assertEquals and failUnless, and stopped installing setuptools in new virtual environments (What's New in 3.12). Code that imports pkg_resources at runtime now needs setuptools declared as a dependency.
• 3.13 removed 19 "dead batteries" including cgi, crypt and telnetlib, plus lib2to3 and the 2to3 tool (What's New in 3.13).

Lambda adds one change that tests rarely catch. From python3.12, functions return Unicode characters in JSON responses instead of escaped sequences, so a caller expecting こ-style output may break (AWS). The upside is real, though: Python 3.11 is between 10-60% faster than Python 3.10 on CPython's benchmark suite. Whether your handler sees any of that depends on how much time it spends in Python rather than waiting on I/O.

Where the deadline actually falls for you

The strongest argument for waiting is that AWS keeps extending the block dates, and invocation never stops. Both are true. But every extension has shifted when deployments stop, not when patches stop, and the patch stream for both the language and the OS has already ended or narrowed. Waiting is the wrong call if any python3.10 function touches the internet or untrusted input.

Work it in this order: inventory with the command above, upgrade the most-invoked functions first to python3.13, and keep the old version behind an alias until after 31 August 2027. If the inventory reveals a broader legacy application modernization problem, such as abandoned dependencies pinned to 3.10, treat it as one. We have written about the same pattern with Node 20 end of life, and our serverless architecture team can help when the runtime upgrade turns into a redesign.