AWS ECS (Elastic Container Service)

O Amazon ECS é o serviço de orquestração de contêineres nativo da AWS, responsável por agendar e executar contêineres Docker em clusters gerenciados. Seu modelo abstrai a complexidade de manter um control plane: você define o que executar em uma task definition e o quanto executar em um service, e a plataforma cuida do agendamento, do ciclo de vida e das integrações com ALB, IAM, CloudWatch e Auto Scaling. A escala de operação do serviço dá credibilidade ao modelo: a AWS processa na casa de bilhões de tasks ECS por semana, distribuídas em contas de clientes dos mais variados portes. Para times cujo backend inteiro já vive na AWS, o ECS costuma entregar o essencial da orquestração com custo operacional menor que Kubernetes. Em 2025, o lançamento do ECS Managed Instances fechou a lacuna de controle de infraestrutura, combinando simplicidade do Fargate com flexibilidade de instâncias EC2.

Conceito e modelo de objetos

O ECS organiza a operação em três objetos principais. O cluster é o agrupamento lógico de capacidade, que pode vir de instâncias EC2, de Fargate ou de Managed Instances. A task definition é a especificação declarativa da aplicação: imagem, CPU, memória, variáveis, portas, credenciais, log configuration e health check. A task é uma instância em execução dessa definição, e o service mantém um número desejado de tasks saudáveis, faz rolling deployments e se recupera de falhas automaticamente.

O modelo é mais simples que o Kubernetes porque a AWS substituiu a taxonomia extensível por um conjunto fechado de blocos integrados. O preço é menor flexibilidade para casos exóticos; a vantagem é que quase todo caso comum, de balanceamento a secrets, tem caminho oficial e documentado.

Launch types: EC2, Fargate e Managed Instances

O ECS oferece três formas de fornecer capacidade, e escolher entre elas é a decisão arquitetural mais importante do serviço. O launch type EC2 administra você mesmo um grupo de instâncias com o agente ECS; Fargate entrega contêineres sem servidor, cobrando por vCPU e GB de memória por segundo de uso; e o ECS Managed Instances, lançado em 2025, administra instâncias EC2 sob o mesmo modelo simplificado do Fargate.

O Fargate elimina patching de sistema operacional, dimensionamento de grupo de instâncias e planejamento de bin packing; em contrapartida, cobra prêmio por vCPU e tem restrições, como o teto de 120 GB de memória por task e ausência de privileged. Quando o workload precisa dessas capacidades, o ECS Managed Instances surge como terceira via: o time continua definindo tasks e services da mesma forma, mas por trás existem instâncias EC2 escolhidas para o caso, incluindo GPU, containers privileged e memória além do limite do Fargate, sem que a plataforma exponha a complexidade de administrar um cluster.

Integração com ALB, IAM e CloudWatch

A integração é o grande diferencial do ECS em produção. Um service conectado a um Target Group registra automaticamente cada task no ALB, respeitando portas dinâmicas com host e path routing. O IAM elimina a gestão de credenciais embutidas: cada task assume uma task role com permissões granulares para S3, SQS, DynamoDB e o que mais for necessário, e o execution role cuida de ações da plataforma, como pull de imagem no ECR.

{
  "family": "pedidos-api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/pedidosTaskRole",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789012.dkr.ecr.sa-east-1.amazonaws.com/pedidos:1.12.0",
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "environment": [
        { "name": "AMBIENTE", "value": "producao" }
      ],
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:sa-east-1:123456789012:secret:pedidos/db"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/pedidos-api",
          "awslogs-region": "sa-east-1",
          "awslogs-stream-prefix": "api"
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/healthz || exit 1"],
        "interval": 30,
        "retries": 3
      }
    }
  ]
}

O CloudWatch recebe logs via driver awslogs, métricas de CPU e memória por service e eventos do scheduler. Com Container Insights, o time obtém visão agregada de utilização por cluster, service e task, base para decisões de dimensionamento e de custo. Alarmes e dashboards fecham o ciclo de observabilidade sem instalar agentes customizados.

Service e ciclo de vida de deploy

O service é onde a operação real acontece. Ele mantém o número desejado de tasks, substitui instâncias não saudáveis e orquestra deploys rolantes: sobe tasks novas, aguarda registro no Target Group e probes saudáveis, drena as antigas e reverte automaticamente se o rollout não convergir. Circuit breaker de deploy interrompe lançamentos defeituosos antes de afetar todos os alvos, e a opção de rollback automático devolve a revisão anterior sem intervenção.

# Registra uma nova revisão da task definition e atualiza o serviço
aws ecs register-task-definition --cli-input-json file://pedidos-api.json

aws ecs update-service \
  --cluster producao \
  --service pedidos-api \
  --task-definition pedidos-api \
  --desired-count 6

# Acompanha eventos e saúde das tasks do serviço
aws ecs describe-services --cluster producao --services pedidos-api \
  --query 'services[0].{desejado:desiredCount,rodando:runningCount,eventos:events[0:3]}'

Deploys canário e blue-green ficam viáveis com deploy controllers externos, como CodeDeploy, que alternam Target Groups no ALB. Para o caso padrão, o rolling update com health checks e circuit breaker cobre a maioria das necessidades com configuração mínima.

ECS versus Kubernetes

A comparação entre ECS e Kubernetes é recorrente e merece critérios objetivos, pois a resposta correta depende do contexto do time, não de preferência técnica.

Times pequenos ou médios com infraestrutura toda na AWS frequentemente entregam mais rápido com ECS, gastando o tempo economizado em produto. Times com múltiplas nuvens, exigência de portabilidade ou plataforma interna madura tendem a justificar o Kubernetes. Migrar de um para o outro depois é possível, mas caro; a decisão merece análise séria antes do primeiro serviço de produção.

Erros comuns e boas práticas

Os problemas mais comuns no ECS vêm de configuração de capacidade, limites de IAM e dimensionamento mal calibrado. Conhecê-los acelera o diagnóstico.

• Subdimensionar CPU ou memória da task definition, gerando loops de OOM kill com restarts silenciosos; monitore métricas de memória por service.
• Ignorar o awsvpc e a escassez de IPs na sub-rede, que trava novas tasks em picos de escala; dimensione sub-redes para o máximo de réplicas.
• Conceder task role ampla demais, violando menor privilégio; defina políticas por serviço e audite com IAM Access Analyzer.
• Não configurar deployment circuit breaker, permitindo rollouts defeituosos consumirem o serviço inteiro.
• Misturar ambientes no mesmo cluster sem separação de namespaces e security groups; prefira clusters por ambiente.
• Usar tags mutáveis de imagem e perder rastreabilidade; fixe versões no pipeline e aplique políticas de imutabilidade no ECR.

Boas práticas consolidam a operação. Padronize task definitions por templates gerados no pipeline; trate revisões como código versionado; configure drain de conexões e ordenação correta de readiness; habilite Container Insights desde o primeiro serviço; e revise regularmente a escolha de launch type, pois o lançamento do ECS Managed Instances mudou a fronteira entre Fargate e EC2 autoadministrado, e cenários que antes exigiam contornos agora têm caminho suportado pela própria plataforma.