Ingress NGINX Is End of Life: How to Keep It Secure on AWS With NES

It routes requests for a large share of the world's clusters, and in March 2026 the Kubernetes community officially retired it. This was not a surprise. The maintainers had signaled for months that the project would wind down due to a growing amount of tech debt. Retirement means no more releases, no more bug fixes, and no more security patches. The controller keeps running, which is exactly what makes it dangerous. It will quietly accumulate unpatched vulnerabilities right at the entry point to your cluster.

Migrating off Ingress NGINX on AWS is real engineering work, and most teams cannot finish it before the security clock runs out. HeroDevs Never-Ending Support (NES) for Ingress NGINX is now available on AWS Marketplace, giving AWS customers a commercially supported, drop-in replacement they can buy through the procurement channel they already use.

‍

TL;DR

• Ingress NGINX reached end of life in March 2026. There are no further security patches from the Kubernetes project, and the repository is archived and read-only.
• On AWS EKS, the controller is not installed by default, so responsibility for patching sits entirely with you. Running it unpatched in the request path is both a security exposure and an audit finding under SOC 2, PCI DSS, HIPAA, and ISO 27001.
• NES for Ingress NGINX is a Kubernetes-native, drop-in replacement delivered as a Helm chart and OCI image. It keeps your existing ingress rules and gives you ongoing CVE remediation while you migrate on your own timeline.
• It is available on AWS Marketplace as a public offer, metered per running controller pod per hour with no upfront commitment, so you can self-subscribe and bill against existing AWS commitments. Custom terms are available as a private offer, still transacted through Marketplace.
• Best fit: platform and security teams on EKS that cannot safely complete a Gateway API or AWS Load Balancer Controller migration before the risk window opens.

‍

Why Ingress NGINX End of Life Is a Bigger Problem on AWS

First, a naming clarification, because it causes real confusion. The retired project is Ingress NGINX (the community-maintained kubernetes/ingress-nginx controller governed by Kubernetes SIG Network). It is not the same as F5/NGINX Inc.'s separate nginxinc/kubernetes-ingress controller, which is still maintained, and it is not the NGINX web server, which is unaffected. Only the community Ingress NGINX controller reached end of life.

Amazon EKS does not ship or install Ingress NGINX for you. If it is in your cluster, someone installed it manually, and you now own maintaining it. When the IngressNightmare CVEs landed in 2025, including a 9.8-severity remote code execution flaw in the admission controller, AWS confirmed EKS itself was unaffected and told customers who had installed the controller to update it themselves. After retirement, there is nothing left to update to.

New vulnerabilities continue to surface in code paths that affect retired Ingress NGINX builds, and an ingress controller is the single most attack-adjacent component you can leave unpatched. It terminates external traffic, holds TLS material, and has broad in-cluster reach. For a running inventory of patched Ingress NGINX vulnerabilities, see the HeroDevs Vulnerability Directory.

‍

The Migration Paths, and Why Timing Is the Hard Part

There is no true drop-in successor in the open source ecosystem, which is what makes the deadline painful. The realistic controller alternatives on AWS are:

1. Gateway API with the AWS Load Balancer Controller. The strategically cleanest destination and the direction AWS is investing in. It removes the in-cluster proxy hop and the associated single point of failure, but it is a re-architecture, not a swap. It requires new resource models, careful CRD version pinning, and per-route reconfiguration.
2. A different Ingress controller (Traefik, HAProxy, Kong, Envoy Gateway). Keeps the Ingress API for now but still means adopting a new controller, re-testing annotations, and revalidating behavior under load.
3. Commercially supported NES for Ingress NGINX. A true drop-in that keeps your existing architecture secure and decouples the security deadline from the migration project, so you can migrate strategically and on your own terms. A helm upgrade in place keeps your existing ingress rules and annotations.

The first two are the right long-term answers. The problem is that both take longer than the window most teams have, and rushing a controller migration on the production traffic path is its own risk. That gap between the security deadline and a safe migration is precisely what NES is built to cover.

