# Bastion host: 3 estratégias para ligar e acessar o porteiro

> Como usar o bastion host no dia a dia da empresa: ligar e desligar com Lambda, ler o IP público na hora de conectar ou fazer start e stop pela CLI.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Segurança, Rede
- URL: https://pages.formacaoaws.com.br/blog/bastion-host-3-estrategias/
- Aula de origem: "Bastion Host: 3 estratégias do campo de batalha para você aplicar na sua empresa" (https://www.youtube.com/watch?v=Los7PjtPMlA)

O porteiro (o bastion host) já funciona e o túnel SSH abre, mas deixá-lo ligado o dia inteiro custa dinheiro. Aqui estão três estratégias para ligar, desligar e conectar nele no dia a dia da empresa, e como escolher a sua, ou combinar duas.

Parto do porteiro já montado. A montagem (security groups, chave `.pem` e túnel) está em [Acesso seguro ao RDS: bastion host e túnel SSH](https://pages.formacaoaws.com.br/blog/acesso-seguro-ao-rds-bastion-host/).

## O cenário: o time acessa o banco pelo porteiro

O desenho é o do porteiro: o usuário chega pela internet ao bastion host (BH), dentro da VPC, e dele alcança o RDS.

![O cenário base: o usuário chega pela internet ao bastion host (BH) e, dele, ao RDS, os dois dentro da VPC](https://pages.formacaoaws.com.br/blog/assets/posts/bastion-host-3-estrategias/cenario-usuario-bastion-rds.svg)

Agora pense no cenário real: na sua empresa, um time acessa o servidor por esse porteiro. Em que horário essa gente acessa? De madrugada, à noite, o tempo todo ou só em horário comercial? No meu exemplo, das 9h às 18h.

A resposta decide a estratégia. Deixar o porteiro ligado o tempo todo pode não fazer sentido, porque envolve custo, e onde há custo vale ter uma estratégia inteligente para reduzi-lo ao máximo.

## Estratégia 1: ligar e desligar o porteiro com Lambda

Se o time trabalha em horário comercial, automatize o ligar e o desligar do porteiro com o AWS Lambda, com uma função agendada (schedule). Dá para criar direto no Lambda ou usar o SAM, e a escolha é gosto do freguês. A EC2 liga e desliga sozinha nos horários que você definiu.

A função precisa das permissões de IAM para ligar e desligar a EC2.

Essa estratégia traz um problema. Quando você para a instância e liga de novo, o IP público dela muda, e o usuário, que precisa desse IP para conectar, passa a ter um endereço diferente a cada dia.

Há dois caminhos para isso:

- **Elastic IP.** Você configura para reassociá-lo ao porteiro sempre que a instância for ligada de novo, e o IP não muda. Em compensação, quando o Elastic IP não está associado a nenhuma EC2 ligada, a AWS cobra uma fração por hora, um valor pequeno. Se custo é problema para você, fique atento a isso.

> **Importante:** isso vale para o que eu expliquei na aula, em 2022, quando a AWS cobrava o Elastic IP só enquanto ele estava sem uso. Desde fevereiro de 2024 a AWS cobra todo IPv4 público, em uso ou não. Os detalhes estão em [IP público cobrado na AWS](https://pages.formacaoaws.com.br/blog/ip-publico-ipv4-cobrado-na-aws/).
- **Não usar Elastic IP e deixar o IP mudar.** Aí o usuário precisa descobrir qual é o IP do porteiro para conectar. É a estratégia 2.

## Estratégia 2: ler o IP público na hora de conectar

Sem Elastic IP, o script que você entrega ao time descobre o IP do porteiro na hora de abrir o túnel. O caminho:

1. Crie um usuário no IAM e dê a ele uma policy com a permissão de *describe instances*, para recuperar informações da EC2.
2. Com o ID da instância do porteiro, o script recupera o IP público dela.
3. O shell script usa esse IP para abrir o túnel SSH.

Mesmo dinâmico, o IP é lido no instante em que o script roda, então o túnel aponta para o endereço certo.

Tem um benefício de segurança: o porteiro passa a ter um IP diferente a cada vez que liga. Se alguém na mesma rede que você conseguir a sua chave `.pem` e o endereço do porteiro, esse endereço muda, e isso é mais um requisito de segurança na sua realidade.

E tem o contra, porque sempre tem: passa a existir um usuário com credenciais de CLI e permissão para listar as informações das instâncias daquela região. Se isso não for problema para você, lembre que a permissão dele é só essa e que é um usuário do seu negócio.

## Estratégia 3: start e stop pela CLI, sem Lambda

A terceira é mais permissiva e não usa Lambda. Não há ligar e desligar por horário: funciona em qualquer horário.

O usuário do IAM, que na estratégia 2 só tinha *describe instances*, ganha também a permissão de dar start e stop na EC2. A rotina do script, via CLI, passa a ser:

1. Ligar a EC2 pela CLI.
2. Esperar a instância ficar disponível.
3. Recuperar o IP público dela.
4. Abrir o túnel SSH com esse IP.

Quando terminar, uma rotina separada para a instância.

![A estratégia 3: o bastion host e o RDS na VPC, a rotina de start e stop da EC2 e o horário das 9h às 18h, que a estratégia 1 automatiza](https://pages.formacaoaws.com.br/blog/assets/posts/bastion-host-3-estrategias/estrategia-3-start-stop-e-horario.svg)

Essa estratégia dá mais trabalho e, dependendo do que você faz, pode nem fazer sentido montar. Para um acesso pontual, pode valer. Para um acesso controlado, com horário e tudo mais, a estratégia 1 combinada com a 2 pode ser a ideal para o seu negócio.

## Qual escolher

**Fluxo:** Lambda (liga o porteiro no horário combinado) → Script (lê o IP público da EC2) → Túnel SSH (abre com o IP do dia) → Amazon RDS (acesso só no horário)

- **Time com horário fixo (estratégias 1 e 2 juntas).** O Lambda liga e desliga o porteiro no horário combinado, e o script lê o IP público a cada conexão. O porteiro não fica ligado fora do expediente, você dispensa o Elastic IP e o endereço muda a cada vez que ele liga.
- **Acesso pontual (estratégia 3).** Sem horário, o script liga o porteiro quando o usuário precisa e uma rotina separada o para quando termina. Dá mais trabalho de montar, em troca de funcionar a qualquer hora.
- **Só a estratégia 1.** Funciona, com a ressalva do IP que muda: ou você usa Elastic IP e aceita o custo, ou passa para a estratégia 2.

Combinar uma ou duas estratégias é escolha sua: você tem o escopo para aplicar ao seu negócio.

## Checklist

- Descubra em que horários o seu time acessa o banco pelo porteiro.
- Se for horário fixo, crie uma função Lambda agendada para ligar e desligar a EC2, com permissão no IAM para isso.
- Decida entre Elastic IP, que tem custo por hora quando não está associado a uma EC2 ligada (e, desde fevereiro de 2024, todo IPv4 público é cobrado), e IP dinâmico.
- Para o IP dinâmico, crie um usuário no IAM com a permissão de *describe instances* e faça o script recuperar o IP público pelo ID da instância.
- Para acesso pontual, acrescente a esse usuário a permissão de start e stop e escreva uma rotina que liga, espera, lê o IP e abre o túnel.
- Tenha uma rotina separada para parar a instância quando o acesso terminar.
- Não deixe o porteiro ligado o tempo todo sem necessidade: isso é custo.

Escolha a estratégia pelo horário do seu time: o porteiro só precisa estar ligado quando alguém vai usá-lo.