AWS Lambda end of support for Node.js 18 and Node.js 16 extended to March 2026

AWS extends Node 18 and Node 16 support - what this reprieve means

If you were gearing up for AWS Lambda to pull the plug on Node.js 18 and Node.js 16 this week, you can breathe - but only a little. AWS has announced a new date: 9 March 2026. The 1 November cutoff has officially been pushed back by four months. A stay of execution, then - not a pardon.

AWS quietly updated its Lambda runtimes documentation in August 2025 to reflect the new March 2026 deadline. The change effectively gives everyone a bit more breathing space, but it doesn't change the outcome: Node 18 and 16 are still heading for retirement.

For those who've spent the last fortnight frantically auditing functions, this is welcome news. For everyone else, it's a reminder that AWS can (and will) change course, but the end result is the same. These runtimes are still on borrowed time.

So rather than tearing up the migration checklist, keep it open. The extra time is there to test, not to procrastinate!

What actually happens now

AWS has essentially hit snooze on the final phase of the Node 18 and 16 deprecation plan. Here's the updated picture:

• September 2025: AWS stopped releasing patches for Node 18. No more bug fixes or performance updates.
• October 2025: New function creation using Node 18 / 16 disabled in the console and APIs.
• 9 March 2026: The hard stop. From this date you won't be able to update, redeploy or modify existing functions using those runtimes.

The illusion of "it still works"

The tricky part of these runtime deprecations is that, on the surface, nothing breaks immediately. Your users won't see errors, dashboards won't flash red, and your automated monitoring probably won't flag anything. It lulls teams into thinking they can postpone the work. But this is one of those rare moments where inaction quietly increases risk every day.

Unsupported runtimes are more than a theoretical problem. Once Node 18 and 16 fall off the patch cycle, any new vulnerabilities discovered in the Node core or dependent libraries remain unpatched. For functions that process customer data, interact with AWS services, or connect to public APIs, that's a material security exposure. Auditors and cyber teams will spot it quickly, and regulators increasingly view unsupported environments as a compliance failure.

Even if security isn't your main concern, there's a reliability angle. Lambda itself continues to evolve behind the scenes. Over time, infrastructure updates or changes in AWS's internal execution environment can cause older runtimes to behave unpredictably. It doesn't happen overnight - but when it does, you won't get support for it.

Why this isn't just a developer problem

CTOs, engineering directors and founders often underestimate how many small but critical systems depend on Lambda. It's the unsung hero behind automation, cron jobs, image resizing, S3 triggers, and internal APIs. These are the "set and forget" functions that quietly power your operations. Because they require no infrastructure management, they tend to go untouched for years - until something like this deadline brings them back into view.

In a typical SME environment, you might find dozens of small Lambda functions scattered across multiple AWS accounts. Some run every minute, others only on specific events. They all need reviewing. Treat this like a digital MOT: the sooner you inspect them, the less likely you'll be caught out when one stops behaving after an AWS change next spring.

Node 22 is the new standard - but it's not a quick switch

The newest supported runtime is Node 22 and is a likely candidate for upgrading legacy functions. On paper, that sounds simple - change the runtime setting, redeploy, done. In reality, it rarely goes that smoothly.

Functions built years ago on older Node runtimes tend to come with older npm packages. Some of those dependencies may have since been deprecated, changed APIs, or dropped Node 20+ compatibility altogether. In many cases, the runtime upgrade exposes these buried issues. Code that once compiled fine on Node 14 or 16 can suddenly fail because of stricter syntax checks, ES module changes, or transitive dependency mismatches.

So each function should be evaluated. Review its dependencies, rebuild its package-lock file, and test locally under Node 22 before deploying. The aim isn't just to "get it running", but to ensure the entire dependency chain is healthy and supported. If you're using a CI/CD pipeline, now's the time to add automated tests that run against the new runtime - not just unit tests, but integration checks that confirm AWS service calls still behave as expected.

The AWS SDK surprise - v2 is gone

One significant change is that the AWS SDK for JavaScript v2 is no longer included in the Node 20 runtime. For years, AWS shipped v2 as part of the runtime, so you could simply write:

const AWS = require('aws-sdk');
const s3 = new AWS.S3();

That's no longer the case. Node 20 only includes AWS SDK v3, which is modular and imported per service. It looks more like this:

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client();

The change is positive in the long run - v3 loads faster and reduces cold start times - but it means older functions won't work without adjustment. If you're still using v2, you'll need to either include it in your deployment bundle or refactor your code to v3 syntax. Including v2 manually works as a stopgap, but refactoring is cleaner and avoids future runtime surprises.

For larger teams, this is a good opportunity to standardise on v3 across the codebase. It simplifies dependency management and aligns with AWS's own documentation going forward.

Finding what's affected

The easiest way to see which of your Lambda functions still use deprecated runtimes is through the AWS CLI. Run this for each region:

aws lambda list-functions \
  --region eu-west-2 \
  --query "Functions[?Runtime=='nodejs18.x' || Runtime=='nodejs16.x'].FunctionName"

Alternatively, you can use Trusted Advisor or the AWS Health Dashboard which now highlights deprecated runtime usage across your organisation. The Health event includes a list of affected functions by name and region - worth reviewing even if you think everything's up to date. Forgotten test environments and legacy staging stacks are often where these old functions hide.

For businesses with multiple AWS accounts, it's wise to script the discovery process. Loop through all accounts via AWS Organizations or a central credentials profile and generate a simple report. It's not glamorous work, but it's better than a support call from a client wondering why their nightly export job hasn't run for two days.

Practical migration strategy

Once you've identified affected functions, follow a structured plan:

1. Audit: List every function still running Node 18 or 16. Include its triggers (S3, API Gateway, EventBridge, etc.) and dependencies.
2. Assess: Note which ones handle sensitive data, customer-facing workloads, or high-volume traffic. Prioritise those first.
3. Test locally: Run each function under Node 22, installing dependencies fresh. Resolve compatibility issues early.
4. Refactor: Update AWS SDK usage and replace deprecated npm packages. Consider upgrading to ES modules if appropriate.
5. Redeploy: Once tested, deploy to production using Node 22. Monitor logs closely for the first 24 hours.
6. Automate: Add a runtime check to your CI/CD pipeline so future deployments can't accidentally use old runtimes.

Treat this not as a one-off patch but as an opportunity to tighten your development process. Runtime upgrades tend to expose where the gaps are - missing documentation, untested code paths, or inconsistent packaging workflows.

What if you do nothing?

The honest answer: nothing dramatic, at first. Your functions won't suddenly stop running on 9th March. But from that day onwards, you'll be locked out of making any modifications, and over time that turns into operational risk.

AWS will eventually remove support entirely, and while they rarely pull the plug abruptly, history suggests they will start restricting functionality more aggressively in 2026. When that happens, upgrading late will become more painful because the code will have drifted even further from current standards.

If your Lambdas still run Node 18 or Node 16, the best course of action is clear: upgrade them to Node 22, retest, and redeploy before the March lockout hits. Don't assume it's a quick runtime flip - evaluate each function, check dependencies, and modernise where needed.