ECS, EKS ou Fargate: qual escolher para rodar sua API sem virar especialista em Kubernetes

Depois de decidir hospedar um site estatico, o proximo problema pratico costuma ser: como rodar uma API em container na cloud? A resposta da AWS vem com uma sopa de letrinhas — ECS, EKS, Fargate — que ja confunde sozinha, antes mesmo de comparar com Azure e Google Cloud.

Esse artigo parte do pressuposto de que voce ja decidiu qual cloud usar (veja como escolher entre AWS, Azure e Google Cloud se ainda nao decidiu) e agora precisa decidir como rodar containers dentro dela.

1. O erro de comparacao mais comum: ECS, EKS e Fargate nao sao 3 opcoes equivalentes

A confusao mais frequente e tratar ECS, EKS e Fargate como 3 alternativas do mesmo nivel. Na pratica, sao duas decisoes separadas:

• Orquestrador: ECS (orquestrador proprietario da AWS, mais simples) ou EKS (Kubernetes gerenciado pela AWS, mesmo padrao usado em qualquer outra cloud ou on-premise).
• Modo de execucao: Fargate (serverless, sem gerenciar maquina) ou EC2 (voce gerencia as instancias que rodam os containers).

Ou seja, Fargate nao compete com ECS ou EKS — ele e uma forma de rodar qualquer um dos dois sem precisar provisionar e manter servidor. As combinacoes reais sao: ECS+Fargate, ECS+EC2, EKS+Fargate ou EKS+EC2 (ou node groups gerenciados).

2. ECS vs EKS: a decisao que realmente importa

• ECS (Elastic Container Service): orquestrador proprio da AWS, curva de aprendizado menor, integracao mais direta com outros servicos AWS (IAM, CloudWatch, Application Load Balancer). Ideal para quem nao tem experiencia previa com Kubernetes e nao precisa rodar a mesma stack fora da AWS.
• EKS (Elastic Kubernetes Service): Kubernetes gerenciado pela AWS. Faz sentido quando o time ja conhece Kubernetes, quando existe necessidade real de portabilidade entre clouds (ou entre cloud e on-premise), ou quando o projeto depende de ferramentas do ecossistema Kubernetes (Helm charts, operators especificos) que nao tem equivalente no ECS.

Para a maioria dos times pequenos rodando uma API sem exigencia de portabilidade multi-cloud, ECS + Fargate resolve com menos complexidade operacional do que EKS. Kubernetes so compensa quando ha um motivo tecnico concreto, nao porque "e o padrao da industria".

3. Equivalentes em Azure e Google Cloud

Azure

• Azure Container Apps: equivalente direto a ECS+Fargate — voce sobe o container e a plataforma cuida de escala, rede e execucao sem gerenciar maquina.
• AKS (Azure Kubernetes Service): equivalente ao EKS — Kubernetes gerenciado pela Azure, mesma logica de decisao (so escolha se o time ja conhece Kubernetes ou precisa de portabilidade).

Google Cloud

• Cloud Run: equivalente a ECS+Fargate/Container Apps, e hoje considerado o mais simples dos tres para subir um container sem gerenciar nada alem do proprio container, com escala automatica ate zero.
• GKE (Google Kubernetes Engine): equivalente ao EKS/AKS — vale notar que o Google criou o Kubernetes originalmente, entao o GKE costuma ser visto como a implementacao gerenciada mais madura e "nativa" das tres, mesmo que EKS tenha o ecossistema mais amplo por causa do tamanho de mercado da AWS.

4. Framework de decisao

1. O time ja conhece Kubernetes? Se nao, comece pela opcao serverless mais simples da cloud escolhida (Fargate, Container Apps ou Cloud Run). O ganho de aprender Kubernetes raramente compensa para uma API simples.
2. Existe exigencia real de portabilidade? Se o projeto pode precisar rodar em outra cloud ou on-premise no futuro, Kubernetes (EKS, AKS ou GKE) evita reescrever tudo depois, porque e um padrao aberto — ECS, Container Apps e Cloud Run sao proprietarios de cada cloud.
3. O projeto depende de ferramentas especificas do ecossistema Kubernetes? Helm charts, operators ou service mesh especificos so existem no mundo Kubernetes — se o projeto depende disso, a escolha ja esta feita.
4. A API tolera cold start? Opcoes serverless com escala a zero (Cloud Run, Fargate configurado para isso) podem ter um atraso na primeira requisicao apos periodo ocioso — se a API precisa de resposta imediata sempre, vale manter um numero minimo de instancias ativas, o que muda o calculo de custo.

5. Custo e complexidade: gerenciado nao significa simples

• "Gerenciado" reduz o trabalho de manter a infraestrutura (servidor, patch, escala), mas nao reduz a complexidade conceitual do Kubernetes em si — voce ainda precisa entender pods, services, deployments e RBAC mesmo usando EKS, AKS ou GKE.
• Fargate, Container Apps e Cloud Run cobram um premium pela simplicidade: o custo por vCPU/memoria costuma ser mais alto do que gerenciar a mesma capacidade em instancias EC2/VMs tradicionais. Voce esta pagando para nao gerenciar servidor.
• Sempre simule o cenario completo na calculadora oficial da cloud escolhida antes de decidir — o calculo muda bastante dependendo de trafego constante vs. trafego variavel.

6. Erros comuns

• Escolher Kubernetes (EKS/AKS/GKE) "porque e o padrao da industria", sem o time ter experiencia real para operar.
• Migrar um docker-compose.yml direto para Kubernetes sem entender que o modelo de rede e armazenamento e diferente entre os dois.
• Achar que a opcao serverless (Fargate, Container Apps, Cloud Run) e sempre mais barata — ela e mais simples, nao necessariamente mais barata em alta escala constante.
• Ignorar cold start em API que precisa responder rapido sempre, ao usar configuracao de escala a zero.
• Comparar ECS com EKS como se fossem concorrentes diretos, sem entender que Fargate e uma dimensao separada (modo de execucao, nao orquestrador).

7. Checklist antes de escolher

1. Confirme se o time ja tem experiencia real com Kubernetes, nao so teorica.
2. Avalie se existe exigencia concreta de portabilidade multi-cloud ou on-premise.
3. Verifique se o projeto depende de alguma ferramenta especifica do ecossistema Kubernetes.
4. Teste a opcao serverless mais simples da cloud escolhida antes de partir direto para Kubernetes gerenciado.
5. Simule o custo completo (incluindo cold start, se aplicavel) na calculadora oficial da cloud.
6. Documente a decisao e o motivo, para nao repetir a discussao quando o time crescer.

O hub de Cloud reune os demais artigos deste cluster, incluindo o comparativo de hospedagem de site estatico e o guia de escolha inicial entre AWS, Azure e Google Cloud.

Perguntas frequentes

Fargate substitui o ECS ou o EKS? Nao. Fargate e um modo de execucao serverless que funciona tanto com ECS quanto com EKS, nao um orquestrador concorrente.

Preciso saber Kubernetes para rodar container na cloud? Nao, para a maioria dos casos. ECS+Fargate, Azure Container Apps e Google Cloud Run resolvem sem exigir conhecimento de Kubernetes.

Qual e a opcao mais simples entre as tres clouds para rodar uma API em container? Google Cloud Run costuma ser citado como o mais direto das tres, mas ECS+Fargate e Azure Container Apps resolvem o mesmo problema com nivel de esforco parecido.