Amazon EKS na Prática: o Guia Avançado de Kubernetes Gerenciado na AWS

Eduardo Souza | CEO Dominit

Toda empresa que atinge um certo nível de complexidade em containers esbarra na mesma decisão: continuar operando o Kubernetes por conta própria — com toda a carga operacional de manter o control plane no ar — ou migrar para um serviço gerenciado que absorve essa complexidade. O Amazon EKS existe para resolver exatamente esse problema. Neste guia avançado, você vai entender quando o EKS faz mais sentido do que ECS ou Fargate, como estruturar a arquitetura de um cluster em produção, o modelo de segurança via IRSA, e como controlar custo e autoscaling sem sacrificar performance.

O Que É o Amazon EKS e Por Que Empresas Escolhem Kubernetes Gerenciado

O Amazon EKS é o serviço gerenciado de Kubernetes da AWS: a AWS opera e escala o control plane (os componentes que gerenciam o estado do cluster), enquanto a empresa mantém controle total sobre os nós de trabalho e as cargas de contêiner que rodam neles. A diferença em relação a rodar Kubernetes “na unha” em cima de EC2 é a eliminação do trabalho mais arriscado e menos diferenciado: patch de segurança do control plane, alta disponibilidade do etcd, upgrades de versão do próprio Kubernetes.

A escolha por Kubernetes gerenciado, em vez de alternativas mais simples da própria AWS, normalmente aparece quando a empresa já tem investimento real no ecossistema Kubernetes — seja por portabilidade entre nuvens, por usar ferramentas do ecossistema CNCF, ou porque o time já tem essa competência e não quer reaprender um modelo de orquestração proprietário.

EKS vs ECS vs Fargate: Como Escolher o Modelo de Orquestração Certo

Não existe modelo de orquestração “melhor” de forma absoluta — a escolha certa depende do que a equipe já sabe operar e do quanto de controle a carga de trabalho exige:

Critério	Amazon EKS	Amazon ECS	AWS Fargate
Modelo de orquestração	Kubernetes (padrão de mercado, portável)	Proprietário da AWS, mais simples	Serverless, sem gerenciar servidor
Curva de aprendizado	Alta — exige conhecimento de Kubernetes	Baixa/média	Baixa
Portabilidade entre nuvens	Alta (mesmo padrão em qualquer cloud)	Nenhuma (específico da AWS)	Nenhuma (específico da AWS)
Controle operacional	Alto (mas com mais responsabilidade)	Médio	Baixo (AWS gerencia a infraestrutura)
Ecossistema de ferramentas	Amplo (Helm, operators, CNCF)	Limitado ao ecossistema AWS	Limitado ao ecossistema AWS
Melhor para	Times com Kubernetes já maduro, multi-cloud	Times que querem simplicidade dentro da AWS	Cargas simples, sem gestão de nó

Na prática, muitas empresas usam EKS combinado com Fargate (perfis Fargate no EKS) para cargas de trabalho que não precisam de controle fino sobre o nó, e node groups gerenciados para cargas que exigem tipo de instância ou configuração específica — não é uma escolha binária.

Arquitetura de um Cluster EKS em Produção

Um cluster EKS bem desenhado para produção tem algumas decisões de arquitetura que precisam ser feitas conscientemente, não por padrão:

Node groups gerenciados vs self-managed — node groups gerenciados pela AWS reduzem trabalho operacional de patch e atualização; self-managed dá mais controle sobre a AMI e configuração do nó, útil em cenários com requisitos muito específicos.

VPC CNI e networking — o EKS usa o plugin VPC CNI por padrão, atribuindo IPs da própria VPC diretamente aos pods, o que simplifica integração com security groups e outros recursos AWS, mas exige planejamento de espaço de endereçamento IP — um erro comum é subdimensionar a VPC e esgotar IPs disponíveis conforme o cluster escala.

