EKS Auto Mode now runs Gateway API with no controller to install, minus timeouts

As of October 28, 2026, an EKS cluster in Auto Mode understands Gateway and HTTPRoute with no controller to install: you declare the route and AWS stands up an Application Load Balancer for L7 or a Network Load Balancer for L4. GKE has offered the same deal for a while with its Google-hosted controller, and the EKS version ships with a list of gaps worth reading before you migrate.

01What changes

Until now, traffic into an EKS Auto Mode cluster went through Ingress (ALB) or a LoadBalancer Service (NLB). With Gateway API, Auto Mode brings two built-in controllers that you pick in the GatewayClass:

• eks.amazonaws.com/gateway-alb: ALB for HTTPRoute and GRPCRoute.
• eks.amazonaws.com/gateway-nlb: NLB for TCPRoute and UDPRoute.

According to the announcement, support covers HTTP and gRPC routing, cross-namespace routes, weighted traffic splitting, header-based routing and certificate discovery through AWS Certificate Manager. There is no extra charge beyond the load balancers it creates, and it is available in every region where EKS Auto Mode runs.

The operational win is the split of responsibilities the model encourages: the platform team owns the GatewayClass, cluster operators own the Gateway (listeners, ports, TLS), and each app team ships HTTPRoutes in its own namespace. With Ingress, all of that ended up tangled in annotations.

02Turning it on

Gateway API is off by default. You enable it in the cluster's network config with gatewayApi.crds.managed, which also decides who owns the cluster-wide Gateway API CRDs:

• true: AWS installs and upgrades the CRDs (at v1). If you already have CRDs at an older version, the call is rejected and nothing changes.
• false: you keep the CRDs. Pick this if you already run Envoy Gateway, Istio or another controller.

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

Then a GatewayClass pointing at the ALB controller, a Gateway with its listener, and the route to your Service:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eks-auto-alb
spec:
  controllerName: eks.amazonaws.com/gateway-alb
---
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: service-2048
          port: 80

The docs say to create the GatewayClass first, since it takes a moment to become usable. The load balancer can take a few minutes; kubectl wait --for=condition=Programmed gateway/my-gateway tells you when it's ready. Subnets need the public/private tags Auto Mode expects (eksctl adds them for you).

03What the ALB won't do

The catch is in the spec details. Auto Mode uses the AWS Load Balancer Controller implementation, and its compatibility table leaves out several standard pieces:

• Listener TLS: certificateRefs is not supported. Certificates go in the AWS-specific LoadBalancerConfiguration resource (gateway.k8s.aws/v1), not in a Secret as with other implementations.
• HTTPRoute timeouts and retries, RequestMirror, ResponseHeaderModifier and CORS: not supported.
• Session persistence and external auth: only through ListenerRuleConfiguration, which is also how you wire up Cognito or OIDC.
• Backend TLS to your pods: not supported.
• Redirects: a path-only RequestRedirect using ReplacePrefixMatch triggers a redirect loop; use ReplaceFullPath instead. And if one redirect rule is invalid, the controller stops creating the remaining rules of that HTTPRoute.

If you're coming from Envoy Gateway or Istio with timeouts and retries on your routes, those manifests won't port as-is: either move that logic into the app or keep that controller. Both can run in the same cluster because each one has its own controllerName.

04How it compares with GKE

In practice, EKS no longer makes you install and upgrade the AWS Load Balancer Controller to get Gateway API on Auto Mode, which is the chore GKE saved you from day one. Your existing Ingress and LoadBalancer Service objects keep working, so you can adopt it one route at a time: start with a new service, get TLS working through LoadBalancerConfiguration, and compare the ALB it creates with the one you had.

05Sources

• Amazon EKS Auto Mode now supports Kubernetes Gateway API (AWS What's New)
• Configure the Kubernetes Gateway API in EKS Auto Mode (Amazon EKS User Guide)
• AWS Load Balancer Controller: L7 (ALB) Gateway API guide (Kubernetes SIGs)
• About the Gateway API (GKE) (Google Cloud)