# Ligar e desligar EC2 automaticamente com o AWS CLI

> Um script de shell com AWS CLI que liga a EC2, espera ela ficar pronta e desliga. Usuário no IAM, perfil, start-instances e stop-instances.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos
- URL: https://pages.formacaoaws.com.br/blog/ligar-e-desligar-ec2-automaticamente/
- Aula de origem: "Como ligar e desligar AWS EC2 de forma automatizada" (https://www.youtube.com/watch?v=9tg4ZS_1GHY)

Uma EC2 que só trabalha em alguns horários não precisa ficar ligada o resto do dia: a computação é cobrada por segundo, e parada ela só cobra o armazenamento. Aqui você monta um script de shell com o AWS CLI que liga a instância, espera ela ficar pronta, abre espaço para o seu processo e desliga em seguida, sem clicar em nada no console.

## O cenário: uma instância só, que não precisa ficar ligada o tempo todo

Quando se fala em economizar na nuvem, o primeiro caminho que vem à cabeça é a elasticidade: o Auto Scaling reduz a frota (scale-in) ou aumenta (scale-out) sozinho. Só que isso exige uma aplicação preparada para trabalhar com várias instâncias.

Se a sua aplicação não está nesse ponto e você tem **uma instância EC2** que guarda dados e não pode ser descartada, o que dá para fazer é parar e ligar essa mesma máquina em horários previsíveis: desligar à noite, ou ligar só para executar um determinado processo.

Isso rende porque a EC2 é cobrada por segundo de uso computacional, com mínimo de um minuto. Todo segundo desligada é segundo que você não paga; com a instância parada, sobra só uma cobrança mínima do armazenamento.

![Dois cenários: em cima, a frota do Auto Scaling, com duas instâncias riscadas pelo scale-in; embaixo, a instância única, que só recebe stop ou start](https://pages.formacaoaws.com.br/blog/assets/posts/ligar-e-desligar-ec2-automaticamente/desenho-dois-cenarios.svg)

O exemplo abaixo usa uma instância t2.micro, uma só, e um script em shell. O mesmo caminho serve com o SDK, mas aqui o meio é o AWS CLI.

## Passo 1: ter o AWS CLI funcionando

O script chama o `aws`, então a máquina precisa ter o AWS CLI instalado. Confira no terminal:

```bash
aws --version
```

Ele devolve o AWS CLI e a versão instalada. Se não responder, instale o CLI antes de continuar.

## Passo 2: criar o usuário de automação no IAM

O CLI precisa de permissão na conta para mexer em EC2. No IAM, crie um usuário novo:

1. Dê um nome ao usuário. Na aula é `automacao-ec2`.
2. Marque o **acesso programático**, que é a forma como o CLI vai acessar a conta.
3. Em permissões, **anexe a policy diretamente** ao usuário e procure por `ec2`. Escolha `AmazonEC2FullAccess`.
4. Revise e crie o usuário. A tela seguinte mostra as credenciais (Access Key e Secret Key).

![A criação do usuário no IAM: Attach existing policies directly, filtro ec2 e a policy AmazonEC2FullAccess marcada](https://pages.formacaoaws.com.br/blog/assets/posts/ligar-e-desligar-ec2-automaticamente/iam-policy-ec2fullaccess.webp)

> **Importante:** a policy `AmazonEC2FullAccess` foi escolhida para a aula ser objetiva. Dá para customizar e liberar só o que o script usa. As credenciais dão acesso à conta: não deixe a chave exposta. Na gravação eu mostrei as minhas e avisei que ia apagá-las depois da aula.

> **Importante:** o que este passo faz (usuário IAM com chave de acesso de longo prazo e `AmazonEC2FullAccess`) é o jeito de 2021 e dá mais permissão do que o script precisa. Hoje o recomendado é a permissão mínima: só `ec2:StartInstances` e `ec2:StopInstances`, restritas à ARN dessa instância, mais `ec2:DescribeInstances` se o seu script consultar o estado (essa ação não aceita restrição por recurso e usa `*`). E, se o script rodar dentro da AWS, use uma role no lugar de chave de acesso: as credenciais são temporárias e não há chave para vazar. Veja [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) na documentação do IAM.

## Passo 3: configurar o perfil no CLI

Como eu tenho várias contas na máquina, uso um **profile**, um nome que identifica a conta com a qual o CLI conversa. Se você trabalha com uma conta só, pode não usar profile. Rode:

```bash
aws configure --profile automacaoec2
```

O CLI pergunta quatro valores. Eu respondi assim:

- **AWS Access Key ID:** cole a Access Key do usuário criado.
- **AWS Secret Access Key:** cole a Secret Key.
- **Default region name:** `us-east-1`, a região em que a instância está.
- **Default output format:** `table`, para ver o resultado em formato de tabela.

## Passo 4: parar a instância com um comando

Crie o arquivo do script. Eu chamei de `automacao_ec2.sh`, porque o meu cenário é Linux e o script é de shell. No Windows a extensão seria `.bat`, e o script provavelmente funciona sem alteração, talvez com um ajuste ou outro.

Antes de escrever o comando, pegue o **ID da instância** (o `Instance ID` que aparece na lista de instâncias do console). É a chave que identifica a máquina em toda operação. Coloque numa variável e chame o `stop-instances`:

```bash
instance_id="i-0123456789abcdef0"

aws ec2 stop-instances --instance-ids $instance_id --region us-east-1 --profile automacaoec2
```

Troque o valor de `instance_id` pelo ID da sua instância. Só ele precisa mudar para o script servir no seu projeto. Se você não usa profile, tire o `--profile`.

Execute o arquivo (`./automacao_ec2.sh`). A saída em tabela traz o ID da instância e o estado: `CurrentState` em `stopping`, código 64. No console, a instância já está parando. Com um comando só, parar a instância ficou automatizado.

![A saída do stop-instances em formato table: CurrentState com código 64, stopping (ID da instância borrado)](https://pages.formacaoaws.com.br/blog/assets/posts/ligar-e-desligar-ec2-automaticamente/stop-instances-stopping.webp)

Para ligar, o comando é o `start-instances`, com os mesmos argumentos:

```bash
aws ec2 start-instances --instance-ids $instance_id --region us-east-1 --profile automacaoec2
```

## Passo 5: organizar em funções e esperar a instância subir

Dois comandos soltos não ficam organizados. O passo seguinte é transformar cada um numa função, com um `echo` que diz o que está acontecendo:

```bash
instance_id="i-0123456789abcdef0"

ligar_ec2() {
  aws ec2 start-instances --instance-ids $instance_id --region us-east-1 --profile automacaoec2
  echo "Ligando instancia de id: $instance_id"
}

desligar_ec2() {
  aws ec2 stop-instances --instance-ids $instance_id --region us-east-1 --profile automacaoec2
  echo "Desligando instancia de id: $instance_id"
}
```

Depois, o roteiro que chama as duas, com a espera no meio:

```bash
ligar_ec2
sleep 60
echo 'Instancia ligada'
sleep 60
desligar_ec2
```

O primeiro `sleep 60` é o tempo de boot: 60 segundos é o que eu costumo usar para a instância ficar apta a trabalhar. Se é suficiente para a sua, você confere no console. O `echo 'Instancia ligada'` marca esse ponto.

É entre o `echo` e o `desligar_ec2` que entram os comandos da sua realidade. Na demonstração, esse espaço ficou só com a espera do segundo `sleep 60`.

**Fluxo:** Script (automacao_ec2.sh) → Ligar (start-instances) → Espera (sleep 60) → Seus processos (SSH, backup, build) → Desligar (stop-instances)

## Passo 6: rodar e acompanhar no console

Rode o script com a instância parada. Abri o terminal e o console lado a lado para ver os dois. A saída mostra `Ligando instancia de id: ...` e a instância aparece em `pending`, código 0. No meu caso, ainda durante a primeira espera de 60 segundos ela já estava em `running`.

![O roteiro do script (ligar_ec2, sleep 60, echo, sleep 60, desligar_ec2) e, no terminal, a saída do start-instances com CurrentState 0, pending](https://pages.formacaoaws.com.br/blog/assets/posts/ligar-e-desligar-ec2-automaticamente/roteiro-e-pending.webp)

Depois vem a mensagem `Instancia ligada`, a segunda espera e, no fim, `Desligando instancia de id: ...`, que é o comando de parar a instância.

## Onde colocar o seu processo

O trecho depois da instância ligada é onde entra o que você precisa executar, e aí o limite é a sua criatividade. Exemplos que citei na aula:

- Conectar por SSH e mandar processos para serem executados na instância.
- Recuperar o IP da instância depois de ligada. O IP é dinâmico, então é preciso buscar a cada vez.
- Copiar arquivos para dentro dela.
- Fazer o vínculo com o Route 53 de um site que você quer colocar no ar dinamicamente.

No meu dia a dia uso esse tipo de script em processo de CI: o script liga a máquina quando precisa, faz o backup ou o restore, executa o que for do CI/CD e desliga o recurso. Há recursos da AWS que só se alcança de dentro da VPC, e uma instância que só fica ligada durante o build resolve isso.

Rodando na sua máquina, o script depende dela. Para rodar na AWS, os caminhos que citei foram um agendamento com o CloudWatch, a integração com Lambda ou com Fargate.

## Checklist

- Confirme que existe uma instância única que não precisa ficar ligada o tempo todo.
- Rode `aws --version` e confirme que o CLI está instalado.
- Crie um usuário no IAM com acesso programático e uma policy do EC2 (na aula é a `AmazonEC2FullAccess`; prefira a permissão mínima do aviso acima).
- Rode `aws configure --profile <nome>` com região e formato de saída.
- Guarde o ID da instância na variável `instance_id` do script.
- Teste `stop-instances` e `start-instances` e veja o estado no console.
- Separe `ligar_ec2` e `desligar_ec2` em funções e deixe um `sleep 60` entre ligar e o seu processo.
- Apague a chave de acesso do usuário quando não precisar mais dela.

Uma instância que só precisa existir durante um processo não precisa ficar ligada o resto do tempo, e é nessa diferença que a conta cai.