EKS Auto Mode passa a aplicar security groups por Pod sem exigir node pool dedicado

A AWS anunciou em 11 de novembro de 2026 que o EKS Auto Mode suporta security groups for Pods, permitindo isolar o tráfego de cada carga de trabalho sem separar workloads em node pools distintos.

O que mudou

O Amazon EKS Auto Mode agora suporta security groups for Pods, segundo anúncio da AWS publicado em 11 de novembro de 2026. O recurso deixa aplicar regras dedicadas de security group do Amazon EC2 a Pods individuais, em vez de depender apenas do security group herdado do nó.

Na prática, dois workloads rodando no mesmo nó podem carregar security groups diferentes, com segmentação de rede sem precisar criar um node pool separado para cada aplicação. É exatamente o problema que hoje empurra muita equipe a multiplicar node groups só para isolar tráfego por motivo de compliance ou de arquitetura multi-tenant.

O recurso estende os controles de rede que você já usa na VPC até o nível do Pod. Isso inclui autorizar conexão a bancos como Amazon RDS e Amazon ElastiCache que liberam acesso por security group, seguindo as mesmas regras já aplicadas ao resto da VPC.

A configuração é feita por um recurso SecurityGroupPolicy, que você aplica no cluster para dizer quais Pods recebem quais security groups. Pods que não casam com nenhuma política continuam usando o security group do nó onde rodam, sem quebra de compatibilidade.

apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: payments-sg-policy
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  securityGroups:
    groupIds:
      - sg-0123456789abcdef0

Onde está disponível

O recurso funciona em clusters rodando Kubernetes versão 1.36 ou posterior. A AWS diz que ele está disponível em todas as regiões onde o EKS Auto Mode já é suportado, mas o anúncio não lista as regiões nominalmente.

A fonte não confirma explicitamente se a região América do Sul (São Paulo), sa-east-1, está entre elas. Quem roda cluster por lá precisa checar a tabela de disponibilidade regional do EKS Auto Mode no console ou na documentação antes de planejar a migração.

Quanto custa

Security groups for Pods está incluído no EKS Auto Mode sem cobrança adicional, segundo o anúncio. Não há taxa por política, por Pod ou por security group aplicado além do que você já paga pelo Auto Mode em si.

O anúncio não detalha o modelo de cobrança do Auto Mode como um todo (gestão de cluster mais capacidade de computação), então quem ainda não usa o modo deve consultar a página de preços do EKS antes de comparar com um cluster EKS tradicional com node groups próprios.

Como começar

Para usar o recurso, o caminho é:

1. Confirmar que o cluster está rodando Kubernetes 1.36 ou superior e com o EKS Auto Mode habilitado.
2. Criar os security groups na VPC com as regras de entrada e saída necessárias para cada workload (por exemplo, liberar porta 5432 para o Amazon RDS).
3. Escrever um manifesto SecurityGroupPolicy apontando o podSelector para o workload alvo e listando os groupIds.
4. Aplicar com kubectl apply -f security-group-policy.yaml no namespace correto.
5. Validar que os Pods recriados após a política passam a usar o security group definido, checando a interface de rede atribuída ao Pod.

O que muda para quem já usa

Em resumo: quem já segmenta tráfego por security group em cluster EKS tradicional conhece esse padrão, mas até agora isolar tráfego por Pod normalmente empurrava a equipe a multiplicar node pools dedicados a cada workload com exigência própria de rede. No Auto Mode, essa segmentação passa a ser possível no mesmo nó, via política aplicada diretamente ao Pod, o que reduz a lista de coisas que a equipe de plataforma precisa operar manualmente.

O ganho concreto é poder consolidar workloads de sensibilidade de rede diferente no mesmo nó, em vez de manter node pools exclusivos só para isolamento, o que historicamente gerava nós subutilizados e fatura mais alta. Para um cluster multi-tenant típico, isso pode significar menos node groups dedicados a cada time ou aplicação regulada.

O que ainda fica em aberto, porque o anúncio não detalha: quais são os limites técnicos por trás da implementação do recurso no Auto Mode, e qual é o comportamento exato quando um Pod casa com mais de uma SecurityGroupPolicy ao mesmo tempo. Vale testar em ambiente de homologação antes de aplicar em produção.

Fonte: AWS What's New