# Levar a aplicação para a AWS é seguro? Como proteger o banco

> O que muda na segurança ao sair do on-premise: VPC, security group, o erro de abrir a porta do banco para os devs e como o bastion host resolve.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Segurança, Migração
- URL: https://pages.formacaoaws.com.br/blog/e-seguro-levar-a-aplicacao-para-a-aws/
- Aula de origem: "Será se é seguro levar a app para a AWS?" (https://www.youtube.com/watch?v=zGiFf-bBhTc)

Levar a aplicação para a AWS é seguro quando só a aplicação web fica exposta e o banco aceita apenas a aplicação. O erro que desfaz isso é liberar a porta do banco para as máquinas dos devs, e dá para evitar com VPC, Security Group e bastion host.

"Minha aplicação e meu banco vão estar seguros na nuvem?" foi uma das respostas que mais apareceram quando perguntei, nas pesquisas dos meus eventos, o que impede as pessoas de começar com a AWS. Uso um cenário simples: aplicação web e banco de dados.

## O ponto de partida: o que você já faz no on-premise

Imagine a sua estrutura local com uma aplicação web e um banco. Pela configuração de rede, dá para deixar só a parte web acessível para o usuário. A aplicação conversa com o banco, e o banco não fica acessível da internet: não há como falar com ele direto.

Na mesma rede, porém, estão as máquinas dos devs. Elas têm acesso à internet e, dependendo da configuração, ao banco. Sem pipeline nem automação de deploy, é normal o dev se conectar nele para rodar uma migration ou uma atualização.

![No on-premise: banco (BD), aplicação web e os devs na mesma rede; os devs saem para a internet e acessam o banco, e o usuário acessa a web](https://pages.formacaoaws.com.br/blog/assets/posts/e-seguro-levar-a-aplicacao-para-a-aws/onprem-dev-no-banco.svg)

Esse é o cenário de quem está pensando em migrar. A pergunta é como isso fica na AWS.

## Como a AWS organiza a rede

Em cada região da AWS você tem zonas de disponibilidade: conjuntos de servidores isolados por energia, com distância mínima de 15 km entre eles. No desenho da aula usei a região da Virgínia com duas zonas, AZ1 e AZ2.

Em cada região você ganha uma **VPC**, a rede que você tem na nuvem naquela região. Por padrão, essa rede está acessível para a internet, e cada recurso você pode fechar ou não. Dois itens bastam para quem está começando: o **Internet Gateway** e o **Security Group**.

## Passo 1: deixe só a aplicação web aberta

Para a máquina da aplicação web ser acessível, a VPC precisa do Internet Gateway, mas só ele não basta. Você também associa à máquina um Security Group.

1. Confirme que a VPC tem o Internet Gateway.
2. No Security Group da aplicação web, libere as portas 80 e 443 para o mundo.

![A VPC em us-east-1 com o Internet Gateway: a aplicação web e o security group na AZ-1, e a AZ-2 ainda vazia](https://pages.formacaoaws.com.br/blog/assets/posts/e-seguro-levar-a-aplicacao-para-a-aws/vpc-internet-gateway.svg)

Com isso o usuário consegue acessar a aplicação.

## Passo 2: deixe o banco falar só com a aplicação

Coloque o banco, por exemplo, na outra zona (AZ2), com o seu próprio Security Group. Do mesmo jeito que você faz localmente, libere a comunicação da aplicação web com o banco: o Security Group do banco aceita o Security Group da aplicação na porta do banco, que no exemplo é a 5432.

![O banco na AZ-2 com o próprio security group: a web libera 80 e 443, o banco só a 5432, e a web fala com o banco](https://pages.formacaoaws.com.br/blog/assets/posts/e-seguro-levar-a-aplicacao-para-a-aws/vpc-security-group.svg)

Até aqui está certo. O erro vem do próximo pedido.

## O erro que transporta o problema para a nuvem

Os devs precisam rodar uma migration ou uma manutenção no banco, e você ainda não tem pipeline de CI/CD. O que muita gente faz: vai no Security Group do banco e libera a 5432 também para o dev 1 e o dev 2.

Quando você faz isso, abre uma brecha enorme. Uma máquina sobre a qual você não tem controle passa a poder falar com o seu banco, e ela só precisa de endpoint, usuário e senha. Se essa máquina guarda as credenciais, quem estiver monitorando ou interceptando a rede consegue pegá-las e se conectar.

Esse problema também existe no on-premise. Se você fizer assim, só transportou para a nuvem um problema que já tinha. Nos dois casos é inseguro, e é essa configuração que responde "não" à pergunta do título.

## Passo 3: tire o banco da internet e use um bastion host

O banco não precisa de acesso à internet: só a aplicação web precisa chegar nele. Com acesso à internet, ele permite justamente a configuração do erro acima, que é um desastre para o negócio.

E os devs, que continuam precisando do banco? Entra o **bastion host**: o dev não fala direto com o banco, e o bastion host faz a ponte. Você constrói um túnel SSH, e ele encaminha o tráfego do banco para a máquina do dev.

![O bastion host ao lado do banco: os devs entram por túnel SSH no bastion, e o acesso direto ao banco fica marcado com X](https://pages.formacaoaws.com.br/blog/assets/posts/e-seguro-levar-a-aplicacao-para-a-aws/bastion-host.svg)

Quem não tem a chave do cofre não se comunica com o banco, e a chave do cofre não é o login nem a senha. Assim você controla todo o acesso.

Dá ainda para ligar o bastion host só na janela de trabalho dos devs. Se eles trabalham das 8h às 18h, uma automação com Lambda deixa o bastion host ligado só nesse horário. Fora dele, ele está desligado, e ninguém fala com o banco, exceto a aplicação. Para montar o bastion host e o túnel, veja [Acesso seguro ao RDS: bastion host e túnel SSH](https://pages.formacaoaws.com.br/blog/acesso-seguro-ao-rds-bastion-host/) e, para o horário, [Ligar e desligar EC2 automaticamente](https://pages.formacaoaws.com.br/blog/ligar-e-desligar-ec2-automaticamente/).

**Fluxo:** Dev (precisa acessar o banco) → Bastion host (ponte com túnel SSH) → Banco (sem acesso à internet, porta 5432)

## O que entender antes de migrar

Para saber se é seguro, entenda VPC, Security Group e Internet Gateway. Existem outros itens ligados a eles, como subnet pública e privada, que eu não explorei na aula. Com esse conhecimento, você entende a comunicação e sabe que dá para colocar uma aplicação na internet de forma segura.

Este texto cobre o raciocínio de rede. Outros erros que causam acidente em conta AWS, como SSH aberto, Access Key no servidor e conta sem MFA, estão em [Segurança na AWS: 6 erros que podem quebrar seu negócio](https://pages.formacaoaws.com.br/blog/seguranca-na-aws-6-erros/).

## Checklist

- A VPC tem o Internet Gateway e a aplicação web tem um Security Group com as portas 80 e 443.
- O banco tem o seu Security Group, que aceita só o Security Group da aplicação na porta do banco.
- Nenhuma regra libera a porta do banco para a máquina de dev.
- O banco não tem acesso à internet.
- O acesso dos devs ao banco passa por um bastion host, com túnel SSH.
- O bastion host fica ligado só no horário em que os devs trabalham.

Se você quer ver a sua aplicação indo para a AWS com esse desenho e não sabe por onde começar, agende uma conversa.