The Node.js 20 Lambda Deadline Everyone Is Citing Is Wrong and the Real Risk Already Started

The Deadline You Were Given Is Already Out of Date

If you searched for the AWS Lambda Node.js 20 end-of-support date in the last few months, you were almost certainly told it is August 31, 2026 for blocking new functions and September 30, 2026 for blocking updates. A lot of blog posts, migration trackers, and internal tickets are built on those two dates.

They are stale. AWS moved them.

The current AWS Lambda documentation shows the block dates for nodejs20.x as February 1, 2027 to block function creation and March 3, 2027 to block updates. AWS states plainly that it delayed these dates beyond the usual schedule "in response to customer feedback to give you more time to upgrade your functions." The secondary coverage quoting August and September 2026 was written against the earlier plan and never caught up.

Here is the trap in that good news, and it is the whole point of this post: the extension to 2027 tells you when AWS stops letting you deploy the runtime. It says nothing about when the runtime stopped being safe. That already happened, on April 30, 2026, and most of the coverage is anchored on the wrong event entirely.

What AWS Actually Scheduled

The verified timeline for nodejs20.x, from the AWS Lambda runtimes documentation:

Four distinct events, and the word everyone reacts to, "deprecation," is the one that has already passed. The two 2027 dates are administrative gates. The one that matters for security fired three months ago.

"Deprecated" Does Not Mean "Stops Working"

The single biggest misconception about Lambda runtime deprecation is that it is a kill switch. It is not. AWS never blocks invocation of a function on a deprecated runtime. Your Node.js 20 functions will keep answering requests in 2027, in 2028, and beyond, with no action from you.

What deprecation actually removes is maintenance and support. From the deprecation date onward:

• AWS no longer applies security patches to the Node.js 20 language runtime.
• Functions on that runtime are no longer eligible for AWS technical support.
• The runtime is provided as-is, and AWS explicitly warns it "may contain bugs, errors, defects, or other vulnerabilities," and that functions "may also experience degraded performance or other issues, such as a certificate expiry, that can cause them to stop working properly."

That last point is worth holding onto. Deprecated runtimes do not stop on a date, they rot slowly. A TLS certificate baked into the runtime expires, a dependency assumption breaks, and a function that ran fine for a year fails on a Tuesday with no deploy to explain it.

The Nuance Almost Every Guide Gets Wrong

There is a subtlety in the extension window that matters, and it is the difference between "we are unpatched" and "we are partially unpatched."

During the delay between deprecation (April 2026) and the block dates (2027), AWS keeps patching the underlying operating system, Amazon Linux 2023, for nodejs20.x. What it does not patch is the Node.js 20 language runtime itself. AWS's own wording: "During this period, Lambda only applies security patches to the runtime OS. Lambda doesn't apply security patches to programming language runtimes after they reach their end of support date."

So the honest status of a nodejs20.x function today is: the OS layer beneath it may still receive fixes, but the Node.js runtime it executes on stopped receiving them on April 30, 2026. The next security issue in Node.js 20 itself ships with a patch for Node 22 and 24, and nothing for you. Node.js 20 reached community end of life upstream on the same April 30 date, which is exactly why Lambda deprecated it then. There is no upstream fix coming either.

That is the real deadline, and it is in the past. February 2027 is when the paperwork catches up.

Find Your Exposure in One Command

Do not assume you have no Node.js 20 functions. Teams that migrated their main services often leave a forgotten utility function, a cron trigger, or a CI helper on an old runtime. Check.

Per region:

aws lambda list-functions \
  --query "Functions[?Runtime=='nodejs20.x'].{Name:FunctionName,Modified:LastModified}" \
  --output table

Across every region you are enabled in:

for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  count=$(aws lambda list-functions --region "$region" \
    --query "length(Functions[?Runtime=='nodejs20.x'])" --output text 2>/dev/null)
  [ "$count" != "0" ] && [ -n "$count" ] && echo "$region: $count nodejs20.x functions"
