EKS Auto Mode ahora habla Gateway API: ALB y NLB administrados desde Gateway y HTTPRoute

El 28 de octubre de 2026 AWS anunció que Amazon EKS Auto Mode soporta Kubernetes Gateway API de forma nativa. Definís GatewayClass, Gateway y HTTPRoute (o GRPCRoute, TCPRoute, UDPRoute) y Auto Mode crea y opera el Application Load Balancer o el Network Load Balancer correspondiente. No hay que instalar el AWS Load Balancer Controller, ni mantener su chart de Helm, ni darle un rol de IAM.

Para quienes venimos siguiendo el tema, es la pieza que faltaba. En marzo escribí sobre cómo migrar de Ingress NGINX a Gateway API en EKS a partir del retiro del proyecto, y una de las fricciones era justamente esa: para tener Gateway API con balanceadores de AWS había que instalar y operar un controlador más. Con Auto Mode, ese controlador pasa a ser parte del clúster administrado, igual que ya pasaba con Ingress.

En este artículo vemos qué trae exactamente, cómo se habilita, un ejemplo completo con TLS, tráfico entre namespaces y canary por pesos, qué funcionalidades de Gateway API no están soportadas sobre un ALB, cuánto cuesta y cómo encarar la migración desde Ingress.

TL;DR

• EKS Auto Mode ahora implementa Gateway API con dos controladores propios: eks.amazonaws.com/gateway-alb (capa 7, ALB) y eks.amazonaws.com/gateway-nlb (capa 4, NLB).
• Soporta HTTPRoute, GRPCRoute, TCPRoute y UDPRoute, con ruteo por header, división de tráfico por pesos y rutas entre namespaces.
• Se habilita a nivel de clúster con gatewayApi.crds.managed: en modo administrado AWS instala y mantiene los CRDs de Gateway API v1; en modo no administrado los manejás vos.
• Los certificados de ACM se descubren automáticamente a partir del hostname del listener.
• La configuración específica de AWS (esquema, subnets, health checks, autenticación con Cognito u OIDC) va en tres CRDs de extensión: LoadBalancerConfiguration, TargetGroupConfiguration y ListenerRuleConfiguration.
• Ingress y Services tipo LoadBalancer siguen funcionando en paralelo, así que la migración puede ser gradual.
• No tiene costo adicional: pagás Auto Mode y los balanceadores que se crean.

Por qué ahora

Gateway API es el estándar de Kubernetes para exponer tráfico desde hace tiempo, y 2026 fue el año en que dejó de ser opcional para muchos equipos. El retiro de Ingress NGINX en marzo obligó a mucha gente a decidir hacia dónde ir, y la mayoría de los caminos razonables terminaban en Gateway API: Envoy Gateway, Istio, Cilium o el AWS Load Balancer Controller, que sumó soporte GA en marzo.

El problema para los clústeres con Auto Mode era de coherencia. Auto Mode promete que AWS opera los componentes de infraestructura del clúster: cómputo, almacenamiento en bloque, DNS, red de pods y balanceo de carga. Pero el balanceo administrado solo hablaba Ingress y Services. Si querías Gateway API, volvías a instalar un controlador a mano, con su rol de IAM, sus upgrades y sus CRDs, que es exactamente lo que Auto Mode intenta sacarte de encima. Había incluso artículos en AWS re:Post explicando cómo montar Envoy Gateway sobre Auto Mode para cubrir el hueco.

El contexto en AWS también empuja. El mismo mes, ECS lanzó ECS Gateway, su propio ingress administrado con ALBs compartidos. La dirección es clara: el balanceo de entrada pasa a ser una responsabilidad de la plataforma administrada, no algo que cada equipo arma por su cuenta.

Qué es y qué no es

Es una implementación administrada de Gateway API dentro de EKS Auto Mode. Los recursos que escribís son los estándar del proyecto (gateway.networking.k8s.io/v1), y el controlador que los reconcilia corre del lado de AWS, como el resto de las capacidades de Auto Mode.

No es:

• Un proxy dentro del clúster. No hay pods de Envoy ni de NGINX. El plano de datos es un ALB o un NLB, con las capacidades y los límites de esos servicios.
• Una implementación completa de Gateway API. Varias funcionalidades del estándar no tienen equivalente en un ALB (lo vemos más abajo). Si dependés de mirroring, timeouts o reintentos por ruta, esto no te alcanza.
• Exclusivo. Los controladores usan nombres propios, así que pueden convivir con Envoy Gateway, Istio u otra implementación en el mismo clúster. Cada GatewayClass apunta a su controlador.
• Algo para clústeres sin Auto Mode. Si tu clúster usa node groups administrados o Karpenter instalado por vos, el camino sigue siendo el AWS Load Balancer Controller con sus propios controladores (gateway.k8s.aws/alb y gateway.k8s.aws/nlb).

