ECS vs EKS: containers na AWS sem dogma
Orquestrador nativo simples ou Kubernetes gerenciado com todo o ecossistema: a pergunta que decide 80% dos casos é quem opera, e a conta inclui salários, não só a fatura.
Decidiu rodar containers e sua casa é a AWS. A próxima bifurcação tem duas placas: ECS e EKS. A internet transformou isso em disputa religiosa; a realidade é uma escolha de trade-offs bem comportada, e este artigo a organiza.
O que cada um é
ECS (Elastic Container Service) é o orquestrador proprietário da AWS (aws.amazon.com/ecs): task definitions no lugar de manifests, services que mantêm réplicas, integração nativa e sem costura com o resto da casa (ALB, IAM por task, CloudWatch, SQS). Não há control plane para você ver, nem cobrar: o serviço é de graça; paga-se só pela computação.
EKS (Elastic Kubernetes Service) é o Kubernetes gerenciado da AWS (aws.amazon.com/eks): a AWS opera o control plane (por uma taxa fixa por cluster) e você ganha o Kubernetes de verdade: os objetos padrão, o ecossistema CNCF inteiro (Helm, Argo CD, operadores), e portabilidade de manifests para qualquer outro K8s.
E a peça que muda o jogo dos dois lados: Fargate, o modo serverless de computação: sem nós para gerenciar, você declara CPU/memória por container e a AWS materializa. Funciona com ECS (combinação perfeita) e com EKS (com restrições).
Os critérios, em ordem de peso
1. Seu time conhece Kubernetes (ou precisa conhecer)? Esta é a pergunta que decide 80% dos casos. O EKS entrega o K8s, e cobra o K8s: a curva de conceitos, upgrades de versão a cada poucos meses, add-ons (CNI, CSI, autoscaler) para manter. Se o time não tem (nem quer construir) essa competência, o ECS entrega orquestração de produção com uma fração da superfície de operação.
2. Você precisa do ecossistema ou da portabilidade? Ferramentas CNCF, operadores prontos (bancos, filas, ML), múltiplos ambientes fora da AWS, política corporativa multi-cloud, ou plataforma comum para muitos times: pontos legítimos para o EKS. Se "portabilidade" é teórica (como costuma ser), não pague por ela.
3. Quanto de time de plataforma você tem? ECS + Fargate opera-se com um time de produto: esteira, task definition no Terraform, pronto. EKS saudável pressupõe gente cuidando da plataforma como produto interno. A conta honesta inclui esses salários, não só a fatura AWS.
O resumo de consultoria
- Um produto, um a três times, tudo na AWS: ECS com Fargate é o padrão sensato: simples, barato de operar, integração impecável. É a resposta certa para a maioria das empresas brasileiras que atendemos.
- Plataforma para muitos times, ecossistema K8s como requisito, competência existente: EKS, com investimento consciente em quem o opera.
- Migração futura ECS → EKS? Menos dolorosa do que parece (as imagens são as mesmas); começar simples não te prende.
O erro clássico, de novo, é o de sempre: escolher EKS "porque Kubernetes está no roadmap de carreira de alguém" e descobrir que o produto virou refém da plataforma. Complexidade se compra com evidência, não com currículo.
Checklist de implantação (para qualquer um dos dois)
- Imagens com tags imutáveis, construídas na esteira.
- IAM por task/service account: menor privilégio por container, não credencial gorda no cluster.
- Logs e métricas centralizados desde o dia um.
- Health checks e auto-scaling configurados, o tema que fecha esta série no próximo artigo.
Fazer essa escolha com a conta completa (e implantar a esteira em volta) é parte do nosso serviço de DevOps e Deploy.
Time pequeno e tudo na AWS? Descreva seu cenário para a IA da Rabelo Digital, aqui no canto da tela, e ela confirma se o ECS+Fargate resolve ou se há motivo real para EKS. Sem formulário, sem espera.
Deixe um Comentário