AWS Quietly Moved Lambda's Runtime Cutoffs to 2027. The Security Clock Didn't Move.

Published: August 1, 2026  ·  EOL Watch — news analysis

If you searched for the AWS Lambda Node.js 20 deprecation date recently, there is a good chance the schedule you found is wrong — and wrong in a way that cuts both directions. AWS has pushed the operational cutoffs for its entire cohort of old runtimes — nodejs16.x, nodejs18.x, nodejs20.x, python3.8, python3.9, ruby3.2, dotnet6 and provided.al2 — to a single shared wall: function creation blocked February 1, 2027, function updates blocked March 3, 2027.

What AWS did not move is the date the patches stopped. nodejs20.x was deprecated on April 30, 2026 — the same day Node.js 20 reached its upstream end of life — and per AWS's own deprecation policy, from that day the runtime no longer receives security patches and functions on it are no longer eligible for technical support. The 2027 dates are a reprieve for your deploy pipeline, not for your attack surface.

The verified three-stage schedule

Lambda runtime end of life happens in three stages, and each stage breaks something different: deprecation (patches and support stop, invocations continue), block create (no new functions on the runtime), and block update (existing functions can no longer be modified while on the runtime). Here is the full cohort, cross-checked against AWS's Lambda runtimes page on August 1, 2026:

* For provided.al2 the "upstream" is the operating system: AWS's page notes Amazon Linux 2 is scheduled for end of life on June 30, 2026. Table generated from the endoflife.ai AWS Lambda dataset and verified against AWS's live documentation on August 1, 2026.

Read the two right-hand columns down: identical for every row. That is the news. AWS collapsed eight runtimes' individually staggered operational deadlines into one shared wall in early 2027 — including provided.al2, which was only deprecated yesterday, and nodejs16.x, which has been unpatched since 2024. Then read the two left-hand columns: that is the part no announcement changed. A function on nodejs20.x today runs on a runtime that stopped receiving security patches over three months ago.

Why AWS delayed the blocks

AWS's runtimes page is unusually direct about the reason: the delay is a response to customer feedback, to give teams more time to upgrade. It is not hard to reconstruct what that feedback was, because the third stage — block function update — is the one with real teeth.

Deprecation breaks nothing operationally. Block-create breaks new work only. But once updates are blocked, an existing function is frozen: you cannot ship a bug fix, rotate an environment variable via code, or patch a dependency in the bundle without simultaneously upgrading the runtime identifier. The moment a production incident touches a frozen function, a routine hotfix becomes an unplanned runtime migration performed under pressure. AWS also warns that once updates are blocked, you cannot roll back to the deprecated runtime after upgrading — the door locks behind you.

Multiply that by the size of the Node 20 install base — Node 18 and 20 were the default serverless runtimes for years of tutorials, templates and frameworks — and the pressure on AWS to widen the exit is obvious. The result: roughly ten extra months, for everyone, on one calendar.

The trap: the reprieve is operational, not security

Here is the problem with reading the 2027 dates as "we have time." Between April 30, 2026 and March 3, 2027, a nodejs20.x function behaves perfectly. It deploys without friction. It passes CI. Nothing in the console shouts at you at deploy time. And for that entire ten-month window, no security patch reaches the language runtime underneath it — AWS's policy is explicit that after deprecation it may no longer apply security patches, that deprecated runtimes are provided as-is, and that language-runtime patches stop at the language's end-of-support date regardless.

That silent works-fine-but-unpatched window is exactly what end-of-life risk is. The next Node.js security release will fix CVEs in supported release lines — 22 and 24 — and describe them in public advisories. Nothing back-ports those fixes into the deprecated Lambda runtime. Every advisory that ships between now and your migration widens the gap between what attackers know and what your runtime contains, and no operational deadline will remind you it is happening.

Where to go: nodejs22.x or nodejs24.x

The destination options, from the same verified table:

