ECS: orquestração de containers no ecossistema AWS

O que é ECS e como se compara ao Kubernetes

A alternativa da AWS para orquestração de containers sem a complexidade do K8s

Amazon ECS (Elastic Container Service) é o serviço gerenciado da AWS para orquestrar containers Docker, oferecendo uma alternativa mais simples ao Kubernetes para equipes que já estão no ecossistema AWS. Enquanto Kubernetes é um padrão aberto e portável entre qualquer cloud ou on-premise, ECS é específico da AWS e integra nativamente com IAM, ALB, CloudWatch, Secrets Manager, ECR e outros serviços da plataforma — essa integração reduz drasticamente o overhead operacional para equipes que não precisam de portabilidade. A curva de aprendizado do ECS é consideravelmente menor: conceitos como Task Definition, Service e Cluster são mais simples que os equivalentes Kubernetes (Pod, Deployment, Namespace). Para organizações all-in AWS sem planos de migração para outro cloud, ECS frequentemente é a escolha mais pragmática e econômica.

Task Definitions — definindo como os containers rodam

O equivalente ECS do Dockerfile para definir runtime de containers

Task Definition é o blueprint de uma task no ECS — define qual imagem Docker usar, quanto CPU e memória alocar, variáveis de ambiente, mapeamento de portas, volumes, configuração de logging e o IAM Role que a task deve assumir. Cada revisão de Task Definition é imutável e versionada — task-definition:1, task-definition:2, etc. — permitindo rollback para versões anteriores. Uma Task Definition pode definir múltiplos containers que rodam juntos (equivalente a um Pod no Kubernetes), compartilhando o namespace de rede do host local. Boas práticas incluem usar o Parameter Store ou Secrets Manager para injetar secrets na Task Definition (em vez de hardcodar nas variáveis de ambiente), e sempre especificar resource limits para evitar que uma task consuma todos os recursos do host.

Fargate vs EC2 launch type

Serverless containers versus controle total sobre a infraestrutura

ECS suporta dois launch types: Fargate e EC2. Com Fargate, a AWS gerencia completamente a infraestrutura de servidores — você define CPU e memória na Task Definition e a AWS provisiona o compute automaticamente, sem necessidade de gerenciar instâncias EC2, patching de SO ou capacidade do cluster. Fargate cobra por vCPU e memória por segundo de execução — ideal para workloads variáveis e equipes sem expertise em operação de servidores. Com EC2 launch type, você gerencia instâncias EC2 que formam o cluster ECS — mais complexo operacionalmente, mas mais barato em workloads contínuos de alta utilização e com mais controle sobre o tipo de instância (incluindo GPU, arm64, spot instances). A escolha entre Fargate e EC2 geralmente se resume a: se a simplicidade operacional vale o custo adicional do Fargate para o perfil de workload específico.

ECS Services — manter o número certo de tasks rodando

Alta disponibilidade e rolling deployment automatizados

Um ECS Service garante que um número especificado de tasks esteja sempre rodando — se uma task falha ou é encerrada, o Service automaticamente inicia uma nova para manter a contagem desejada. Services também gerenciam deploys: ao atualizar a Task Definition, o Service executa um rolling deployment — inicia tasks com a nova versão gradualmente enquanto encerra as antigas, sem downtime. O circuit breaker de deployment do ECS para automaticamente um deploy se um percentual configurável de tasks falha ao iniciar, evitando que uma imagem com bug seja implantada em todas as tasks. Para workloads intermitentes (jobs agendados, processamento em batch), o ECS Scheduled Tasks integra com EventBridge para disparar tasks em horários definidos sem manter um Service continuamente rodando.

Service Discovery e comunicação entre services

Como microsserviços ECS se encontram sem hardcodar endereços IP

ECS integra com AWS Cloud Map para service discovery — cada task registra seu IP no Cloud Map quando inicia e remove o registro quando termina. Outros services podem resolver o endereço das tasks pelo nome DNS (meu-servico.namespace.local) sem conhecer IPs que mudam a cada deploy. Para comunicação via HTTP, o App Mesh (implementação do Envoy proxy) adiciona capacidades de service mesh — balanceamento de carga avançado, circuit breaking, retries automáticos, observabilidade de tráfego e TLS mútuo entre serviços. Para comunicação assíncrona, SQS e SNS são alternativas mais simples ao service discovery — um serviço publica em uma fila e o consumidor processa independentemente, eliminando a necessidade de descobrir e conectar a serviços específicos.

