EKS Auto Mode Gateway API: Replace Ingress NGINX Without Managing a Controller

On 28 October 2026, AWS announced that Amazon EKS Auto Mode now supports the Kubernetes Gateway API. You can now describe how traffic reaches your apps with standard Gateway and HTTPRoute resources, and EKS Auto Mode creates and manages the AWS load balancers for you. You don’t need to install or upgrade a separate controller.

The timing matters. Many teams still run Ingress NGINX, which has now been retired. If you run Kubernetes on AWS and have been putting off your ingress migration, this launch gives you a managed way to do it. This guide covers what changed, how EKS Auto Mode Gateway API works, and how to move over safely.

Why Gateway API, and Why Now

Ingress was the original Kubernetes API for sending outside traffic to workloads. It is simple, but anything beyond basic host and path routing usually ends up in controller-specific annotations. Gateway API is the newer standard. AWS’s EKS documentation calls it a role-oriented, expressive and portable model that fixes limitations of the older Ingress API. It natively supports L4 (TCP/UDP/TLS) and L7 (HTTP/gRPC) routing, cross-namespace routing, weighted traffic splitting and header-based routing.

There is also a security reason to act. In November 2025, Kubernetes SIG Network and the Security Response Committee announced the retirement of Ingress NGINX. Best-effort maintenance ended in March 2026. Since then there are no new releases, bug fixes or security patches. Existing deployments still work, but the project recommends migrating to Gateway API. You can check whether you use it with:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

How EKS Auto Mode Gateway API Works

EKS Auto Mode already manages compute autoscaling, pod networking, block storage and load balancing as built-in parts of the cluster. Gateway API support extends that load balancing layer. Gateway API splits ownership into three resource types:

• GatewayClass: a template that names the controller and load balancer type. Platform teams usually own it.
• Gateway: creates a load balancer and defines its listeners, hostnames and TLS settings. Cluster operators usually own it.
• Routes: HTTPRoute, GRPCRoute, TCPRoute and UDPRoute map listeners to Kubernetes Services. Application developers usually own them.

EKS Auto Mode comes with two controllers. eks.amazonaws.com/gateway-alb creates Application Load Balancers for L7 routes, and eks.amazonaws.com/gateway-nlb creates Network Load Balancers for L4 routes. Because these controllers use their own names, they can run alongside other gateway implementations such as Envoy Gateway or Istio in the same cluster.

For AWS-specific settings, Auto Mode supports the same extension resources as the AWS Load Balancer Controller. TargetGroupConfiguration covers health checks, deregistration delay and stickiness. LoadBalancerConfiguration covers subnets, security groups and access logs. ListenerRuleConfiguration covers extras such as Amazon Cognito or OIDC authentication. The announcement also mentions automatic TLS certificate discovery through AWS Certificate Manager.

Step-by-Step: Expose an App with Gateway API on EKS Auto Mode

1. Turn on Gateway API for the cluster

You enable it in the cluster’s elasticLoadBalancing network configuration. The gatewayApi.crds.managed setting decides who owns the Gateway API CRDs. If you set it to true, AWS installs and maintains them at Gateway API v1. If you set it to false, you manage them yourself:

aws eks update-cluster-config \
  --name $CLUSTER_NAME \
  --kubernetes-network-config '{"elasticLoadBalancing":{"enabled":true,"gatewayApi":{"crds":{"managed":true}}}}'

If your cluster already has Gateway API CRDs below v1, AWS rejects the managed option and changes nothing. In that case, upgrade the CRDs first, or choose unmanaged mode.

2. Create a GatewayClass first

AWS recommends creating the class before anything else because it takes a moment to become ready:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eks-auto-alb
spec:
  controllerName: eks.amazonaws.com/gateway-alb

3. Create a Gateway and an HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: eks-auto-alb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
    sectionName: http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-service
      port: 80

4. Verify

Provisioning can take a few minutes. Wait for the Gateway to show Programmed, then read its address:

kubectl wait --for=condition=Programmed gateway/my-gateway
kubectl get gateway my-gateway -o jsonpath='{.status.addresses[0].value}'

When you delete these resources, EKS Auto Mode deletes the load balancer it created. Your subnets still need the standard EKS Auto Mode public and private tags so the right subnets are chosen.

A Safe Migration Plan from Ingress

You don’t have to switch everything at once. AWS confirms that existing Ingress and Service (type LoadBalancer) resources keep working alongside Gateway API resources. A careful rollout looks like this:

1. Take inventory: list every Ingress, its annotations and its TLS setup. The annotations are where hidden behaviour lives, such as redirects, rewrites and auth.
2. Check feature fit: not every Gateway API field maps to an AWS load balancer feature. Review the Gateway API feature comparison before you convert NGINX-specific rules.
3. Run both side by side: create a Gateway and routes for one low-risk service, test the new ALB address, then move DNS over gradually.
4. Use weighted routing for cutovers: HTTPRoute weights let you split traffic between versions for canary releases without extra tooling.
5. Lock down route attachment: the AWS Load Balancer Controller docs warn that allowedRoutes.namespaces.from: All lets any namespace influence routing on the load balancer. Keep the default Same, or use Selector with labelled, trusted namespaces.
6. Plan TLS early: AWS’s gateway implementation picks up certificates from AWS Certificate Manager based on listener and route hostnames. The AWS Load Balancer Controller docs note that TLS certificates cannot be set through Kubernetes secrets in certificateRefs, so issue your ACM certificates before cutover.

Cost and Operations Notes

Gateway API support comes with EKS Auto Mode at no extra feature charge. You pay standard charges for the load balancers it creates, plus normal Amazon EKS pricing. One Gateway can serve many routes and hostnames, so consolidating scattered per-service load balancers onto shared Gateways can also lower your monthly ELB bill. If your workloads run on Amazon ECS instead, the newly launched Amazon ECS Gateway solves a similar problem by letting up to 25 services share one ALB.

Moving off Ingress NGINX touches networking, TLS, DNS and CI/CD at the same time. Our cloud DevOps services team helps plan and automate Kubernetes ingress migrations on Amazon EKS, and our cloud migration and modernization practice helps teams move self-managed Kubernetes clusters to EKS Auto Mode.

Frequently Asked Questions

Do I need to install the AWS Load Balancer Controller for EKS Auto Mode Gateway API?

No. EKS Auto Mode includes the gateway controllers. You enable Gateway API on the cluster and reference eks.amazonaws.com/gateway-alb or eks.amazonaws.com/gateway-nlb in your GatewayClass.

Will my existing Ingress resources stop working?

No. Ingress and Service type LoadBalancer resources keep working alongside Gateway API resources, so you can migrate one service at a time.

Which route types are supported?

HTTPRoute and GRPCRoute are served by an ALB, and TCPRoute and UDPRoute are served by an NLB. Some fields in the Gateway API spec have no matching load balancer feature, so check the feature comparison first.

Is it available in the India Regions?

AWS says Gateway API support is available in all AWS Regions where EKS Auto Mode is supported. If you already run EKS Auto Mode in Mumbai or Hyderabad, you can enable it there.

Ready to Retire Ingress NGINX?

Shanav Technologies helps startups and growing businesses run Kubernetes on AWS with less operational effort, from EKS Auto Mode adoption to zero-downtime ingress cutovers. If your clusters still depend on Ingress NGINX, talk to our team and we will map out a safe migration to Gateway API for your workloads.