# Amazon ECS na prática: o que ele resolve que a EC2 sozinha não > Container numa EC2 cai e você refaz tudo à mão. Veja como cluster, service, Auto Scaling Group e load balancer mantêm o container no ar no ECS. - Autor: Henrylle Maia, consultor AWS - Publicado em: 2026-10-15 - Assuntos: Containers - URL: https://pages.formacaoaws.com.br/blog/ecs-na-pratica-cluster-service-asg/ - Aula de origem: "Como funciona o ECS da AWS" (https://www.youtube.com/watch?v=3H4287qhxm0) Rodar um container numa EC2 é fácil. Mantê-lo de pé quando a máquina cai, ou só o container cai, é o problema. Abaixo, o que o Amazon ECS assume nesse trabalho e como cluster, service, Auto Scaling Group e load balancer se encaixam num único desenho. Gravei a aula em fevereiro de 2023, e telas e opções do console mudam com o tempo. O conceito se mantém; para o que está vigente, confira a [documentação oficial do ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html). ## O que o ECS tira das suas costas O ECS é o serviço de orquestração de containers da AWS, totalmente gerenciado. A diferença está aí: você deixa de ser responsável por uma tarefa crítica, que é manter o seu container rodando. Uso como exemplo uma aplicação WordPress, cuja imagem oficial está no Docker Hub, o repositório principal do Docker. Se quiser ver essa aplicação subindo sem ECS, tenho [o WordPress na AWS com Docker](https://pages.formacaoaws.com.br/blog/wordpress-na-aws-com-docker/). ## O caminho convencional: uma EC2 com Docker Quem ainda não conhece o ECS faz o óbvio. Lança uma EC2, uma máquina virtual na AWS, instala o Docker, talvez o Docker Compose, sobe as variáveis de ambiente e manda o container rodar. Libera o acesso, e o usuário chega na aplicação. Agora imagine que a máquina caiu. A saída é lançar outra EC2, subir o container de novo e redirecionar o usuário. Faz isso manualmente toda vez? Há dois problemas juntos: garantir que haja uma máquina disponível e saber se o container está rodando. Se só o container cair, quem percebe? Esse costuma ser o mindset inicial, e é o que o ECS substitui. ## O cluster: máquinas como poder computacional No ECS, você cria um **cluster**, que é uma série de recursos computacionais agrupados. Você diz quantas instâncias EC2 quer dentro dele, por exemplo duas. O mindset que muda o jogo é este: no ECS, as máquinas virtuais são poder computacional. O cluster precisa de instâncias para ter onde rodar as coisas. ## Service, task e task definition Cada peça tem [um post só dela](https://pages.formacaoaws.com.br/blog/ecs-cluster-service-task-definition/). O resumo para seguir: - **Task:** de forma simplista, um container rodando. - **Service:** lança as tasks (você não lança uma sozinha), mantém o número que você pediu e faz a atualização no deploy ou na troca de imagem. - **Task definition:** parente próxima do Docker Compose. Guarda o que o service não sabe da aplicação: imagem, porta, variáveis de ambiente e recursos, como 500 MB de memória. Ao criar o service, você indica a task definition e quantas tasks quer. ![O service, com 2 tasks, mantém as tasks nas duas EC2 do cluster; o Auto Scaling Group mantém as duas EC2](https://pages.formacaoaws.com.br/blog/assets/posts/ecs-na-pratica-cluster-service-asg/cluster-service-asg.svg) ## O service cuida das tasks, o Auto Scaling Group cuida das máquinas Digamos que você pediu uma task. O service trabalha sem parar para ter uma rodando. Se ela morrer, e container foi feito para morrer, o service procura poder computacional no cluster e lança outra. Por isso nada de guardar informação dentro do container: ela vai embora. Se eu mudar para duas tasks, para ter alta disponibilidade (o que mudar na aplicação para isso está em [Docker com alta disponibilidade](https://pages.formacaoaws.com.br/blog/docker-alta-disponibilidade-na-aws/)), ele olha o cluster, vê uma EC2 livre e lança a segunda lá. Isso depende do tamanho: no meu exemplo, o recurso descrito na task definition ocupa uma EC2 inteira, então a segunda task precisa de outra máquina. Quem cuida das máquinas é um serviço em comunicação com o cluster, o **Auto Scaling Group**. Se eu disse que queria duas EC2 no cluster, ele trabalha para manter as duas. O service mantém as tasks, o Auto Scaling Group mantém as instâncias. Para ver como esse grupo se configura, veja [o Auto Scaling Group com launch template](https://pages.formacaoaws.com.br/blog/auto-scaling-group-ec2-launch-template/). Faltou poder computacional para mais containers? Aumente-o no cluster com o Auto Scaling Group. O service continua pedindo "preciso lançar mais task", encontra capacidade e lança. Para a configuração atual, consulte a [documentação de Auto Scaling do cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html). ## O usuário chega pelo load balancer Com duas EC2 e duas tasks, o acesso passa por um **load balancer** na frente. Ele distribui o tráfego. Para saber para onde mandar, há um **Target Group**, que se comunica com o service e conhece as duas tasks disponíveis. Ele também trabalha junto com o service no deploy: enquanto uma task é trocada, o Target Group para de mandar tráfego para ela e envia só para a outra. Terminou, volta a mandar para as duas. A task antiga morre, a nova sobe e só então recebe tráfego. ![No deploy, o Target Group corta o tráfego para a task que está sendo trocada, marcada com X, e manda só para a task da outra EC2; o load balancer fica na frente](https://pages.formacaoaws.com.br/blog/assets/posts/ecs-na-pratica-cluster-service-asg/target-group.svg) No caso do WordPress, talvez você nem faça deploy, porque a imagem é a oficial e, se não for atualizar, não há o que trocar. O deploy faz mais sentido no segundo cenário. Para saber como o load balancer se liga ao service no ECS atual, veja a [documentação de load balancing do service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html). **Fluxo:** Imagem (Docker Hub ou ECR) → Task definition (como é o container) → Service (mantém N tasks) → Cluster (EC2 mantidas pelo Auto Scaling Group) → Load balancer (Target Group) ## Quando a imagem é sua: ECR e rollback No segundo cenário, a aplicação é sua: você baixa o projeto do GitHub, containeriza e só depois sobe para a AWS. Na sua máquina você só consegue gerar a imagem local, então usa o **ECR**, o registro de imagens da AWS, e a imagem passa a ser usada na task definition. Subindo várias imagens com versões diferentes, você pode ter task definitions apontando para versões distintas, a 1, a 2, a 3. Se a 1 está rodando e você faz o deploy da 2 e dá problema, o rollback para a 1 fica facilitado. O cluster, junto com o service, faz a orquestração. O passo a passo disso está em [primeiro container em produção no ECS](https://pages.formacaoaws.com.br/blog/primeiro-container-em-producao-no-ecs/). ## O que ficou de fora Eu mesmo disse na aula que falta muita coisa: Security Group, permissão para o ECR conversar com o cluster e outros pontos. Estranhar tanto termo novo é normal. Quando o cérebro tenta encaixar peças novas de uma vez, dá confusão, e isso faz parte do aprendizado. ## Checklist - Explicar por que uma EC2 com Docker não mantém o container disponível sozinha. - Descrever o cluster como poder computacional composto por instâncias EC2. - Diferenciar task, service e task definition. - Saber quem mantém as tasks (service) e quem mantém as máquinas (Auto Scaling Group). - Explicar o papel do load balancer e do Target Group durante um deploy. - Usar o ECR e versões de imagem para facilitar o rollback. Se você quer montar isso na prática, com cluster, service e load balancer funcionando de ponta a ponta, é o caminho da Formação AWS.