Cómo funciona

El modelo de Gateway API separa responsabilidades en tres niveles, y esa separación es la principal ventaja frente a Ingress:

• GatewayClass: la define quien opera la plataforma. Dice qué controlador implementa los Gateways de esa clase.
• Gateway: la define quien opera el clúster. Es el punto de entrada: listeners, puertos, hostnames y qué namespaces pueden colgarle rutas.
• Routes: las definen los equipos de aplicaciones en sus propios namespaces. Dicen qué tráfico va a qué Service.

En Auto Mode, el controlador observa esos recursos, los traduce a recursos de AWS (load balancer, listeners, reglas y target groups), corrige cualquier desvío y escribe el resultado en el status del Gateway y de cada ruta, incluida la dirección DNS del balanceador. Las rutas HTTP y gRPC van a un ALB; las TCP, UDP y TLS, a un NLB. Cuando borrás el Gateway, Auto Mode borra el balanceador.

La configuración propia de AWS no entra en los recursos estándar, y para eso hay tres CRDs de extensión en el grupo gateway.k8s.aws, los mismos que usa el Load Balancer Controller:

• LoadBalancerConfiguration: propiedades del balanceador y los listeners (esquema interno o público, subnets, security groups, access logs, certificado por defecto). Se asocia a un Gateway o a una GatewayClass.
• TargetGroupConfiguration: health checks, deregistration delay, stickiness. Se asocia a un Service.
• ListenerRuleConfiguration: comportamiento específico de las reglas del ALB, como respuestas fijas o autenticación con Amazon Cognito u OIDC. Se usa desde una ruta como filtro ExtensionRef.

Habilitarlo en el clúster

La activación vive en kubernetesNetworkConfig.elasticLoadBalancing.gatewayApi. La presencia del bloque gatewayApi enciende la funcionalidad, y crds.managed define quién es dueño de los CRDs:

Para un clúster existente:

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

Y para crear uno nuevo con Auto Mode y Gateway API desde el arranque:

aws eks create-cluster \
  --name $CLUSTER_NAME \
  --role-arn $CLUSTER_ROLE_ARN \
  --resources-vpc-config subnetIds=$SUBNET_IDS \
  --compute-config enabled=true \
  --kubernetes-network-config '{"elasticLoadBalancing":{"enabled":true,"gatewayApi":{"crds":{"managed":true}}}}' \
  --storage-config '{"blockStorage":{"enabled":true}}'

Mi recomendación: modo administrado salvo que ya tengas otra implementación de Gateway API que necesite una versión específica de los CRDs. Si ya tenés CRDs instalados y son anteriores a v1, la operación se rechaza sin cambiar nada, así que actualizalos primero o pasate a no administrado. Y no te olvides de los tags de subnets: Auto Mode los usa para decidir dónde van los balanceadores públicos e internos (si creaste el clúster con eksctl, ya están).

Manos a la obra

El ejemplo de la documentación expone el juego 2048 por HTTP. Vamos con algo más cercano a un clúster compartido: un Gateway en el namespace infra con HTTP y HTTPS, rutas de dos equipos en sus propios namespaces y un canary por pesos.

1. GatewayClass y configuración del balanceador

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-publico
  namespace: infra
spec:
  loadBalancerName: edge-publico
  scheme: internet-facing

Creá la GatewayClass antes que el resto: la documentación aclara que hay una pequeña demora hasta que un Gateway puede referenciar una clase nueva.

2. El Gateway compartido

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-publico
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "api.ejemplo.com.ar"
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"

Dos cosas para mirar. Primero, el listener HTTPS no referencia ningún certificado: con el hostname definido, el controlador busca en ACM un certificado que coincida y lo asocia, y además sigue los cambios en ACM, así que la renovación no te obliga a tocar nada. Si preferís fijarlo, se puede definir un defaultCertificate en la LoadBalancerConfiguration. Segundo, allowedRoutes con Selector: solo los namespaces con la etiqueta gateway-access=true pueden colgar rutas de este Gateway. Es el control que con Ingress no existía.

kubectl label namespace pagos gateway-access=true
kubectl label namespace web gateway-access=true

3. Rutas de los equipos

El equipo de pagos publica su API con un canary del 10% hacia la versión nueva:

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

Y el equipo web enruta por header para que QA pruebe una versión canary sin afectar a nadie:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
  namespace: web