Note what the first row implies: nodejs22.x is deprecated on April 30, 2027 — less than two months after the Node 20 update-block lands. A team that migrates 20 → 22 in early 2027 is scheduling its next forced migration for the same year. Unless a dependency pins you to 22, target nodejs24.x and buy runway to April 2028. (AWS lists Node.js 26 as targeted for a November 2026 Lambda launch; treat that as indicative, not plannable.)

The migration itself is usually mild — Node 20 → 22/24 is an LTS-to-LTS step, not a framework rewrite. The checklist that catches what actually breaks:

1. Census first. aws lambda list-functions --query "Functions[?Runtime=='nodejs20.x'].[FunctionName,Runtime,LastModified]" --output table, per account, per Region — and repeat for nodejs18.x and nodejs16.x, which hit the same 2027 wall. AWS Trusted Advisor and the Health Dashboard list affected functions too.
2. Rebuild native dependencies. Anything with a binary addon (sharp, bcrypt, canvas, database drivers) must be rebuilt against the new Node ABI — this is the classic silent breaker. Rebuild layers too.
3. Check engine pins. engines fields in package.json, .nvmrc files, and hard-coded runtime strings in IaC (CloudFormation, SAM, Terraform, CDK, Serverless Framework) all need the new identifier.
4. Test the runtime, not just the code. Run the suite under Node 22/24 locally or in CI before touching Lambda config. Watch for OpenSSL-related differences in crypto code and for deprecated core-API warnings that became errors.
5. Deploy with rollback in hand. AWS recommends versions and aliases so you can shift traffic gradually — this is also your safety net, because after March 3, 2027 there is no reverting a function to nodejs20.x.
6. Don't schedule against the wall. The 2027 dates are when your escape hatch closes, not when the work becomes urgent. The work became urgent on April 30. Every month earlier you migrate is a month less unpatched exposure — and a migration done calmly instead of during a frozen-function incident.

If you genuinely cannot move yet

An honest note on the option that does not exist: unlike RDS, where AWS sells Extended Support past end of standard support, Lambda has no paid extended-support tier. There is no writing a check to keep nodejs20.x patched — a deprecated managed runtime is simply done, and the only fix AWS offers is changing the runtime identifier.

Commercial extended support for end-of-life Node.js does exist — but only where you control the runtime binary: containers, EC2, on-premises. If a hard blocker (a vendored dependency, a frozen vendor SDK) keeps a workload on Node 20 past the wall, the honest architecture conversation is whether that workload still belongs on a managed runtime at all, or whether it moves to a container image where an extended-support build of Node can be swapped in. See every Node.js version's dates and risk scores and the extended-support options we track — and treat that as a bridge with an end date, not a destination.

A note on date provenance

Every date in this article was verified against AWS's live Lambda runtimes documentation on August 1, 2026, cross-checked against the endoflife.ai dataset, which refreshes nightly from upstream. This story is a case study in why that discipline matters: AWS edited a load-bearing schedule in place, without a changelog entry most people would ever see, and every article, runbook and compliance doc that copied the old dates became quietly wrong — in both directions at once. It is the serverless version of the date drift we documented across 54 products. If you are reading a lifecycle schedule on a month-old blog post — including, one day, this one — check it against the vendor's live page or a source that does so automatically and verifiably before you plan around it.

We track lifecycle deadlines like these across 480+ products — every Lambda runtime and its three-stage dates, check any version in seconds, scan your whole stack, or see what else is reaching end of life this half.

Frequently Asked Questions

Related Resources

• AWS Lambda — every runtime, dated and risk-scored
• Node.js — every version's EOL dates and risk scores
• Node.js 18 End of Life: Upgrade Guide to 20/22 LTS
• AWS Starts Charging for MySQL 8.0 on August 1. Here's What It Costs.
• EOL Dates Drift: What We Found Cross-Checking 54 Products Against Their Vendors
• Your Docker Base Images Are Quietly Dead: The FROM-Line Audit Nobody Runs