Integração com ALB para balanceamento de carga

Roteamento inteligente de tráfego externo para containers ECS

Application Load Balancer (ALB) distribui tráfego externo entre as tasks de um ECS Service, com roteamento baseado em path (/api/users, /api/orders) e hostname (api.exemplo.com, admin.exemplo.com). O ALB integra nativamente com ECS: registra e desregistra tasks automaticamente conforme elas iniciam e terminam, executa health checks nas tasks e remove tasks não saudáveis do balanceamento. Connection draining garante que tasks que estão sendo encerradas recebem tempo para concluir requisições em andamento antes de serem removidas — evitando erros para usuários durante deploys. O ALB também é onde TLS termination acontece — o certificado gerenciado pelo AWS Certificate Manager (ACM) é associado ao listener HTTPS do ALB, e as tasks recebem tráfego HTTP em sua porta interna.

ECR — repositório de imagens na AWS

Registry privado integrado com IAM e scanning de vulnerabilidades

Amazon ECR (Elastic Container Registry) é o registry privado de imagens Docker integrado ao ecossistema AWS. A autenticação usa IAM — não há credenciais separadas para gerenciar, e as permissions granulares do IAM controlam quais usuários e roles podem push e pull de cada repositório. ECR Enhanced Scanning integra com Amazon Inspector para verificar vulnerabilidades conhecidas em cada imagem — o scan pode ser configurado para rodar automaticamente no push e bloquear deploys de imagens com vulnerabilidades críticas via ECR lifecycle policies. Lifecycle policies também automatizam a limpeza de imagens antigas — mantendo apenas as últimas N imagens ou removendo imagens sem tag após X dias, controlando custos de storage. A integração entre ECR e ECS é nativa — a Task Definition referencia a imagem pelo ARN do ECR e as permissões são gerenciadas via o Task Execution Role do IAM.

IAM Roles para ECS — permissões por task

O princípio do menor privilégio aplicado a containers na AWS

ECS usa dois tipos de IAM Role distintos e frequentemente confundidos. O Task Execution Role é assumido pelo ECS agent para operações de infraestrutura — pull de imagens do ECR, envio de logs para CloudWatch, acesso a Secrets Manager para injetar secrets na task. O Task Role é assumido pela aplicação dentro do container para acessar serviços AWS — S3, DynamoDB, SQS, SNS, etc. Separar esses dois roles é crítico: a aplicação não deve ter permissão para pull de imagens ou gerenciar logs, e o ECS agent não deve ter acesso ao S3 ou DynamoDB da aplicação. Cada Task Definition deve ter um Task Role específico com apenas as permissões mínimas necessárias para aquele serviço — um serviço de upload que precisa escrever em S3 tem um role diferente do serviço de notificações que precisa publicar em SNS.

Monitoramento com CloudWatch Logs e Container Insights

Observabilidade nativa para containers ECS sem infraestrutura adicional

ECS integra nativamente com CloudWatch Logs para coleta de logs de containers — o driver awslogs envia stdout e stderr de cada container para um Log Group no CloudWatch automaticamente, sem necessidade de agente de log adicional. CloudWatch Container Insights habilita métricas detalhadas de CPU, memória, network e disk por task, service e cluster — com dashboards automáticos e alertas configuráveis. Cada task tem sua própria dimensão de métricas, permitindo comparar performance entre tasks de um mesmo service e identificar tasks outliers com uso anormal de recursos. Para rastreamento distribuído em microsserviços ECS, o AWS X-Ray SDK integra com a Task Definition para enviar traces de cada requisição, mostrando a latência de cada chamada entre serviços e identificando gargalos na cadeia de dependências.

Conclusão — ECS como caminho pragmático para containers na AWS

Simplicidade operacional com integração nativa ao ecossistema AWS

ECS representa a abordagem pragmática para orquestração de containers em organizações AWS — menos complexidade operacional que Kubernetes, com integração nativa a IAM, ALB, ECR, Secrets Manager e CloudWatch que reduz significativamente o trabalho de colagem entre serviços. Para equipes que já operam na AWS e não têm requisitos de portabilidade multi-cloud, ECS com Fargate elimina a necessidade de gerenciar servidores e oferece deploy de containers com segurança, observabilidade e escalabilidade prontos para produção. Dominar Task Definitions, Services, IAM Roles e a integração com ALB cobre 90% dos casos de uso de containers em produção na AWS. Continue em: Fundamentos obrigatórios antes de produção.