‍

NES for Ingress NGINX on AWS Marketplace

Ingress controllers sit directly in the request path, which makes unsupported ingress software a high-impact security, compliance, and operational risk. NES for Ingress NGINX is a fully supported, security-maintained replacement for teams that need more runway to migrate off unsupported Ingress NGINX on a realistic timeline.

It is built for Kubernetes-native platform teams. NES for Ingress NGINX is delivered as a Helm chart and OCI container image, so you replace the upstream controller without rewriting existing ingress rules or application configuration. You keep operating on your current architecture while HeroDevs handles ongoing vulnerability remediation and maintenance.

Key benefits

• Secure drop-in replacement for EOL Ingress NGINX. Swap the unsupported controller for a commercially supported, expert-backed NES release without re-architecting your ingress layer.
• Ongoing CVE remediation and compliance support. As new vulnerabilities are reported, HeroDevs ships new NES for Ingress NGINX releases with fixes, keeping the request path defensible against audit findings. Since retirement, HeroDevs has shipped fixes for 89 vulnerabilities (at the time of writing) across the controller, NGINX, and the image's dependencies.
• Kubernetes-native delivery for platform teams. Helm chart and OCI image delivery fits the way modern platform teams already deploy and manage cluster components.

Why buying through AWS Marketplace matters

For teams already operating in AWS, procurement through AWS Marketplace removes a common source of delay. Instead of standing up a separate vendor relationship and purchase order, you can evaluate and subscribe through a channel your organization already trusts. Spend counts toward existing AWS commitments, aligns with pre-approved cloud budgets, and moves through familiar approval workflows. The listing is metered per running controller pod, per hour, with no upfront commitment, so most teams can self-subscribe in minutes and stop billing by scaling down. When the security clock is running, shaving weeks off procurement is not a minor convenience.

‍

Who NES for Ingress NGINX Is For

This is the right fit if you are a platform or security team on EKS (or self-managed Kubernetes on AWS) that depends on Ingress NGINX in production and cannot safely complete a Gateway API or alternative-controller migration before newly discovered vulnerabilities start going unpatched. CVE-2026-42945 ("NGINX Rift") is a prime example: a heap buffer overflow in the NGINX rewrite module, reachable pre-authentication at the cluster edge and scoring 9.2 on CVSS v4.0. A worker-crash denial of service is reachable, and remote code execution is possible where ASLR is disabled. Upstream NGINX shipped a fix, but the retired Ingress NGINX controller compiles the vulnerable code into its binary and will never receive it. HeroDevs backported the fix to NES within days. Until you have that patch, scanners flag it as an open critical the moment the advisory propagates. It is especially costly in regulated environments, where an unsupported component in the L7 data path is an automatic finding under SOC 2, PCI DSS, HIPAA, and ISO 27001, and where the compliance clock often moves faster than any specific exploit.

NES is a bridge, not a dead end. For some teams it buys secure time toward an eventual Gateway API migration. For others, it keeps critical systems supported when a fast migration is not possible due to customer obligations, regulatory constraints, or engineering capacity. Either way, it converts a hard deadline into a schedule you control.

‍

Get Started on AWS Marketplace

If your organization is running unsupported Ingress NGINX on AWS, Marketplace is a practical place to begin evaluating coverage:

• NES for Ingress NGINX on AWS Marketplace: a secure, Kubernetes-native, drop-in replacement for unsupported Ingress NGINX controller deployments.
• HeroDevs Vulnerability Directory: track the Ingress NGINX vulnerabilities HeroDevs patches and see what NES coverage includes.
• NES for Ingress NGINX on AWS Marketplace (setup guide): IAM/IRSA configuration, subscription steps, and metering details for deploying on EKS.

You can also contact HeroDevs to discuss coverage, private offer options, and the right path for your environment. End of life does not have to mean end of security. With NES, you keep Ingress NGINX secure, supported, and operational while you migrate on a timeline that actually works.