Desde el 28 de octubre de 2026, un clúster de EKS en Auto Mode entiende Gateway y HTTPRoute sin que instales ningún controlador: declaras la ruta y AWS levanta un Application Load Balancer para L7 o un Network Load Balancer para L4. Es la misma promesa que GKE ofrece desde hace tiempo con su controlador alojado por Google, y llega con una lista de huecos que hay que leer antes de migrar.
Qué cambia
Hasta ahora, en EKS Auto Mode la entrada de tráfico se resolvía con Ingress (ALB) o con Service de tipo LoadBalancer (NLB). Con la Gateway API, Auto Mode trae dos controladores propios que se eligen en la GatewayClass:
eks.amazonaws.com/gateway-alb: ALB paraHTTPRouteyGRPCRoute.eks.amazonaws.com/gateway-nlb: NLB paraTCPRouteyUDPRoute.
Según el anuncio, el soporte incluye enrutado HTTP y gRPC, rutas entre namespaces, reparto de tráfico por pesos, enrutado por cabeceras y descubrimiento de certificados en AWS Certificate Manager. No tiene coste adicional: pagas los balanceadores que se crean, como siempre. Está en todas las regiones donde existe EKS Auto Mode.
Lo más interesante para operar es el reparto de papeles que propone el modelo: plataforma define la GatewayClass, quien opera el clúster define el Gateway (listeners, puertos, TLS) y cada equipo de aplicación publica sus HTTPRoute en su namespace. Con Ingress todo eso acababa mezclado en anotaciones.
Cómo activarlo
La Gateway API no viene encendida: se activa en la configuración de red del clúster con el campo gatewayApi.crds.managed, que además decide quién es dueño de los CRD de la Gateway API, que son globales al clúster:
true: AWS instala y actualiza los CRD (en la v1). Si ya tienes CRD en una versión anterior, la operación se rechaza sin tocar nada.false: los CRD siguen siendo tuyos. Es la opción si ya usas Envoy Gateway, Istio u otro controlador.
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled":true,"gatewayApi":{"crds":{"managed":true}}}}'Después, una GatewayClass que apunte al controlador de ALB, un Gateway con su listener y la ruta hacia tu 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: 80La documentación recomienda crear la GatewayClass antes que el resto, porque tarda un poco en estar lista. El balanceador puede tardar unos minutos; kubectl wait --for=condition=Programmed gateway/my-gateway te dice cuándo está listo. Las subredes tienen que llevar las etiquetas de pública o privada que exige Auto Mode (eksctl ya las pone).
Lo que no hace el ALB
La trampa está en el detalle de la especificación. Auto Mode usa la implementación del AWS Load Balancer Controller y su tabla de compatibilidad deja fuera varias piezas estándar:
- TLS en el listener:
certificateRefsno está soportado. El certificado se configura con el recurso propioLoadBalancerConfiguration(gateway.k8s.aws/v1), no con unSecretcomo en otras implementaciones. - Timeouts y reintentos de
HTTPRoute,RequestMirror,ResponseHeaderModifiery CORS: no soportados. - Sesiones persistentes y autenticación externa: solo con
ListenerRuleConfiguration, que también es la vía para Cognito u OIDC. - Backend TLS hacia los pods: no soportado.
- Redirecciones: un
RequestRedirectque solo cambia la ruta conReplacePrefixMatchprovoca un bucle; hay que usarReplaceFullPath. Y si una regla de redirección es inválida, el controlador deja de crear las reglas siguientes de esaHTTPRoute.
Si vienes de Envoy Gateway o Istio con timeouts y reintentos en las rutas, esos manifiestos no se trasladan tal cual: o los mueves a la aplicación, o mantienes ese controlador. Los dos conviven en el mismo clúster porque cada uno tiene su controllerName.
Frente a GKE
| EKS Auto Mode | GKE | |
|---|---|---|
| Controlador | Gestionado por AWS, se activa por clúster | Alojado por Google, activado por defecto (un clúster) |
| Balanceadores | ALB (L7) y NLB (L4) | Clases gke-l7-*, globales, regionales e internas |
| Coste del controlador | Incluido; pagas los balanceadores | Incluido en el precio de Standard y Autopilot |
| CRD | Gestionados por AWS u opcionalmente por ti | La documentación no lo detalla |
La diferencia práctica es que EKS ya no obliga a instalar y actualizar el AWS Load Balancer Controller para tener Gateway API en Auto Mode, que era el trabajo que GKE ahorraba desde el principio. Los Ingress y Service de tipo LoadBalancer que ya tienes siguen funcionando, así que la adopción puede ser ruta a ruta: empieza por un servicio nuevo, valida TLS con LoadBalancerConfiguration y compara el ALB que crea con el que tenías.
Fuentes
- 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)