Perfis Fargate para cargas específicas — permitem rodar determinados namespaces ou workloads sem gerenciar nó nenhum, útil para cargas esporádicas ou de baixa previsibilidade, enquanto workloads centrais ficam em node groups dimensionados sob medida.

Múltiplos node groups por tipo de carga — separar node groups por perfil de carga (workloads de CPU intensiva, workloads de memória intensiva, workloads com GPU) evita que o Kubernetes precise fazer scheduling complexo demais num pool único e heterogêneo.

Segurança no EKS: IAM Roles for Service Accounts e Pod Identity

O maior risco de segurança em clusters Kubernetes mal configurados é dar às aplicações mais permissão AWS do que elas precisam — geralmente porque é mais fácil dar a permissão do nó inteiro do que configurar acesso granular por aplicação. O EKS resolve isso através de dois mecanismos:

IRSA (IAM Roles for Service Accounts) — permite associar uma role IAM específica a uma service account do Kubernetes, para que cada pod assuma apenas a permissão que sua própria aplicação precisa, não a permissão do nó inteiro onde está rodando.

EKS Pod Identity — uma evolução mais simples do mesmo conceito, reduzindo a configuração necessária para associar identidade AWS a cargas de trabalho no cluster, sem depender de OIDC federation manual.

Sem um desses dois mecanismos configurados corretamente, é comum encontrar clusters onde qualquer pod comprometido tem acesso a todas as permissões AWS do node group inteiro — exatamente o tipo de risco que uma revisão Well-Architected no pilar de Segurança deveria capturar.

Observabilidade e Autoscaling no EKS

Um cluster em produção sem autoscaling bem configurado ou sem visibilidade real do que está acontecendo dentro dele é um risco operacional silencioso:

Karpenter — o autoscaler de nós mais recomendado atualmente para EKS, substituindo o Cluster Autoscaler tradicional em boa parte dos casos novos: provisiona nós sob medida para os pods pendentes, considerando tipo de instância, zona de disponibilidade e custo, de forma mais rápida e granular.

Horizontal Pod Autoscaler (HPA) — escala o número de réplicas de um pod com base em métricas (CPU, memória, ou métricas customizadas), enquanto o autoscaler de nó garante que exista capacidade de infraestrutura disponível para essas réplicas rodarem.

Container Insights e observabilidade — sem métricas e logs centralizados por container, diagnosticar um problema de performance num cluster com dezenas de microsserviços vira tentativa e erro. Ferramentas nativas da AWS (CloudWatch Container Insights) ou do ecossistema Kubernetes (Prometheus, Grafana) precisam estar no lugar antes do incidente, não depois.

Custos do EKS: Como Otimizar Sem Perder Performance

O EKS cobra uma taxa fixa por hora por cluster, mais o custo da infraestrutura de computação subjacente (EC2 ou Fargate) — o que significa que o principal alavanca de otimização de custo não está no EKS em si, mas em como a capacidade computacional é dimensionada e utilizada:

Rightsizing de node groups — a mesma disciplina de FinOps que já se aplica a instâncias EC2 tradicionais se aplica aos nós do cluster: instâncias superdimensionadas para a carga real do pod são desperdício, só que mais difícil de enxergar porque está “escondido” atrás de uma camada de orquestração.

Spot Instances para cargas tolerantes a interrupção — workloads stateless e resilientes a reinício se beneficiam de rodar em node groups Spot, com desconto significativo em relação ao preço on-demand.

Bin packing eficiente — o Karpenter e um bom dimensionamento de requests/limits de recursos por pod reduzem a “gordura” entre o que é reservado e o que é realmente usado, o mesmo tipo de desperdício que já cobrimos no guia de FinOps AWS.

Migrando Cargas de Trabalho Existentes para o EKS

Empresas migrando de uma infraestrutura tradicional (VMs, ECS, ou Kubernetes self-managed) para o EKS costumam seguir uma sequência que reduz risco:

Comece por uma carga de trabalho stateless e não crítica — para validar padrões de deployment, observabilidade e autoscaling antes de migrar sistemas centrais do negócio.

