Amazon EKS: o que a AWS gerencia e o que continua sendo decisão do arquiteto

Quem decide usar o Amazon EKS normalmente já sabe operar Kubernetes. A escolha real não é "Kubernetes ou não": é parar de manter um control plane no ar às 3h da manhã. Um artigo publicado na DEV Community, no perfil softverseadmin, organiza bem essa fronteira e serve como mapa de arquitetura de referência para quem já tem (ou está prestes a colocar) um cluster EKS em produção.

Este texto é para arquiteto, DevOps e SRE que vão desenhar ou já operam esse cluster, não para quem ainda está decidindo se adota Kubernetes.

O problema

Criar um cluster EKS é trivial: eksctl create cluster ou um módulo Terraform resolvem em uma tarde. O problema aparece depois, no intervalo entre "cluster criado" e "cluster pronto pra produção".

A AWS gerencia uma fatia específica: os servidores de API e o etcd, replicados entre zonas de disponibilidade, com patch aplicado pela AWS e cobrança por uma taxa fixa por hora de cluster. Fora disso, tudo é seu: os nós (EC2 ou Fargate), a VPC, o IAM e os add-ons que transformam o cluster em uma plataforma utilizável.

O erro mais comum, segundo o artigo, é esperar uma plataforma de aplicação e receber uma excelente infraestrutura de primitivos. Quem orça zero trabalho de plataforma descobre essas decisões chegando de qualquer forma, sem agenda.

A arquitetura

O fluxo típico de uma requisição em um cluster EKS de produção, do usuário ao dado, segue este caminho:

1. O cliente faz uma requisição HTTPS para um domínio público.
2. O external-dns já mapeou esse domínio para o endereço de um Application Load Balancer, criado automaticamente a partir de um Ingress.
3. O AWS Load Balancer Controller provisionou esse ALB (ou um NLB, dependendo da anotação) com target groups apontando direto para os pods.
4. O cert-manager, integrado à AWS Certificate Manager ou ao Let's Encrypt, garante o certificado TLS na borda.
5. O tráfego chega ao pod, que recebeu um IP real da sua VPC via Amazon VPC CNI, não um IP sintético de overlay.
6. O pod precisa falar com um bucket S3 ou uma fila SQS: ele assume um papel IAM específico via EKS Pod Identity, não a role genérica do nó.
7. Se o pod grava dados, o EBS CSI Driver provisiona um volume gp3 via PersistentVolumeClaim.
8. Em paralelo, o Karpenter observa pods pendentes e, se faltar capacidade, lança um nó do tipo e da zona certos em menos de um minuto, consolidando nós ociosos depois.

Cada seta desse desenho é uma decisão de arquitetura que o EKS não toma por você.

Os serviços envolvidos

Trade-offs

Nenhuma escolha aqui é neutra; cada uma pesa em um pilar diferente do Well-Architected Framework.

Excelência operacional: managed node groups são a opção enfadonha e correta na maioria dos casos, porque a AWS cuida do ciclo de vida da EC2. Self-managed node groups devolvem controle total sobre AMI e bootstrap, mas também devolvem todo patch e todo upgrade como tarefa sua.

Confiabilidade: Fargate isola cada pod em sua própria microVM, o que é ótimo para blast radius, mas vem com restrições reais: sem DaemonSet, sem volume persistente além de EFS, tamanho de pod limitado a um menu fixo e latência de inicialização que workloads de lote toleram e serviços sensíveis a latência não.

Segurança: o erro mais caro do artigo é o node role que faz tudo. Um papel IAM amplo o bastante para qualquer pod do nó é um convite a escalada de privilégio. O Pod Identity resolve isso com papel por workload, e a correção é barata de aplicar desde o primeiro cluster.

Eficiência de desempenho: como os pods consomem IP real da VPC, a densidade de pods por nó é limitada pela capacidade de ENI/IP da instância. Prefix delegation aumenta bastante essa densidade quando necessário, mas isso precisa estar no desenho da sub-rede desde o início, não como correção de incidente.

Otimização de custos e sustentabilidade: Karpenter consolida nós subutilizados automaticamente, o que reduz capacidade ociosa sem intervenção manual, efeito que aparece na fatura (pra menos) e no consumo de energia da frota.

Custo estimado

O artigo aponta três componentes de custo que times costumam subdimensionar:

• Taxa de control plane: cobrada por cluster, hora a hora. Parece pequena isoladamente, mas multiplica rápido quando cada squad cria seu próprio cluster de desenvolvimento e esquece de destruir.
• Nós: o maior item na maioria dos ambientes. Karpenter ajuda ao escolher o tipo de instância mais barato que atende o pod e ao consolidar nós ociosos; capacidade Spot para workloads tolerantes a interrupção reduz ainda mais.
• Perímetro de rede: NAT Gateway, load balancers e transferência de dados, decisões que o desenho da VPC já tomou antes de o cluster existir. Um NAT Gateway por zona de disponibilidade, multiplicado por ambiente, é um item que raramente aparece na planilha inicial.

Suporte padrão de uma versão do Kubernetes no EKS dura cerca de 14 meses a partir do lançamento da versão; depois disso, suporte estendido é cobrado à parte. Isso significa que adiar upgrade de versão tem custo recorrente, não é só risco técnico.

Como adaptar

A escolha de nó muda conforme o perfil da carga de trabalho, e o artigo original sugere um teste prático pra decidir entre EKS e alternativas mais simples como ECS Fargate: qual ecossistema seu time de contratação, suas ferramentas e suas cargas de trabalho existentes já falam.

Para um time pequeno com carga esporádica e sem estado, um cluster só com Fargate é suficiente e elimina a conta de gerenciar nó. Para a maioria dos clusters com demanda variável, managed node groups como linha de base mais Karpenter para picos é a combinação recomendada pelo material. Para quem precisa de AMI customizada ou configuração de kernel fora do padrão, self-managed node groups continuam sendo a válvula de escape, com o custo operacional que isso implica.

Sobre quantidade de clusters, a régua sugerida é: menos do que o instinto manda, mas nunca um só. Separar produção de não produção é o mínimo; a partir daí, blast radius, fronteira de compliance e autonomia de time decidem se vale consolidar com namespaces e IAM por time ou manter clusters dedicados, cientes do custo de cada escolha.

Um ponto final de higiene operacional: clusters que ainda usam o aws-auth ConfigMap editado à mão são um risco de trancar todo mundo fora do cluster com um erro de digitação. Access entries, o mecanismo baseado em API introduzido mais recentemente, substitui essa prática e deveria ser a configuração padrão em qualquer cluster novo criado a partir de agora.

Fonte

DEV Community — #aws: "Amazon EKS in 2026: Managed Kubernetes on AWS, Explained for Working Engineers", publicado no perfil softverseadmin.

Fonte: DEV Community — #aws