# Auto Scaling Group na AWS: lance EC2 com Docker e pague só pelo uso

> Crie um Launch Template e um Auto Scaling Group que lançam quatro EC2 prontas com Docker em duas zonas, com acesso por SSM.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos
- URL: https://pages.formacaoaws.com.br/blog/auto-scaling-group-ec2-launch-template/
- Aula de origem: "COMO ESCALAR AUTOMATICAMENTE SEUS PROJETOS NA NUVEM DA AWS PAGANDO APENAS PELO USO" (https://www.youtube.com/watch?v=FlzZP2K20GU)

No fim deste texto você vai saber montar um Auto Scaling Group que lança várias EC2 sozinho, já com Docker instalado, distribuídas em duas zonas de disponibilidade. E vai saber ajustar a quantidade de máquinas quando precisar, até zerar, para pagar só pelo poder computacional que está ligado.

## O que o Auto Scaling Group resolve

Muita gente aprende a lançar uma EC2 num tutorial e para aí. Fica a dúvida de como isso funciona em produção. A escala automática é uma das respostas: você diz quantas máquinas quer, e a AWS lança, distribui e mantém essas máquinas para você.

O Auto Scaling Group não tem custo próprio. Você paga pelo poder computacional que ele lança, por segundo de uso. Se aumenta ou diminui a quantidade de instâncias, a cobrança acompanha.

O desenho do laboratório é este: uma região, a VPC padrão da conta, duas zonas de disponibilidade (A e B) e quatro máquinas distribuídas entre elas. Duas zonas ajudam a manter a aplicação disponível se uma delas tiver problema.

Para a máquina já nascer pronta, o grupo se apoia num **Launch Template**. Ele guarda o modelo da instância: a role, o security group e o script de preparação.

> **Importante:** parto do princípio de que você já sabe criar security group e role de IAM. Esses dois itens precisam existir antes de começar.

## Passo 1: conferir os pré-requisitos

Eu preciso de duas peças prontas antes do Launch Template.

1. **Uma role para acesso por SSM.** A minha se chama `role-acesso-ssm` e tem a policy `AmazonSSMManagedInstanceCore`. É por ela que eu entro na máquina depois, sem SSH. O SSM é mais seguro que o SSH, e o acesso não depende de porta aberta.
2. **Um security group.** O meu se chama `bia-dev` e tem uma regra de entrada liberando HTTP na porta 80. Ela é opcional: como a conexão é por SSM, não preciso dela, e você pode deixar o grupo sem porta aberta. Se a sua aplicação precisar de porta, libere o que fizer sentido para ela.

No console do IAM, abra a role e confirme a policy. No console do EC2, abra os security groups e confirme o grupo.

## Passo 2: preparar o script de user data

O user data é um script de shell que roda quando a instância liga. Aqui ele deixa a máquina pronta para trabalhar com containers. O script que eu uso instala:

- Docker e Git, e coloca os usuários `ec2-user` e `ssm-user` no grupo `docker`;
- ativa e inicia o serviço do Docker;
- Docker Compose, como plugin (v2.23.3 no script);
- uma configuração de swap;
- Node e npm.

![O início do script user_data_ec2_zona_a.sh no GitHub: instala Git e Docker, adiciona ec2-user e ssm-user ao grupo docker, ativa o serviço e baixa o Docker Compose v2.23.3](https://pages.formacaoaws.com.br/blog/assets/posts/auto-scaling-group-ec2-launch-template/user-data-script.webp)

Ele está no repositório do projeto Bia, no meu GitHub. Copie o conteúdo do script, porque você vai colá-lo no Launch Template. Se a sua realidade pede outras ferramentas, ajuste o script. O importante é o grupo lançar todas as máquinas já preparadas.

## Passo 3: criar o Launch Template

No console do EC2, abra **Launch Templates** e crie um novo. Eu usei um nome de aula, com versão 1. Os campos que preenchi:

- **Resource tags:** nenhuma. Eu queria nomear as instâncias, mas o nome só entrou depois, no grupo.
- **Imagem:** Amazon Linux 2023.
- **Tipo da instância:** deixei em branco, para escolher na tela do grupo.
- **Key pair:** nenhum, porque não uso chave.
- **Security group:** o `bia-dev`.
- **Storage:** o padrão.
- **Advanced details, IAM instance profile:** `role-acesso-ssm`.
- **User data:** o script do passo anterior, colado no final da página.

Clique em **Create launch template**.

> **Importante:** a primeira instância nasceu sem nome, e eu a renomeei no console. Para as seguintes, coloquei a tag `Name` no grupo (Passo 5).

## Passo 4: criar o Auto Scaling Group

No console do EC2, abra **Auto Scaling Groups** e crie um grupo. O fluxo:

1. Dê um nome ao grupo e escolha o Launch Template. A versão pode ser a última.
2. No tipo de instância, tire as opções extras e deixe só a `t3.micro`, que entra no Free Tier da conta.
3. Em rede, escolha a VPC e marque duas zonas. Na minha conta, na região `us-east-1`, foram a `us-east-1a` e a `us-east-1b`.

![Availability Zones and subnets do Auto Scaling Group com us-east-1a e us-east-1b selecionadas na VPC padrão](https://pages.formacaoaws.com.br/blog/assets/posts/auto-scaling-group-ec2-launch-template/zonas-a-e-b.webp)
4. Pule para a revisão com **Skip to review**. As etapas do meio têm valores padrão que não precisei mexer.
5. Clique em **Create Auto Scaling group**.

Por padrão, o grupo nasce com uma instância. Na aba **Activity** você acompanha o lançamento, e na lista de instâncias a máquina aparece.

**Fluxo:** Launch template (role, security group e user data) → Auto Scaling group (capacidade desejada 4) → Zonas A e B (instâncias distribuídas) → EC2 com Docker (acesso por SSM)

## Passo 5: ajustar a capacidade para quatro

Quatro máquinas foi o escopo que eu me propus. Abra o grupo, clique em **Edit** e ajuste a capacidade: mínima, desejada e máxima em 4.

> **Importante:** o valor desejado não pode passar do máximo. Eu cheguei a colocar a capacidade errada e tive que corrigir antes de salvar.

Na mesma tela, em **Tags**, adicione a tag `Name`. Clique em **Update**.

O grupo atualiza a capacidade e lança as três instâncias que faltam, já com a tag. A que existia antes não é renomeada: o grupo só lança as novas. Filtre a lista de instâncias pelo nome e pelo estado `running` e você vê as quatro distribuídas entre a zona A e a zona B, sem precisar escolher nada.

![Lista de instâncias filtrada por aula-youtube e running: quatro t3.micro em Running, duas em us-east-1a e duas em us-east-1b](https://pages.formacaoaws.com.br/blog/assets/posts/auto-scaling-group-ec2-launch-template/instancias-por-zona.webp)

## Passo 6: conectar e conferir a preparação

Agora vem a prova de que o user data funcionou. Selecione uma das instâncias, clique em **Connect** e entre pela sessão do SSM. Como a role está associada, a conexão abre sem chave e sem depender de porta aberta.

Troque para o usuário `ec2-user` (`sudo su ec2-user`) e rode:

```bash
docker --version
```

Em seguida, o Compose:

```bash
docker compose version
```

Os dois responderam: Docker 25.0.3 e Docker Compose v2.23.3. Clonei o repositório do projeto Bia (`git clone https://github.com/henrylle/bia`), entrei na pasta `bia` e rodei `docker compose up -d`. Ele começou a baixar as imagens como eu precisava.

![Terminal do SSM como ec2-user: docker --version responde 25.0.3, docker compose version responde v2.23.3 e o git clone do projeto bia começa](https://pages.formacaoaws.com.br/blog/assets/posts/auto-scaling-group-ec2-launch-template/docker-no-ssm.webp) Isso vale para as quatro máquinas, porque todas nasceram do mesmo template.

## Passo 7: reduzir ou zerar para não pagar à toa

A capacidade do grupo não é fixa. Para reduzir, volte em **Edit** e mude os valores. Por exemplo, mínimo 2 e máximo 4: o grupo passa a trabalhar com duas máquinas e desliga as outras.

Quando terminar o laboratório, você pode zerar a capacidade. Sem instâncias, não há cobrança do que o grupo lança, porque o Auto Scaling Group em si não é cobrado.

Neste laboratório eu ajustei tudo na mão. O grupo também aceita gatilhos para aumentar ou diminuir a quantidade de máquinas sozinho, mas isso fica para outro texto.

## Checklist

- Crie ou confira a role com a policy `AmazonSSMManagedInstanceCore`.
- Crie ou confira o security group que a instância vai usar.
- Copie o script de user data que prepara Docker, Docker Compose, Git e Node.
- Crie o Launch Template com a role, o security group e o user data.
- Crie o Auto Scaling Group com o template, o tipo `t3.micro` e as zonas A e B.
- Ajuste mínima, desejada e máxima para o número de máquinas que você quer.
- Conecte pelo SSM e rode `docker --version` para provar que o user data funcionou.
- Reduza ou zere a capacidade ao terminar, para não pagar por máquina ligada.

O Auto Scaling Group lança, distribui e mantém as máquinas por você, e a conta acompanha só o que está ligado. O Launch Template é a peça que garante que cada uma nasce pronta.