AWS ECS (Elastic Container Service)

O Amazon ECS é o serviço de orquestração de contêineres nativo da AWS, usado para agendar e executar contêineres Docker em clusters gerenciados sem administrar um control plane de Kubernetes. A escala de operação sustenta a confiança em produção: a AWS processa cerca de 3 bilhões de tasks ECS por semana, distribuídas entre contas de clientes de todos os portes, o que significa que o scheduler, as integrações e os modos de falha do serviço são exaustivamente exercitados diariamente. O modelo mental é simples e fechado: você descreve contêineres em uma task definition, declara réplicas e balanceamento em um service e escolhe a capacidade em um cluster, com integração nativa de IAM, ALB, autoscaling e CloudWatch. Em 2025, o lançamento do ECS Managed Instances adicionou uma terceira forma de capacidade, combinando a simplicidade operacional do Fargate com o controle de instâncias EC2 para cargas com GPU, privileged containers e memória acima do teto de 120 GB do Fargate. Para times AWS-first, o ECS costuma entregar orquestração de produção com custo e complexidade menores que Kubernetes.

Conceito e modelo de objetos

O ECS organiza a operação em três objetos centrais, e entender a fronteira entre eles elimina a maior parte da confusão inicial. O cluster agrupa capacidade de computação, seja de instâncias EC2, Fargate ou Managed Instances. A task definition é o documento declarativo que descreve a aplicação: imagem, CPU, memória, variáveis, segredos, portas, logs e health check. A task é uma instância em execução dessa definição, e o service mantém o número desejado de tasks saudáveis, substitui falhas e orquestra deploys rolantes.

A task definition é versionada por revision, e o deploy de produção é, na prática, a publicação de uma nova revision seguida da atualização do service para essa revision. Esse fluxo é fácil de automatizar em pipeline e de reverter, pois a revisão anterior permanece registrada e disponível.

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

Launch types: EC2, Fargate e Managed Instances

A escolha da capacidade é a decisão arquitetural central do ECS, porque define operação, custo e limites técnicos ao mesmo tempo. Os três modos compartilham a mesma API de tasks e services, o que torna a migração entre eles viável sem reescrever a aplicação.

O Fargate elimina patching de SO, dimensionamento de ASG e planejamento de bin packing, cobrando por vCPU e GB de memória por segundo, com prêmio de preço em relação a instâncias reservadas. O modo EC2 reduz custo unitário em escala constante e permite qualquer recurso do host, ao preço de administrar AMI, agente ECS e escala do grupo. O Managed Instances fecha essa lacuna em 2025: o time continua definindo tasks e services da mesma forma, mas a AWS provisiona e administra instâncias EC2 escolhidas para o caso, incluindo GPU, containers privileged e memória além de 120 GB, sem expor a complexidade de operar um cluster.

Integração com ALB, IAM e autoscaling

A integração com o restante da plataforma é o diferencial prático do ECS em produção. Um service associado a um Target Group registra cada task no ALB automaticamente, respeitando portas dinâmicas com awsvpc e suportando roteamento por host e path em múltiplos services no mesmo domínio. O IAM substitui credenciais embutidas: a task role concede permissões granulares à aplicação, e a execution role cobre ações da plataforma, como pull de imagem do ECR e leitura de segredos do Secrets Manager.

O autoscaling do service ajusta o número desejado de tasks com políticas de target tracking, tipicamente sobre utilização de CPU, número de requisições por target do ALB ou métricas customizadas no CloudWatch. A escala de capacidade, quando o launch type é EC2, fica a cargo do capacity provider, que aciona o ASG subjacente conforme a demanda de tasks.

# Atualiza o service para a nova revision com contagem desejada
aws ecs update-service \
  --cluster producao \
  --service pedidos-api \
  --task-definition pedidos-api:47 \
  --desired-count 8

# Política de escala: mantém a média de CPU do service em 60%
aws application-autoscaling register-scalable-target \
  --service-namespace ecs --resource-id service/producao/pedidos-api \
  --scalable-dimension ecs:service:DesiredCount --min-capacity 4 --max-capacity 40

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs --resource-id service/producao/pedidos-api \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-target-60 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ECSServiceAverageCPUUtilization"}
  }'

Fargate versus EC2 por custo e controle

A comparação de custo é matemática de perfil de carga, e não preferência. Fargate cobra por segundo com preço unitário maior que instância equivalente; em cargas estáveis e previsíveis, EC2 com Savings Plans ou instâncias Spot sai significativamente mais barato por vCPU hora. Em cargas variáveis, o preço de ociosidade desaparece no Fargate, e o custo total frequentemente empata com a economia teórica do EC2 mal utilizada.

Controle segue a mesma lógica de trade-off. Fargate restringe: sem privileged, sem host network, teto de 120 GB de memória por task, e customizações de kernel fora de alcance. EC2 libera tudo, mas transfere a responsabilidade de AMI, patching e capacidade. O Managed Instances entra como resposta 2025 para o caso específico de precisar de controle de host sem querer operar o cluster, e times com requisitos de GPU ou memória alta têm nele o caminho suportado que antes exigia EC2 autoadministrado ou contornos criativos.

Deploy, ciclo de vida e segurança de operação

O service executa deploys rolantes por padrão: publica tasks novas da revision, aguarda registro saudável no Target Group, drena as antigas e reverte automaticamente se o rollout não convergir quando o deployment circuit breaker está habilitado. Para padrões canário e blue-green mais sofisticados, o deploy controller do CodeDeploy alterna Target Groups no ALB, mantendo o ECS como executor.

A segurança de operação combina menor privilégio por task role, imagens assinadas e imutabilidade de tags no ECR, secrets via Secrets Manager ou Parameter Store e logs centralizados no CloudWatch com retenção definida. Container Insights fecha o ciclo de observabilidade com métricas agregadas por cluster, service e task, base para calibrar dimensionamento e custo.

ECS versus EKS

A decisão prática favorece ECS para times pequenos e médios AWS-first que querem foco em produto, e EKS para estratégias multi-cloud, plataformas internas maduras ou necessidades de extensibilidade específicas. Ambos rodam as mesmas imagens e podem compartilhar ECR, ALB e observabilidade, o que mantém o custo de mudança calculável.

Erros comuns e boas práticas

• Subdimensionar CPU ou memória na task definition, gerando loops de OOM kill com restarts silenciosos; monitore memória por service e calibre com dados reais.
• Ignorar a escassez de IPs da sub-rede com awsvpc, que trava novas tasks durante picos de escala; dimensione CIDR para o máximo de réplicas previsto.
• Conceder task role ampla demais, violando menor privilégio; defina policies por serviço e audite com IAM Access Analyzer.
• Desabilitar o deployment circuit breaker e permitir rollouts defeituosos consumirem todas as tasks do serviço.
• Misturar ambientes no mesmo cluster; prefira clusters por ambiente com security groups e IAM distintos.
• Usar tags mutáveis de imagem e perder rastreabilidade de versão; fixe digests no pipeline e aplique imutabilidade no ECR.
• Combinar Fargate em cargas estáveis de 24x7 sem revisar custo; onde a demanda é constante, avalie EC2 com Savings Plans ou Managed Instances.

Como prática consolidada, trate task definitions como código versionado gerado por templates no pipeline, habilite Container Insights e alarmes de memória desde o primeiro serviço, e revise a escolha de launch type por workload periodicamente, pois o lançamento do ECS Managed Instances em 2025 mudou a fronteira entre Fargate e EC2 autoadministrado e tornou viáveis cenários que antes exigiam contornos.