spec:
  parentRefs:
    - name: edge
      namespace: infra
      sectionName: https
  hostnames:
    - "api.ejemplo.com.ar"
  rules:
    - matches:
        - headers:
            - name: x-canary
              value: "true"
      backendRefs:
        - name: web-canary
          port: 80
    - backendRefs:
        - name: web
          port: 80

Cada equipo maneja su HTTPRoute sin pedirle nada al equipo de plataforma, y sin poder tocar el Gateway ni rutas de otros. Con weight vas moviendo el porcentaje del canary con un kubectl apply, y el ALB ajusta los pesos de los target groups.

4. Health checks por Service

Si tu aplicación no responde 200 en /, el health check por defecto del target group la va a marcar como no saludable. Se arregla con una TargetGroupConfiguration asociada al Service:

apiVersion: gateway.k8s.aws/v1
kind: TargetGroupConfiguration
metadata:
  name: pagos-v1-tg
  namespace: pagos
spec:
  targetReference:
    name: pagos-v1
  defaultConfiguration:
    targetGroupAttributes:
      - key: deregistration_delay.timeout_seconds
        value: "30"
    healthCheckConfig:
      healthCheckPath: /health
      healthCheckProtocol: HTTP
      healthCheckInterval: 15
      healthyThresholdCount: 3
      unhealthyThresholdCount: 2

Bajar el deregistration delay de los 300 segundos por defecto a 30 hace que los deploys no se arrastren esperando que el ALB drene conexiones.

5. Verificar

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

kubectl get gateway edge -n infra
kubectl get httproute -A

ADDRESS=$(kubectl get gateway edge -n infra -o jsonpath='{.status.addresses[0].value}')
curl -H "Host: api.ejemplo.com.ar" http://$ADDRESS/pagos

El aprovisionamiento puede tardar unos minutos. Si una ruta no aparece, mirá su status.parents: ahí el controlador deja la condición Accepted y, si falló, el motivo (namespace no permitido, Service inexistente, regla que el ALB no acepta).

Para capa 4

Para tráfico TCP o UDP (un broker, un servidor DNS, un juego) cambiás de clase y de tipo de ruta:

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

TCPRoute y UDPRoute todavía viven en el canal experimental de Gateway API, así que revisá que los CRDs instalados las incluyan antes de usarlas.

Trampas comunes

• Funcionalidades que el ALB no tiene. Según la tabla de compatibilidad del Load Balancer Controller, no están soportados en HTTPRoute: modificación de headers de respuesta, mirroring de requests, CORS, timeouts, reintentos y uso de Gateway por defecto. La modificación de headers de request es parcial. La persistencia de sesión y la autenticación externa se resuelven con ListenerRuleConfiguration. Tampoco hay BackendTLSPolicy.
• Redirects con ReplacePrefixMatch. Tienen que cambiar también esquema, puerto u host. Un redirect que solo cambia el path el ALB lo rechaza como loop, y una regla rechazada bloquea las de menor precedencia en la misma ruta.
• Certificados en el listener. Las certificateRefs estándar no se usan; el certificado sale de ACM por hostname o de la LoadBalancerConfiguration. Si migrás manifiestos de otra implementación que referencian Secrets de TLS, hay que adaptarlos.
• CRDs viejos. El modo administrado se niega a pisar CRDs anteriores a v1.
• Subnets sin tags. Es el motivo número uno de un Gateway que nunca pasa a Programmed.

Migrar desde Ingress

Como Ingress y Gateway API conviven, la migración puede ser por aplicación y sin corte. El orden que recomiendo, alineado con el que propone AWS para su toolkit de migración:

1. Traducir. El toolkit lbc-migrate que AWS publicó en julio lee tus Ingress (incluidas anotaciones del Load Balancer Controller e IngressGroups) y genera los manifiestos de Gateway API. Algunas anotaciones, como reescrituras con regex, requieren edición manual.
2. Previsualizar con un Gateway en modo dry run, para ver qué recursos de AWS se crearían sin crearlos.
3. Aplicar y verificar el Gateway nuevo, que levanta su propio ALB.
4. Mover tráfico cambiando DNS (con pesos en Route 53 si querés hacerlo de a poco).
5. Limpiar el Ingress viejo cuando el ALB anterior deje de recibir tráfico.

Ojo con un detalle: el toolkit está pensado para el AWS Load Balancer Controller, así que después de generar los manifiestos tenés que cambiar la GatewayClass al controlador de Auto Mode (eks.amazonaws.com/gateway-alb) y revisar las versiones de los CRDs de extensión. Si venís de Ingress NGINX, en mi guía de marzo está el mapeo de anotaciones más comunes.

