# Segurança na comunicação entre serviços na AWS: 4 níveis

> Os 4 cenários para ligar a aplicação ao banco na AWS, do IP público ao bastion host com SSM e IAM, e qual deles evitar ou buscar.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Segurança, Rede
- URL: https://pages.formacaoaws.com.br/blog/seguranca-na-comunicacao-entre-servicos-aws/
- Aula de origem: "Níveis de segurança na comunicação entre os serviços na AWS" (https://www.youtube.com/watch?v=wepz71y3M6I)

Quem leva a aplicação para a nuvem costuma começar com dois servidores de IP público e o banco liberado por IP, e cada decisão seguinte herda esse erro. Aqui estão os 4 cenários pelos quais a ligação entre aplicação e banco passa na AWS, do pior ao melhor: descubra em qual você está e qual é o próximo passo.

## Do localhost para a nuvem: onde o erro começa

Na máquina local, a aplicação web fala com o banco por localhost, e esse acesso é permitido por padrão. Você não precisa pensar em liberação nenhuma.

Na nuvem, o hábito é repetir esse desenho: o banco num servidor, a aplicação web em outro, e a comunicação liberada entre eles. O que muda é que agora existe uma rede no meio. Na AWS ela se chama VPC; no Azure, VNet. Como você usa essa rede define o seu nível de segurança.

## Cenário 1: IP público no banco e na aplicação

Os dois servidores têm IP público. No banco, você libera o IP público da aplicação web para ela se comunicar. E, como você também precisa acessar o banco de casa, libera o seu IP público ali também.

![Cenário 1: o usuário chega à aplicação web e ao banco, a aplicação também chega ao banco, e a aplicação e o banco têm cada um seu IP público](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-comunicacao-entre-servicos-aws/cenario-1-ip-publico.svg)

O resultado é uma brecha de segurança enorme: o banco, que não deveria ficar acessível publicamente, está exposto. Muita gente chega aqui sem saber, porque só precisava de dois servidores e depois configurou a comunicação entre eles.

> **Importante:** esse cenário você precisa evitar. Liberar IP público no banco é o erro: o banco não é para ficar acessível publicamente.

## Cenário 2: dentro da VPC, com security group e o seu IP público

O segundo passo é colocar os recursos dentro de uma rede. A VPC é a representação da sua rede na AWS, numa região, e as subnets definem em qual zona de disponibilidade cada recurso roda. Na AWS, todo recurso que você lança já fica dentro de uma VPC, queira você ou não. Para ver como a rede se organiza, veja [Levar a aplicação para a AWS é seguro?](https://pages.formacaoaws.com.br/blog/e-seguro-levar-a-aplicacao-para-a-aws/).

Dentro da VPC, você libera o banco para a aplicação pelo **security group**, não por IP:

1. A aplicação web tem um security group.
2. No banco, você cria uma regra de entrada que libera esse security group, na porta do banco (por exemplo, a do PostgreSQL).

Liberar por IP privado não funciona: se a aplicação morrer e você subir outra máquina, vai acumulando IP na regra, e a aplicação deixa de escalar. Com o security group, toda máquina nova que nascer com o mesmo security group já fala com o banco.

![Cenário 2: dentro da VPC, a aplicação web e o banco ligados por um security group, com o IP público ainda anotado em cada um](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-comunicacao-entre-servicos-aws/cenario-2-security-group.svg)

Só que você também precisa acessar o banco de fora. Neste cenário, o que costuma acontecer é deixar o banco público e criar uma regra de entrada para o seu IP.

O problema: numa rede corporativa, as pessoas provavelmente saem pelo mesmo IP, então quem estiver naquela rede também acessa o banco. É um problema gravíssimo, e muita gente só se dá conta dele quando acontece algo mais sério.

**Fluxo:** Cenário 1 (IP público nos dois servidores) → Cenário 2 (VPC e security group) → Cenário 3 (bastion host com SSH) → Cenário 4 (bastion host com SSM e IAM)

## Cenário 3: bastion host com SSH

Aqui tudo fica dentro da rede. A aplicação web mantém o IP público, e o **banco não precisa mais de IP público**. A comunicação entre os dois continua por security group.

Entra o **bastion host**, que eu chamo de porteiro. Você acessa o bastion com uma chave SSH, pelo IP público dele. Do bastion até o banco, a comunicação é por security group. Com o bastion, você monta um **túnel SSH**: a porta do banco é redirecionada para a sua máquina, e você acessa o banco localmente.

![Cenário 3: o usuário chega ao bastion host com SSH pelo IP público dele, do bastion sai o security group até o banco, e o IP público do banco está riscado](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-comunicacao-entre-servicos-aws/cenario-3-bastion-ssh.svg)

Este cenário é muito melhor que os anteriores, e o porteiro tem uma vantagem: você controla o horário em que ele fica ligado. Ligue às 8 e desligue às 18, por exemplo, com uma automação em Lambda. Também dá para liberar só a faixa de IP dos seus desenvolvedores, que ainda precisam ter a chave SSH.

Mas ainda dá trabalho:

- Você continua gerenciando o IP público dos devs e do time de infra, para eles chegarem ao porteiro.
- Você precisa compartilhar a chave SSH. Se um dev sai da equipe, ele leva a chave: você vai trocar a chave do bastion toda vez que alguém sair?

O erro de liberar a porta do banco para as máquinas dos devs, e como o bastion resolve, está em [Levar a aplicação para a AWS é seguro?](https://pages.formacaoaws.com.br/blog/e-seguro-levar-a-aplicacao-para-a-aws/). Para montar o cenário na prática, veja [Acesso seguro ao RDS com bastion host e túnel SSH](https://pages.formacaoaws.com.br/blog/acesso-seguro-ao-rds-bastion-host/); para ligar e desligar o porteiro, [Bastion host: 3 estratégias](https://pages.formacaoaws.com.br/blog/bastion-host-3-estrategias/).

## Cenário 4: bastion host com SSM e IAM

No quarto nível, o SSH sai de cena. O bastion passa a trabalhar com o **SSM**, o Session Manager, que é um serviço da AWS. Para ver o Session Manager abrindo uma sessão numa EC2, veja [Conectar na EC2 pelo navegador, sem chave PEM e sem abrir SSH](https://pages.formacaoaws.com.br/blog/conectar-na-ec2-pelo-navegador/).

Para o usuário se comunicar com o bastion:

- você não precisa mais liberar IP público no security group;
- você não precisa mais compartilhar chave SSH;
- a segurança passa a ser no nível do **IAM**: o usuário acessa com o IAM.

O resto do fluxo continua igual. O banco não tem IP público, e o bastion até pode ter um, mas **sem nenhuma regra de entrada**.

![Cenário 4: o usuário entra com IAM no bastion host (SSM); o IP público liberado, o SSH e o IP público do banco aparecem riscados](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-comunicacao-entre-servicos-aws/cenario-4-bastion-ssm.svg)

Resultado: você não gerencia mais o IP público dos seus devs nem a chave SSH. É um nível de excelência em segurança bem maior.

## Em qual cenário você deve estar

Minha regra é direta:

- **Cenários 1 e 2:** não recomendo de forma alguma. Descartados.
- **Cenário 3:** o mínimo. Se você está nos anteriores, lute para chegar pelo menos nele.
- **Cenário 4:** o ideal.

Se você está começando na AWS, já conheça os quatro. O problema aparece quando a pessoa lança uma EC2 e um RDS, diz "preciso que o meu cenário funcione lá" e faz as coisas sem saber como estão funcionando.

## Checklist

- Descubra em qual dos 4 cenários a sua aplicação está hoje.
- Confira se o seu banco tem IP público e se alguma regra de entrada libera IP.
- Se tiver, tire o IP público do banco e libere só o security group da aplicação, não o IP dela.
- Verifique se a sua rede corporativa sai por um IP único liberado no banco.
- Coloque um bastion host (o porteiro) entre você e o banco.
- Programe o horário de ligar e desligar o bastion.
- Troque o acesso por SSH pelo SSM com IAM, para não compartilhar chave nem gerenciar IP dos devs.

Se o seu banco ainda está num dos dois primeiros cenários, esse é o primeiro ajuste: dentro da VPC, com security group e com o acesso externo passando por um bastion host.