ECS vs EKS: Qual serviço de containers escolher na AWS

A pergunta aparece toda vez que alguém vai containerizar algo na AWS: ECS ou EKS? A resposta honesta: depende da sua equipe, não da sua aplicação.

A diferença fundamental

ECS (Elastic Container Service) é o orquestrador proprietário da Amazon. Simples, opinionado, profundamente integrado ao ecossistema AWS.

EKS (Elastic Kubernetes Service) é Kubernetes gerenciado. Padrão de mercado, portável, complexo.

Quando escolher ECS

Você quer entregar features, não operar Kubernetes

# task-definition.tf — a simplicidade do ECS
resource "aws_ecs_task_definition" "api" {
  family                   = "minha-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 512
  memory                   = 1024
  execution_role_arn       = aws_iam_role.ecs_task_exec.arn

  container_definitions = jsonencode([{
    name  = "api"
    image = "${aws_ecr_repository.api.repository_url}:latest"
    
    portMappings = [{ containerPort = 3000 }]
    
    environment = [
      { name = "NODE_ENV", value = "production" }
    ]
    
    secrets = [
      { name = "DATABASE_URL", valueFrom = aws_ssm_parameter.db_url.arn }
    ]
    
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"  = "/ecs/minha-api"
        "awslogs-region" = "us-east-1"
      }
    }
  }])
}

Com ECS + Fargate você não gerencia nenhum servidor. Nenhuma versão de kubelet para atualizar, nenhum node group para otimizar.

Integração nativa com AWS

• ALB: roteamento por path/header sem Ingress Controller
• IAM: roles diretamente nas tasks, sem IRSA ou Pod Identity
• Service Connect: service mesh simples sem Istio
• CloudWatch: logs/métricas sem Prometheus + Grafana

Quando escolher EKS

Portabilidade é um requisito real

# O mesmo manifesto roda em GKE, AKS, on-premises
apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    spec:
      containers:
      - name: api
        image: minha-api:1.2.3
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Se sua empresa tem estratégia multi-cloud ou on-prem, Kubernetes é a escolha óbvia.

Ecossistema rico de ferramentas

Algumas coisas ainda não têm equivalente nativo no ECS:

• Argo CD / Flux: GitOps avançado
• KEDA: autoscaling baseado em eventos (SQS, Kafka, etc.)
• Karpenter: provisionamento inteligente de nodes
• Istio / Linkerd: observabilidade e controle de tráfego avançados

Time já conhece Kubernetes

Esse é o critério mais subestimado. Um time experiente em Kubernetes vai operar EKS melhor do que um time novo vai operar ECS. A curva de aprendizado do Kubernetes é real — 3 a 6 meses para operar com confiança.

Comparativo de custos

ECS com Fargate

3 tasks × (0.5 vCPU + 1GB RAM):
- CPU:    3 × 0.5 × $0.04048/hora = $0.06/hora
- Memória: 3 × 1 × $0.004445/hora = $0.013/hora
- Total:  ~$53/mês para 3 tasks 24/7

EKS com EC2 (Managed Node Group)

EKS control plane:           $72/mês (fixo)
2x t3.medium (worker nodes): ~$60/mês
Total:                       ~$132/mês mínimo

(sem nenhuma workload rodando ainda)

Para workloads pequenas a médias, ECS + Fargate sai mais barato. EKS começa a compensar quando você tem dezenas de serviços compartilhando os mesmos nodes.

Minha recomendação prática

O erro mais comum: escolher EKS porque “todo mundo usa Kubernetes” e depois gastar 30% do tempo de engenharia só mantendo o cluster.

Escolha a ferramenta que sua equipe vai conseguir operar sem dor. Para a maioria das empresas brasileiras de médio porte, isso ainda é ECS.