Node 18 and Node 16 deprecation in AWS Lambda - time is up

Node 18 and Node 16 deprecation in AWS Lambda - What you need to know this week

If your business is running AWS Lambda functions built on Node.js 18 or Node.js 16, this is your final call. On 1 November 2025 - in a matter of days - AWS will flip the switch. From that point, you will no longer be able to update, redeploy, or modify any Lambda functions that still depend on those runtimes. They'll continue to execute for now, but essentially frozen in amber - unsupported, unpatched, and slowly drifting away from compliance.

This week marks the final phase of the deprecation schedule. After the weekend, any lingering Node 18 or 16 Lambda functions are effectively legacy code.

What actually happens on 1 November

AWS has been phasing this change in stages. Here's the timeline:

• September 2025: AWS stopped updating the Node 18 runtime. No further patches, bug fixes, or performance updates have been applied since then.
• October 2025: Creation of new Node 18 or Node 16 functions was disabled in the Lambda console and APIs.
• 1 November 2025: You'll no longer be able to modify, redeploy, or update existing Lambda functions running on those runtimes.

If you do nothing, your functions will continue to run - for now. But you won't be able to make any configuration or code changes. Even something as trivial as updating an environment variable or changing memory allocation will count as an update and therefore fail. That's fine until the next production issue appears on a Friday afternoon and your fix won't deploy because AWS no longer supports the runtime.

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 20 is the new standard - but it's not a quick switch

AWS now recommends migrating all Lambda functions to Node.js 20, which is the current long-term support runtime. 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 20 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 20, 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 20. 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 1 November. 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.

It's been a long year of reminders and countdowns, but the deadline is here. If your Lambdas still run Node 18 or Node 16, the best course of action is clear: upgrade them to Node 20, retest, and redeploy before the 1 November lockout hits. Don't assume it's a quick runtime flip - evaluate each function, check dependencies, and modernise where needed.