done

Two things that command will not catch, so check them too:

• Published versions and aliases. list-functions returns $LATEST. A function whose $LATEST you already migrated can still have an old published version pinned behind an alias. AWS Trusted Advisor's "AWS Lambda Functions Using Deprecated Runtimes" check lists both $LATEST and published versions, and updates automatically. Use it as the source of truth rather than a one-off CLI sweep.
• Container-image functions. Deprecation notifications are not sent for functions deployed as container images. If you build your own images, you own the deprecation calendar entirely, and nothing will email you about it.

AWS also emails your account's primary contact at least 180 days before a deprecation and surfaces it in the Health Dashboard. If those went to an unmonitored root-account inbox, that is its own problem worth fixing while you are here.

Migrate to nodejs22.x or nodejs24.x

Both are supported. The choice is about runway:

For most teams, nodejs22.x is the pragmatic move today: it is the established LTS and your dependencies are already tested against it. If you would rather not repeat this migration in a year, nodejs24.x buys you to 2028.

The migration itself is usually small, because the hard part happened at an earlier hop. The AWS SDK for JavaScript v3 has been the default since Node.js 18, so if you are on 20 you are already off the SDK v2 cliff. Going 20 to 22 is mostly a runtime-identifier change plus a test pass:

• Zip functions: change the runtime in the function configuration (Terraform runtime, SAM Runtime, CDK runtime, or the console) and redeploy.
• Container functions: rebuild from the nodejs22.x base image and redeploy.

Do it safely rather than in place. Test the function on the new runtime in staging, and use Lambda versions and aliases with a weighted alias to shift a slice of traffic first. AWS notes you cannot revert to a deprecated runtime after the block-update date, so on nodejs20.x you have a rollback window now that closes in March 2027.

One setting to check before you assume auto-updates will save you: if a function's runtime management is set to Manual rather than Auto, it is pinned to a specific runtime version and will not move on its own. Manual pinning is exactly the configuration that lands a function on a deprecated runtime and keeps it there quietly.

The Timeline, Straightened Out

• Now (since Apr 30, 2026): Node.js 20 runtime is unpatched at the language level and unsupported. This is the real risk, and it is live.
• Feb 1, 2027: new nodejs20.x functions can no longer be created.
• Mar 3, 2027: existing nodejs20.x functions can no longer be updated, and your rollback path to Node 20 closes.
• After that, indefinitely: they keep running, unpatched, until a certificate or dependency quietly breaks one.

What To Do

1. Inventory now. Run the commands above and cross-check against Trusted Advisor for versions and aliases. Do not forget container-image functions.
2. Treat it as a security task, not a February 2027 calendar item. The runtime has been unpatched since April. The 2027 dates are when deployment is blocked, not when the risk starts.
3. Migrate to nodejs22.x for the safe default, or nodejs24.x for the longest runway.
4. Roll safely with a staging test and a weighted alias, while the rollback window to Node 20 is still open.
5. Fix the notification gap if these deprecations are reaching an inbox nobody reads. The next runtime deprecation is always already scheduled.

The measured version: you have more calendar time than the internet told you, and less safety margin. AWS did not give you until 2027 to stay secure, it gave you until 2027 to stop deploying. The window to be running a patched runtime closed in April, which is the number your migration should be planned around.

If you want a fast read on which of your functions, across every account and region, are sitting on deprecated runtimes, and a migration sequenced so nothing ships broken, that is exactly what our AWS cloud management and security and compliance work covers. For a related case on the gap between a patch being available and a patch being applied, see our note on the nginx map regex overflow.

Sources

• AWS Lambda runtimes and deprecation schedule
• AWS Lambda runtime deprecation policy and shared responsibility
• Retrieve data about Lambda functions that use a deprecated runtime
• Managing AWS Lambda runtime upgrades, AWS Compute Blog
• Node.js release schedule