Chegou a hora de escolher um orquestrador de containers na AWS e você está entre ECS e EKS (Kubernetes)? Essa dúvida é mais comum do que imagina. Cada um tem seu lugar dependendo do contexto do projeto.
ECS: simples e direto ao ponto
O Elastic Container Service é a solução nativa da AWS para orquestração de containers. É como aquele funcionário que faz exatamente o que precisa, sem complicação.
Quando usar ECS:
- Time pequeno ou com pouca experiência em Kubernetes
- Aplicações simples a médias que não precisam de recursos avançados
- Orçamento apertado (sem custo adicional de control plane)
- Integração forte com outros serviços AWS
A gente implementou ECS para um e-commerce que precisava rodar apenas 3 microsserviços. Em duas semanas estava tudo funcionando com Fargate, sem precisar gerenciar nada de infraestrutura.
Exemplo prático com ECS
Aqui está um task definition básico para uma API:
{
"family": "api-task",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"executionRoleArn": "arn:aws:iam::123456:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"name": "api",
"image": "myapp:latest",
"portMappings": [
{
"containerPort": 3000,
"protocol": "tcp"
}
]
}
]
}EKS: poder total do Kubernetes
O Elastic Kubernetes Service traz toda a flexibilidade do Kubernetes como serviço gerenciado. É a Ferrari dos orquestradores, mas exige um piloto experiente.
Quando usar EKS:
- Time experiente em Kubernetes
- Aplicações complexas com muitos microsserviços
- Necessidade de recursos avançados (service mesh, operators customizados)
- Estratégia multi-cloud ou hybrid
- Compliance rigoroso com controle granular
Diferenças na prática
Curva de aprendizado: ECS você aprende em dias. Kubernetes pode levar meses para dominar direito.
Custo: ECS com Fargate cobra só pelos recursos usados. EKS cobra $0.10/hora pelo control plane mais os worker nodes.
Flexibilidade: Kubernetes é infinitamente mais flexível. ECS faz bem o básico, mas tem limitações.
Caso real: migração que valeu a pena
Um cliente nosso começou com ECS rodando 5 aplicações simples. Funcionava perfeitamente por 2 anos. Quando cresceram para 30+ microsserviços com necessidades de service mesh e gitops avançado, migramos para EKS.
A migração levou 3 meses e custou 40% mais caro inicialmente. Mas ganharam:
- Deploy automático com ArgoCD
- Service mesh com Istio
- Observabilidade granular com Prometheus
- Políticas de segurança com OPA Gatekeeper
Terraform para EKS básico
module "eks" {
source = "terraform-aws-modules/eks/aws"
cluster_name = "meu-cluster"
cluster_version = "1.28"
vpc_id = module.vpc.vpc_id
subnet_ids = module.vpc.private_subnets
eks_managed_node_groups = {
main = {
min_size = 1
max_size = 10
desired_size = 3
instance_types = ["m5.large"]
}
}
}Monitoramento e observabilidade
ECS se integra nativamente com CloudWatch. É automático e funciona bem para a maioria dos casos.
EKS você monta sua própria stack. A gente sempre recomenda:
- Prometheus para métricas
- Grafana para dashboards
- Jaeger para tracing distribuído
- ELK ou CloudWatch Logs para logs centralizados
Segurança: cada um com sua abordagem
ECS usa IAM roles direto nas tasks. É simples e efetivo:
{
"taskRoleArn": "arn:aws:iam::123456:role/MyTaskRole",
"executionRoleArn": "arn:aws:iam::123456:role/ecsTaskExecutionRole"
}EKS precisa de mais configuração. RBAC, service accounts, pod security standards. Mais complexo, porém muito mais granular.
Nossa recomendação prática
Comece com ECS se:
- É seu primeiro projeto com containers
- Time pequeno (até 5 devs)
- Aplicação com menos de 10 serviços
- Prazo apertado para entrega
Vá direto para EKS se:
- Time já conhece Kubernetes
- Arquitetura de microsserviços complexa
- Precisa de portabilidade entre clouds
- Tem requisitos específicos que só Kubernetes atende
A verdade é que não existe escolha errada. ECS resolve 80% dos casos com 20% do esforço. EKS resolve 100% dos casos, mas exige conhecimento e tempo.
A gente já migrou projetos nos dois sentidos. De ECS para EKS quando a complexidade aumentou, e de EKS para ECS quando o time queria simplicidade.
O importante é avaliar honestamente onde sua equipe está hoje e onde quer chegar nos próximos 2 anos.
