EKS Auto Mode agora provisiona ALB e NLB nativamente via Gateway API

O que mudou em 28 de outubro

Desde 28 de outubro de 2026, o Amazon EKS Auto Mode suporta nativamente a Gateway API do Kubernetes. Quem define GatewayClass, Gateway e HTTPRoute (ou GRPCRoute, TCPRoute, UDPRoute) deixa de precisar de um controller externo: o Auto Mode provisiona e opera o Application Load Balancer ou o Network Load Balancer por trás desses recursos.

Na prática, isso elimina três tarefas que todo arquiteto de EKS conhece de cor: instalar o AWS Load Balancer Controller, manter o Helm chart atualizado e cablear a IAM role que o controller usa para falar com a API da AWS. Dois controllers passam a rodar por conta da AWS: eks.amazonaws.com/gateway-alb para L7 e eks.amazonaws.com/gateway-nlb para L4, coexistindo sem conflito com Envoy Gateway, Istio ou outras implementações que já estejam no cluster.

Por que isso fecha uma lacuna do Auto Mode

O Auto Mode sempre prometeu que a AWS opera a infraestrutura do cluster, mas até aqui o load balancing gerenciado só entendia Ingress e Service do tipo LoadBalancer. Quem queria Gateway API tinha que reinstalar um controller por fora, contradizendo a própria proposta do Auto Mode de tirar peça operacional das mãos do time.

O problema ficou mais urgente porque o Ingress NGINX foi descontinuado em março de 2026, e a maior parte dos times já estava migrando para Gateway API de qualquer forma. A diferença central do modelo novo em relação ao Ingress é a divisão de responsabilidade em três camadas: o time de plataforma define a GatewayClass, o time de operação de cluster define o Gateway (listeners, hostnames, quais namespaces podem anexar rotas) e cada time de aplicação define suas próprias rotas no namespace dele.

O Auto Mode observa esses recursos, mapeia para load balancers, listeners, regras e target groups, corrige drift e escreve o status de volta no Gateway e nas rotas: é a mesma lógica de reconciliação do AWS Load Balancer Controller, só que operada pela AWS.

Como habilitar

É uma configuração em nível de cluster, dentro de kubernetesNetworkConfig.elasticLoadBalancing.gatewayApi:

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

Com crds.managed: true, a AWS instala e mantém as CRDs da Gateway API v1 (e recusa tocar em CRDs existentes mais antigas que v1). Com false, o time é dono das CRDs, o que faz sentido quando outra implementação no mesmo cluster precisa de uma versão específica. Um detalhe que custa tempo de debug: não esqueça das tags de subnet, porque o Auto Mode usa elas para decidir onde colocar load balancers públicos e internos, e tag faltando é a causa número um de um Gateway que nunca fica Programmed.

Um exemplo real: Gateway compartilhado com canary

Um padrão comum é um Gateway compartilhado num namespace de infraestrutura, com listeners HTTP e HTTPS, liberando anexação de rota só para namespaces com um label específico:

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: 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"

Repare que não há referência a certificado no listener HTTPS: o controller encontra o certificado ACM correspondente pelo hostname e acompanha renovações automaticamente, sem exigir mudança no manifesto. Crie a GatewayClass antes do resto, porque há um pequeno atraso até ela ficar disponível para referência. Com o Gateway no ar, o time de pagamentos envia um canary de 10% a partir do próprio namespace:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
 name: payments
 namespace: payments
spec:
 parentRefs:
 - name: edge
 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 check e deregistration delay entram numa TargetGroupConfiguration apontada para o Service via spec.targetReference.name. Baixar o deregistration delay do padrão de 300 segundos para 30 torna os rollouts visivelmente mais rápidos. Para confirmar que tudo subiu, kubectl wait --for=condition=Programmed gateway/edge -n infra --timeout=10m e kubectl get httproute -A; se uma rota não aparecer, o campo status.parents registra o motivo da rejeição.

O que um ALB não faz (ainda)

Essa é a parte que precisa ser lida antes de migrar qualquer coisa crítica. A tabela de compatibilidade publicada pela AWS para o Load Balancer Controller deixa claro que nem tudo que a Gateway API permite o ALB entrega:

Redirects com ReplacePrefixMatch também precisam trocar esquema, porta ou host, senão o ALB rejeita como loop. Quem depende de timeout e retry por rota vai precisar de um proxy L7 de verdade na frente, porque isso simplesmente não existe num ALB.

Migrando de Ingress sem downtime

Ingress e Gateway API rodam lado a lado no mesmo cluster, então a migração pode ser aplicação por aplicação. O toolkit lbc-migrate, lançado pela AWS em julho de 2026, traduz recursos Ingress do Load Balancer Controller, suas anotações e IngressGroups em manifestos de Gateway API, com suporte a Gateway em modo dry-run. Como ele mira o controller tradicional, depois de gerar os manifestos é preciso trocar a GatewayClass para eks.amazonaws.com/gateway-alb, aplicar, validar, mover o DNS (pesos no Route 53 ajudam) e só então apagar o Ingress antigo.

Quanto custa

O suporte a Gateway API em si não tem cobrança própria. A conta continua sendo o cluster EKS (US$ 0,10/hora no suporte padrão), a taxa de gestão do Auto Mode sobre as instâncias que ele roda, e os load balancers: em us-east-1, um ALB custa US$ 0,0225/hora mais US$ 0,008 por LCU, e um NLB, US$ 0,0225/hora mais US$ 0,006 por NLCU.

No artigo original, Matias Martinez estima que um único Gateway compartilhado equivale a um ALB, cerca de US$ 16,40/mês só em horas, antes das LCUs. Consolidar cinco ALBs isolados de Ingress num único Gateway com rotas por namespace economizaria, segundo essa conta, por volta de US$ 65/mês apenas na parte de horas. Vale ficar de olho na contagem de regras: avaliações de regra do ALB além das dez primeiras consomem LCU.

Disponibilidade no Brasil

O recurso está disponível em toda região onde o EKS Auto Mode existe, incluindo São Paulo (sa-east-1). O plano de dados continua sendo um ALB ou NLB dentro da VPC do cliente, na mesma região, então o TLS termina localmente e o tráfego entre load balancer e pods em zonas de disponibilidade diferentes segue cobrado como de costume.

Pegadinhas antes do primeiro deploy

Cinco pontos que valem checar antes de habilitar em produção:

• CRDs antigas bloqueiam o modo gerenciado. Se um experimento anterior deixou CRDs de Gateway API abaixo de v1 no cluster, a atualização para crds.managed: true é rejeitada e nada muda até elas serem atualizadas ou o modo passar para não gerenciado.
• Rotas L4 ainda são experimentais no upstream. TCPRoute e UDPRoute vivem no canal experimental da Gateway API, então confira se as CRDs instaladas incluem esses recursos antes de depender da classe NLB.
• Manifestos de outras implementações pedem retrabalho. Rotas escritas para Envoy Gateway ou Istio costumam referenciar Secret de TLS, timeouts ou filtros de retry; nada disso se aplica aqui, já que o certificado vem do ACM e timeout/retry não existem num ALB.
• O debug é pelo status, não por log. Não há pod de controller para acompanhar com kubectl logs; o status do Gateway e de cada rota é a principal ferramenta de diagnóstico, então vale incluir kubectl describe no runbook.
• Gateway compartilhado é blast radius compartilhado. Um ALB único sai mais barato, mas uma regra mal escrita numa rota pode afetar regras de menor precedência na mesma rota; manter rotas pequenas e com um dono único por rota reduz esse risco.

A parte mais importante deste lançamento é sobre propriedade, não sobre funcionalidades.

The most important part of this launch is about ownership, not features.Matias Martinez, autor do artigo original na CloudAcademy.ar

O ponto central, segundo essa leitura, é que a Gateway API resolve um problema de modelo de permissão que o Ingress nunca resolveu bem: ou o time de plataforma virava gargalo para toda mudança de roteamento, ou distribuía anotações que podiam quebrar um load balancer compartilhado. Agora a AWS opera a implementação, mas a restrição real é que o time fica limitado exatamente ao que um ALB sabe fazer, e a lista do que ele não suporta não é curta.

Fonte: DEV Community — #aws