Running Node.js 20 on AWS: What Deprecation Actually Means and What Your Options Are

Node.js 20 reached end-of-life (EOL) on April 30, 2026. That means no further minor releases, no bug fixes, and no security patches for the 20.x line. Supported LTS versions (v22 in maintenance, v24 active) and the current release line (v26) continue to receive updates.

Because the community no longer patches Node.js 20, AWS can no longer patch its managed Node.js 20 runtimes either. The runtime moves to deprecated status, disappears from the console or drop-down menus, and AWS eventually blocks creating new functions, and later blocks updating existing ones.

Most coverage of EOL software focuses on one option: migrate to an LTS or current version of Node.js. That is the recommended path, but it is not the only one, and for organizations with large deployment estates, framework version constraints, or dependencies that have not yet been validated on newer Node.js major versions, migration is often not the fastest or safest path. 

The option that gets far less attention is the one AWS designed into every one of its compute services: you can bring your own runtime. This post explains how AWS deprecation actually works across its services, and how a commercially supported Node.js 20 distribution such as HeroDevs Never-Ending Support (NES) for Node.js lets you stay secure on Node.js 20 while you migrate on your own schedule.

‍

Deprecation Only for AWS Managed Services

AWS only enforces a runtime lifecycle policy where AWS manages the runtime. That single sentence explains the entire policy landscape. When you deploy Node.js as a managed runtime, AWS controls the lifecycle. When you deploy your own Node.js custom runtime or inside a container image, or a virtual machine, AWS has no mechanism to patch, deprecate, or even see what is running. Responsibility for the runtime shifts entirely to you.

Here is how that plays out service by service.

‍

Node.js 20 for AWS Lambda

Lambda is the only AWS compute service with a formal, dated runtime deprecation schedule. Lambda's standard policy is to deprecate a runtime when any major component reaches the end of community long-term support (LTS), and security updates are no longer available. Deprecation proceeds in phases: at the deprecation date, security patches stop and functions lose support eligibility. 

For Node.js 20, AWS has extended these windows well beyond its standard policy: the runtime was removed from the Lambda console at deprecation, but you can still create and update functions via the CLI, SAM, or CloudFormation until February 1, 2027 (creation block) and March 3, 2027 (update block). Note these dates have shifted before, and AWS marks them subject to change.

Node.js 20 functions will keep running indefinitely, but Node.js will remain unpatched, which is a significant security risk. You can bring NES for Node.js into Lambda with continued security patching post-EOL. You deploy the NES runtime to Lambda by building a custom container image; step-by-step instructions are in the HeroDevs documentation.

‍

Node.js 20 for Amazon EC2 Applications

EC2 has no runtime deprecation policy because AWS does not manage above the hypervisor. Whether you install Node.js from a binary, bake it into a custom AMI, or run it in a container on the instance, every runtime on it is yours to patch. An EC2 instance running Node.js 20 will run forever. Nothing stops it, and nothing patches it. This is the purest form of forever-day exposure.

A forever-day vulnerability is a known CVE in EOL software that will never receive an official patch, so exposure is permanent rather than time-boxed. Every vulnerability disclosed affecting Node.js 20 remains exploitable on that instance permanently unless you act.

For a secured and supported Node.js 20 you can run NES for Node.js 20 on Amazon EC2 by downloading the NES binary onto a Linux instance and running your application with that runtime.

‍

Node.js 20 on AWS Fargate Tasks and Services

AWS Fargate is slightly different from EC2 because Fargate is a serverless container platform. AWS Fargate's deprecation policy applies to platform versions, meaning the AWS-managed kernel and container runtime layer underneath your tasks. That enforcement never reaches inside your container image.

The Node.js version, application dependencies, and OS packages in the image are exclusively your responsibility, with no AWS deprecation, notification, or enforcement mechanism.

Because Fargate is serverless, there is no server to log in to and no binary to install. The container image is the only place the runtime can live, which is why the NES Node.js binary is baked into your container image so you can keep Node.js 20 supported on AWS Fargate.

‍

Node.js 20 for AWS App Runner Installations

App Runner applies a policy to its managed runtimes for source-code deployments, and it has already ended support for previous versions of Node.js. For container image deployments, the policy does not apply; you are responsible for regularly updating and patching the images you provide. 

For your existing Node.js- based applications in App Runner, you can run NES for Node.js 20 by building a custom container image that installs the NES Node.js binary, pushing the image to Amazon ECR, and creating an App Runner service from that image.

Note also that App Runner itself stopped accepting new customers on April 30, 2026, with AWS recommending Amazon ECS Express Mode instead, so any migration planning should account for the service's own trajectory.