Precios

La integración con Gateway API no tiene costo propio. Pagás lo de siempre de Auto Mode y de Elastic Load Balancing. Referencia: US East (N. Virginia), salvo donde se indica.

Ejemplo de costo (cálculo propio): un Gateway compartido es un ALB. Corriendo todo el mes son unas 730 horas, o sea unos USD 16,40 de cargo fijo más las LCU que consuma tu tráfico. Si hoy tenés cinco Ingress sin group.name, probablemente tengas cinco ALBs; consolidarlos en un Gateway con rutas por namespace te ahorra unos USD 65 por mes solo en horas de balanceador, sin contar LCUs.

Cómo bajar costos en la práctica:

• Un Gateway por dominio de confianza, no por aplicación. El modelo de Gateway API hace natural compartir: plataforma define el Gateway, los equipos cuelgan rutas.
• Cuidado con las reglas. El ALB cobra evaluaciones de reglas por encima de las primeras 10 gratuitas. Muchas rutas con muchos matches en un solo listener suman LCUs.
• Internos para lo interno. Servicios que solo consume la VPC van en un Gateway con scheme: internal; no pagan transferencia hacia Internet ni exponen superficie.

Disponibilidad y lo que conviene mirar con lupa

• Regiones. Está en todas las regiones donde existe EKS Auto Mode. Auto Mode está disponible en São Paulo (sa-east-1), así que podés usarlo localmente. Los precios de ALB y de Auto Mode en São Paulo son más altos que en Virginia; revisalos en la página de precios antes de estimar.
• Residencia de datos. El plano de datos es un ALB o NLB en tu VPC y tu región. La terminación TLS ocurre en el balanceador, dentro de la región. No hay componentes globales en el medio salvo que agregues CloudFront.
• Transferencia. El tráfico del ALB a los pods en otras zonas de disponibilidad genera transferencia entre AZs, igual que con Ingress. Si tu tráfico es alto, mirá la distribución de pods por zona.
• Paridad de funcionalidades. Antes de comprometerte, revisá la tabla de compatibilidad del Load Balancer Controller contra lo que usan tus rutas hoy. Si necesitás timeouts o reintentos por ruta, vas a tener que resolverlos en la aplicación o con otra implementación.
• Convivencia. Si en el mismo clúster corrés Istio o Envoy Gateway, el modo no administrado de CRDs evita que dos actores peleen por la versión.

¿Vale la pena?

Si tu clúster ya está en Auto Mode, sí, sin mucha vuelta. Te da el modelo de Gateway API (roles separados, rutas por namespace, canary por pesos, ruteo por header) sin agregar un solo componente para operar, y te deja una salida estándar si mañana querés cambiar de implementación. Para clústeres nuevos, refuerza el argumento a favor de Auto Mode que ya hacía en este análisis: cada vez quedan menos razones para mantener controladores de infraestructura a mano.

Donde no alcanza: si necesitás capacidades de un proxy L7 completo (timeouts y reintentos por ruta, mirroring, rate limiting, mTLS entre servicios), un ALB no es la herramienta, y lo razonable es combinar: Gateway de Auto Mode para el borde, y Envoy Gateway o una malla para lo que pasa adentro.

Mi lectura: lo más importante de este lanzamiento no es técnico, es de responsabilidad. Con Ingress, el equipo de plataforma terminaba siendo el cuello de botella de cada cambio de ruteo, o le daba a cada equipo acceso a anotaciones que podían romper el balanceador compartido. Gateway API resuelve eso con un modelo de permisos claro, y ahora AWS lo opera por vos. La limitación real es que estás atado a lo que el ALB sabe hacer, y la lista de lo no soportado no es corta. Para la mayoría de las APIs y frontends que veo en clientes, alcanza y sobra. Mi consejo: habilitalo en modo administrado, empezá migrando una aplicación sin anotaciones raras y usá el canary por pesos desde el primer día.

Recursos

• Anuncio en What's New
• AWS Weekly Roundup del 2 de noviembre de 2026
• Documentación: Gateway API en EKS Auto Mode
• Tags de subnets para EKS Auto Mode
• Guía L7 (ALB) de Gateway API del Load Balancer Controller, con la tabla de compatibilidad
• Guía L4 (NLB) de Gateway API del Load Balancer Controller
• Post de AWS: soporte GA de Gateway API en el Load Balancer Controller
• Post de AWS: toolkit de migración de Ingress a Gateway API
• Precios de Amazon EKS y de Elastic Load Balancing
• AWS re:Post: Envoy Gateway sobre EKS Auto Mode