Padronize manifests e Helm charts antes de escalar o número de aplicações — decisões de configuração tomadas ad-hoc na primeira aplicação viram dívida técnica multiplicada quando repetidas em dezenas de outras.

Trate migração de dado com stateful workloads separadamente — bancos de dados e sistemas com estado exigem uma estratégia própria de migração, geralmente fora do cluster Kubernetes ou usando operators especializados, não o mesmo processo usado para aplicações stateless.

Empresas sem profundidade técnica interna em Kubernetes se beneficiam de um parceiro certificado AWS para conduzir a primeira migração — o custo de errar decisões de arquitetura numa fase inicial costuma ser maior do que o custo de apoio especializado.

O Futuro do Kubernetes Gerenciado na AWS

A tendência clara no ecossistema EKS é reduzir ainda mais a carga operacional que sobra para o cliente — Karpenter e EKS Pod Identity são exemplos de recursos que existem para eliminar configuração manual que antes era necessária. Ao mesmo tempo, a integração entre EKS e cargas de trabalho de IA está crescendo, com suporte nativo a GPU e frameworks de inferência rodando em containers gerenciados pelo mesmo cluster que já orquestra o resto da aplicação.

Para empresas avaliando arquitetura de containers como parte de uma revisão mais ampla, vale revisar o AWS Well-Architected Framework antes de tomar decisões estruturais de longo prazo sobre orquestração — o pilar de Eficiência de Performance tem perguntas específicas sobre escolha de serviço de compute que se aplicam diretamente a essa decisão.

Perguntas Frequentes Sobre Amazon EKS

Amazon EKS é mais caro que ECS?

O EKS tem uma taxa fixa por hora por cluster que o ECS não tem, mas a diferença de custo real depende mais de como a capacidade de computação é dimensionada do que do serviço de orquestração em si. Para operações pequenas, ECS costuma ser mais barato; para operações que já precisam de portabilidade Kubernetes, o custo adicional do EKS geralmente se justifica.

Preciso saber Kubernetes para usar o Amazon EKS?

Sim, de forma substancial. O EKS gerencia o control plane, mas a operação dos workloads, deployments e configuração de rede dentro do cluster ainda exige conhecimento real de Kubernetes — não é uma abstração que elimina essa necessidade.

O que é IRSA e por que ele importa?

IAM Roles for Service Accounts é o mecanismo que permite dar a cada aplicação dentro do cluster apenas a permissão AWS que ela precisa, em vez de toda aplicação herdar a permissão do nó inteiro — um dos controles de segurança mais importantes num cluster EKS em produção.

Karpenter substitui o Cluster Autoscaler?

Na maioria dos casos novos, sim — o Karpenter provisiona nós de forma mais rápida e granular, considerando tipo de instância e custo. O Cluster Autoscaler tradicional ainda é usado em cenários com requisitos mais específicos de compatibilidade.

Quando faz mais sentido usar Fargate em vez de node groups no EKS?

Quando a carga de trabalho não exige controle fino sobre o tipo de instância ou configuração do nó, e o objetivo é reduzir ao máximo a carga operacional de gerenciar servidor — comum em workloads esporádicas ou de baixa previsibilidade de uso.

Amazon EKS Como Investimento em Portabilidade e Maturidade Operacional

O Amazon EKS não é a escolha mais simples para rodar containers na AWS — essa distinção pertence a ECS e Fargate. É a escolha certa quando a empresa já decidiu que quer o padrão Kubernetes, com todo o ecossistema e portabilidade que isso traz, e está disposta a investir na maturidade operacional que esse padrão exige em troca.

As empresas que tratam a adoção do EKS como uma jornada de maturidade — começando por cargas não críticas, investindo em observabilidade e autoscaling antes de escalar o número de aplicações — são as que conseguem extrair o valor real do Kubernetes gerenciado, em vez de recriar, dentro do cluster, a mesma complexidade operacional que o serviço gerenciado deveria eliminar.