‍

Node.js 20 for Amazon Elastic Container Service (ECS)

Amazon ECS is a  scalable container orchestration service that runs Docker containers and allows you to run applications on AWS using two main launch types: Fargate (serverless, no management) or EC2 (user-managed virtual machines).

Since ECS doesn't have a concept of "managed runtimes" like Lambda, you simply build a Docker image that contains NES for Node.js and deploy that image to the cluster. Your ECS services will run a fully supported Node.js 20 the moment the new image deploys.

‍

Node.js 20 on other AWS Compute Services

AWS Elastic Beanstalk retires platform branches on its own schedule under strict lifecycle policies. The path is Beanstalk's Docker platform: package NES for Node.js in your container image and deploy it as a Docker-platform environment, sidestepping the managed Node.js platform branch entirely to keep Node.js 20 fully supported.

Conversely, Amazon EKS operates under a shared responsibility model that isolates control plane updates from workload runtimes. For EKS, AWS manages the Kubernetes control plane version, never what runs inside your pods. Bringing NES for Node.js into an EKS cluster is therefore straightforward: build it into your container image and deploy as usual so you secure the use of Node.js 20.

‍

Bring Your Own Supported Runtime: NES for Node.js in AWS

HeroDevs NES for Node.js is a drop-in replacement distribution of Node.js that continues to receive security patches after the community version reaches EOL. NES maintains compatibility with the corresponding upstream version, so application code and dependencies do not change. The only change is the source of the Node.js runtime for your Lambda functions and your applications on ECS, EC2, App Runner, Elastic Beanstalk, EKS, and Fargate

This approach converts an unbounded forever-day vulnerability exposure in EOL Node.js into a supported distribution. New CVEs affecting Node.js 20.x, 18.x, 16.x, 14.x, and 12.x receive patches through NES. Your compliance posture holds, because supported software with active security patching satisfies auditors in a way an abandoned community version cannot. And your engineering team migrates to Node.js 22, 24, or 26 on a timeline driven by testing and business priorities rather than by an external deadline.

NES solves runtime security. HeroDevs has already patched two High-severity CVEs disclosed after EOL: CVE-2026-56848 and CVE-2026-58043. As more vulnerabilities are discovered, HeroDevs will continue to patch EOL versions.

Over time, npm packages will drop Node.js 20 from their engine support ranges, which is why NES is a bridge for migrating on your own timeline rather than a permanent destination.

‍

Your Node.js 20 Action Plan on AWS

AWS deprecation dates are not a measure of your application's readiness to move. They are a measure of when the community stopped patching Node.js 20. Those are different questions, and conflating them is how teams end up rushing migrations, skipping regression testing, or quietly accepting unpatched runtimes in production.

The practical sequence looks like this. First, inventory where Node.js 20 actually runs across Lambda, ECS, EC2, Fargate, App Runner, Elastic Beanstalk, EKS, and other AWS services, including runtimes buried inside container images that AWS cannot see. Second, classify each workload: migrate now, or secure now and migrate on schedule. Third, for the workloads that need time, deploy NES for Node.js so every one of them keeps receiving security patches while the migration proceeds at the pace your testing and business priorities allow.

Explore NES for Node.js or talk to the HeroDevs team about your AWS deployment. We will help you map which of your services are exposed and get patched runtimes in place, usually in days, not quarters.

‍

Frequently Asked Questions

What Happens to Node.js 20 Lambda Functions After Deprecation?

AWS never blocks invocations of existing functions. What stops is security patching, then the ability to create new functions on the runtime, and finally the ability to update existing ones. Your functions keep running, but on an increasingly unpatched runtime.

Does AWS deprecation apply to Node.js 20 in container images?

No. On ECS, EKS, Fargate, and App Runner image deployments, AWS has no visibility into or enforcement over the runtime inside your image. That also means AWS is not patching it. The runtime is entirely your responsibility.

Will my application code need changes?

NES for Node.js is a drop-in replacement distribution that maintains compatibility with the corresponding upstream version. Application code and dependencies remain unchanged. You change the source of the runtime, not your application.

Does staying on Node.js 20 with NES satisfy compliance requirements?

Frameworks such as PCI DSS, FedRAMP, HIPAA, DORA, and NIS2 expect software that is supported and receiving security patches. NES provides both, something an abandoned community version cannot. Confirm specifics with your auditor, but a commercially supported runtime with active CVE patching is a fundamentally different compliance posture than an EOL one.

Which Node.js versions does NES cover?

NES currently provides security patches for Node.js 20.x, 18.x, 16.x, 14.x, and 12.x, so estates spanning multiple EOL versions can be covered under one support model.