EKS Auto Mode Now Speaks Gateway API: Managed ALBs and NLBs from Gateway and HTTPRoute

On October 28, 2026, Amazon EKS Auto Mode gained native support for the Kubernetes Gateway API. You define GatewayClass, Gateway and HTTPRoute (or GRPCRoute, TCPRoute, UDPRoute), and Auto Mode provisions and runs the Application Load Balancer or Network Load Balancer behind them. No AWS Load Balancer Controller to install, no Helm chart to upgrade, no IAM role to wire up.

If your clusters already run Auto Mode, this closes an awkward gap. Auto Mode promised that AWS operates the cluster's infrastructure components, but its managed load balancing only spoke Ingress and Service type LoadBalancer. With Ingress NGINX retired in March and most teams moving to Gateway API, Auto Mode users had to bolt a controller back on, which is exactly what Auto Mode is supposed to remove.

Platform defines the class, cluster operators define the Gateway, app teams define routes, and Auto Mode runs the load balancer (labels in Spanish). Diagram: CloudAcademy.ar.

TL;DR

Two AWS-owned controllers: eks.amazonaws.com/gateway-alb (L7, ALB) and eks.amazonaws.com/gateway-nlb (L4, NLB). They coexist with Envoy Gateway, Istio and others.
HTTP and gRPC routing, header matching, weighted traffic splitting and cross-namespace routes.
ACM certificates are discovered automatically from the listener hostname.
AWS-specific settings live in three extension CRDs: LoadBalancerConfiguration, TargetGroupConfiguration and ListenerRuleConfiguration (including Cognito/OIDC auth).
Ingress and LoadBalancer Services keep working, so you can migrate one app at a time.
No extra charge beyond Auto Mode and the load balancers it creates.

How it works

Gateway API splits responsibility into three layers, which is its main advantage over Ingress: the platform team owns GatewayClass, cluster operators own Gateway (listeners, hostnames, which namespaces may attach routes), and application teams own routes in their own namespaces.

Gateway API's role model, as presented in AWS's Load Balancer Controller post (adapted from the Gateway API project). Image: AWS.

Auto Mode watches those resources, maps them to load balancers, listeners, rules and target groups, corrects drift, and writes status (including the load balancer address) back to the Gateway and routes. It's the same reconciliation logic as the AWS Load Balancer Controller, just operated by AWS.

Controller reconciliation flow. Image: AWS.

Enabling it

It's a cluster-level setting under kubernetesNetworkConfig.elasticLoadBalancing.gatewayApi. With crds.managed: true, AWS installs and maintains the Gateway API v1 CRDs (and refuses to touch existing CRDs older than v1). With false, you own the CRDs, which is what you want if another implementation needs a specific version.

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

Don't forget subnet tags. Auto Mode uses them to place public and internal load balancers, and missing tags are the number one reason a Gateway never becomes Programmed.

A realistic example

One shared Gateway in an infra namespace, HTTP and HTTPS listeners, and only namespaces labeled gateway-access=true can attach routes:

apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: eks-auto-alb spec: controllerName: eks.amazonaws.com/gateway-alb --- apiVersion: gateway.k8s.aws/v1 kind: LoadBalancerConfiguration metadata: name: edge-public namespace: infra spec: scheme: internet-facing --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: edge namespace: infra spec: gatewayClassName: eks-auto-alb infrastructure: parametersRef: group: gateway.k8s.aws kind: LoadBalancerConfiguration name: edge-public listeners: - name: https protocol: HTTPS port: 443 hostname: "api.example.com" allowedRoutes: namespaces: from: Selector selector: matchLabels: gateway-access: "true"

No certificate reference on the HTTPS listener: the controller finds a matching ACM certificate from the hostname and follows ACM updates, so renewals need no changes. Create the GatewayClass first; there's a short delay before a new class can be referenced.

The payments team then ships a 10% canary from its own namespace:

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: payments namespace: payments spec: parentRefs: - name: edge namespace: infra sectionName: https rules: - matches: - path: type: PathPrefix value: /payments backendRefs: - name: payments-v1 port: 80 weight: 90 - name: payments-v2 port: 80 weight: 10

Health checks and deregistration delay go in a TargetGroupConfiguration attached to the Service (spec.targetReference.name). Dropping the deregistration delay from the default 300 seconds to 30 makes rollouts noticeably faster.

kubectl wait --for=condition=Programmed gateway/edge -n infra --timeout=10m kubectl get httproute -A

If a route doesn't show up, check status.parents: the controller records Accepted and the reason when it fails.

What an ALB can't do

This is the part to read before committing. Per the Load Balancer Controller compatibility table, HTTPRoute doesn't support response header modification, request mirroring, CORS, timeouts, retries or default gateways; request header modification is partial; session persistence and external auth go through ListenerRuleConfiguration; there's no BackendTLSPolicy; and standard listener certificateRefs aren't used. Redirects with ReplacePrefixMatch must also change scheme, port or host, or the ALB rejects them as loops. If you depend on per-route timeouts and retries, you'll need a real L7 proxy for that part.

Migrating from Ingress

Ingress and Gateway API run side by side, so migrate per app. AWS's lbc-migrate toolkit (July 2026) translates Load Balancer Controller Ingress resources, annotations and IngressGroups into Gateway API manifests and supports dry-run Gateways. It targets the controller, so swap the GatewayClass to eks.amazonaws.com/gateway-alb afterwards. Then apply, verify, shift DNS (Route 53 weights help) and delete the old Ingress.

Pricing

Gateway API support has no fee of its own. You pay the EKS cluster ($0.10/hour on standard support), the Auto Mode management fee on the instances it runs, and the load balancers: in us-east-1 an ALB is $0.0225/hour plus $0.008 per LCU, an NLB $0.0225/hour plus $0.006 per NLCU.

My own math: one shared Gateway is one ALB, about $16.40/month in hours before LCUs. Consolidating five standalone Ingress ALBs into one Gateway with per-namespace routes saves around $65/month in hours alone. Keep an eye on rule count, though: ALB rule evaluations beyond the first 10 consume LCUs.

Availability

It's available in every Region where EKS Auto Mode is, including South America (São Paulo). The data plane is an ALB or NLB in your VPC and Region, so TLS terminates in-region. Cross-AZ traffic from the load balancer to pods is billed as usual.

Gotchas worth knowing before day one

Old CRDs block managed mode. If an earlier experiment left Gateway API CRDs below v1 in the cluster, the update is rejected and nothing changes. Upgrade them or switch to unmanaged.
L4 routes are still experimental upstream. TCPRoute and UDPRoute live in Gateway API's experimental channel, so confirm the CRDs you have installed include them before you rely on the NLB class.
Porting manifests from other implementations. Routes written for Envoy Gateway or Istio often reference TLS Secrets, timeouts or retry filters. Those need rework: certificates come from ACM, and timeouts and retries aren't available on an ALB.
Debug from status, not logs. You don't have controller pods to tail. The status of the Gateway and each route is your main debugging tool, so make kubectl describe part of your runbooks.
Shared Gateway, shared blast radius. A shared ALB is cheaper, but a bad rule in one route can affect lower-precedence rules in the same route. Keep routes small and owned by one team each.

My take

The most important part of this launch is about ownership, not features. With Ingress, the platform team either became the bottleneck for every routing change or handed out annotations that could break a shared load balancer. Gateway API fixes that with a clear permission model, and now AWS runs the implementation. The real constraint is that you get exactly what an ALB can do, and the unsupported list isn't short. For most APIs and frontends I see, it's plenty. Enable it in managed mode, migrate one boring app first, and use weighted canaries from day one.

Resources