# VPC Peering: reduzir o custo do RDS tirando-o de São Paulo

> Como manter a EC2 em São Paulo e levar o RDS para a Virgínia, mais barata, ligando as duas VPCs com VPC Peering. E o que medir antes de decidir.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos, Rede, Banco de dados
- URL: https://pages.formacaoaws.com.br/blog/vpc-peering-reduzir-custo-rds/
- Aula de origem: "Como reduzir custo na AWS usando VPC Peering" (https://www.youtube.com/watch?v=_FS1p0TjnnY)

O RDS em São Paulo custava mais que o dobro do mesmo RDS na Virgínia. Se só a EC2 precisa ficar no Brasil, dá para levar o banco para a Virgínia e ligar as duas redes com VPC Peering, sem mexer no código da aplicação.

Abaixo, o desenho que usei num cliente de consultoria, os quatro passos e o que medir antes de decidir: data transfer, latência e segurança. Serve para qualquer ambiente em que um recurso ficou numa região cara por hábito, e não por exigência.

## O cenário: a EC2 precisa estar em São Paulo, o banco não

O cliente tinha um requisito de negócio: o processamento rodava numa EC2 na região de São Paulo. Para a EC2 falar com o banco, ele tinha colocado o RDS também em São Paulo. Usei o t3.medium como modelo para os dois.

Perguntei se existia algum requisito que obrigasse o banco a ficar em São Paulo. Não existia. Então o banco podia ir para a região onde o RDS custa menos.

Na página de preço do Aurora com PostgreSQL, um t3.medium em São Paulo custava 0,168 dólar por hora. Na Virgínia, 0,082: menos da metade do preço só por trocar a região do RDS.

![Linha do db.t3.medium na página de preço do Amazon Aurora (PostgreSQL): 0,168 USD por hora em São Paulo e 0,082 USD por hora na Virgínia](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-reduzir-custo-rds/custo-rds-sao-paulo-x-virginia.webp)

São os valores que eu li na tela na aula, gravada em novembro de 2021. Preço muda: confira na [página de preços do Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/) antes de decidir.

## O problema: liberar acesso por IP não escala

Com o RDS na Virgínia, a EC2 de São Paulo passa a falar com ele por outra região. A saída óbvia é entrar no security group do banco na Virgínia e liberar a porta 5432 (PostgreSQL) para o IP da instância.

Funciona para uma instância. Numa infraestrutura que escala, aparecem duas, três, dez, e o IP público de cada uma é dinâmico. Ficar adicionando IP por IP não faz sentido.

E tem outro custo: para aceitar conexão de IP público, o banco precisa estar com acesso público ligado.

O VPC Peering resolve esse ponto: ele constrói um caminho por dentro da AWS entre a VPC de São Paulo e a da Virgínia, em vez de o tráfego sair pela internet.

## Passo 1: crie as duas VPCs com ranges diferentes

Na VPC de São Paulo, usei de exemplo o range 172.31.0.0/16, que provavelmente é o da sua VPC padrão. Na Virgínia, criamos uma VPC com 172.29.0.0/16.

> **Importante:** os ranges de IP das duas VPCs não podem ser iguais. Você vai precisar dessa diferença na hora de configurar a route table e o resto do mapeamento do peering.

## Passo 2: crie o VPC Peering entre as duas VPCs

O VPC Peering liga a VPC de São Paulo à da Virgínia. Na aula eu só cito que, ao criar, os ranges precisam ser diferentes, e que depois é preciso configurar as route tables para o tráfego seguir pelo peering. Eu não mostro os cliques do console: o foco do vídeo é o desenho e os pontos de atenção. No nosso cenário, a EC2 fica numa VPC e o RDS na outra.

**O que a aula não mostra** (procedimento padrão da AWS, não é o que eu fiz na tela): como as VPCs estão em regiões diferentes, o pedido de peering sai da região de uma VPC e precisa ser aceito na região da outra, e depois as route tables dos dois lados ganham uma rota para o range da VPC par, apontando para o peering. Passo a passo na documentação oficial: [criar o peering](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html), [aceitar o pedido](https://docs.aws.amazon.com/vpc/latest/peering/accept-vpc-peering-connection.html) e [atualizar as route tables](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html).

**Fluxo:** Amazon EC2 (em São Paulo, onde o negócio exige) → VPC Peering (caminho privado dentro da AWS) → Amazon RDS (na Virgínia, região mais barata)

## Passo 3: libere o range da VPC no security group, não os IPs

No security group do RDS, em vez de listar o IP de cada instância, você libera o range da VPC (ou da subnet) onde estão as EC2. No desenho da aula, a regra do banco na Virgínia ficou assim: o range 172.31.0.0/16, a VPC de São Paulo, na porta 5432.

![As EC2 na VPC de São Paulo (172.31.0.0/16) ligadas por VPC Peering ao RDS na VPC da Virgínia (172.29.0.0/16), cujo security group libera 172.31.0.0/16 na porta 5432](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-reduzir-custo-rds/vpc-sao-paulo-virginia.svg)

Com isso o tráfego deixa de passar pela internet e acontece só por dentro da AWS. Instância nova que subir em São Paulo já está dentro do range liberado: não há IP para atualizar.

## Passo 4: feche o acesso público do RDS

Pelo IP público, o RDS precisava de acesso público. Com o peering, você pode configurar o banco para ter só acesso privado. O DNS público do RDS passa a resolver para o IP privado dele, e o tráfego fica todo dentro do canal do peering. Eu digo na aula que é uma configuração que se faz no peering para esse caminho funcionar, mas não mostro a tela.

**O que a aula não mostra:** segundo a documentação da AWS, essa opção é a resolução de DNS do peering ("Edit DNS settings", nos dois lados, requester e accepter). Ela só pode ser ligada com o peering já ativo, e as duas VPCs precisam ter DNS hostnames e DNS resolution habilitados. Detalhes em [Enable DNS resolution for a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html).

Nas EC2 você troca a connection string para o banco novo. Como o DNS público resolve para o IP privado, não é preciso mexer no código da aplicação: é só configuração.

## O que medir antes de decidir

O custo do RDS ficou resolvido. Mas trocar a região do banco cria outros três pontos para avaliar.

**Data transfer.** Com EC2 e banco na mesma região, o tráfego entre zonas de disponibilidade custa 1 centavo de dólar por giga, e na mesma zona não é cobrado. Depois da troca, o tráfego sai de São Paulo para a Virgínia, e a direção importa.

Na tabela de preços de São Paulo, a saída para a Virgínia custava 0,138 dólar por giga. Para a internet, 0,15, que é a faixa logo depois do primeiro giga gratuito do mês.

![Tabela de transferência de dados do Amazon EC2 com origem em São Paulo: 0,15 USD por GB para a internet e 0,138 USD por GB para a Virgínia](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-reduzir-custo-rds/data-transfer-sao-paulo.webp)

Todo custo de dados que sai do Brasil é mais alto. Entre regiões dos EUA, o valor fica bem próximo do custo dentro da região. A conta a fazer: veja quanto você trafega hoje dentro da região, multiplique pelo preço de saída e compare com a economia do RDS.

**Latência.** Nos meus testes, o ping entre São Paulo e a Virgínia dava cerca de 100 milissegundos. Teste se a sua aplicação se comporta bem com isso, porque a aplicação passa a falar com o banco por essa distância.

**Segurança.** Aqui o peering ajuda: o tráfego passa por dentro da VPC e o banco deixa de precisar de acesso público.

E uma ressalva: o VPC Peering não é bala de prata e não resolve todos os problemas. Ele vale para redução de custo neste cenário. Vale também se você já trafega dados entre regiões da AWS pela internet: rever isso para o tráfego passar por dentro da AWS é um caminho mais limpo.

## A alternativa: SQS no lugar do peering

Na semana seguinte gravei [uma segunda aula sobre o mesmo cenário](https://www.youtube.com/watch?v=_YbhMErkj_4), comparando o VPC Peering com o SQS. Os dois pontos de atenção do peering, data transfer e latência, são o motivo.

A ideia: se a EC2 de São Paulo precisa do banco só para pegar e devolver trabalho, ela não precisa falar com ele.

O cliente demanda o trabalho por uma API, numa EC2 na Virgínia. Ela grava o trabalho no RDS e joga uma mensagem numa fila SQS dizendo que há trabalho novo. A EC2 de São Paulo consome a fila, processa e devolve o resultado numa segunda fila. Um listener lê essa fila e grava no banco.

![A API na Virgínia manda o trabalho para a fila SQS, as EC2 de São Paulo processam e devolvem na SQS-2, e o resultado vai para o RDS na Virgínia](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-reduzir-custo-rds/sqs-no-lugar-do-peering.svg)

O que muda em relação ao peering:

- **Data transfer e latência saem de cena.** A comunicação direta entre São Paulo e Virgínia deixa de existir, então o custo de transferência entre regiões e os 100 milissegundos também.
- **O SQS é muito barato.** Na aula, 40 centavos de dólar por milhão de requisições; na tela, era a fila padrão, depois do primeiro milhão do mês, que é gratuito, com a região Ohio selecionada. Confira na [página de preços do Amazon SQS](https://aws.amazon.com/sqs/pricing/).
- **Dá para escalar pela fila.** Chegou trabalho, escala capacidade e processa.
- **Mas exige mudança de código.** A API precisa mandar a mensagem e o consumidor precisa ler a fila. No peering foi só configuração.

A escolha depende do cliente. Se as EC2 precisam conversar com o banco, o SQS não serve e o peering continua necessário. Se toda a comunicação pode virar mensageria, o SQS é mais eficiente e ainda desacopla o processo.

## Um caso real posterior

Em outro texto deste blog eu conto um caso real de VPC Peering para reduzir custo de RDS, com banco e API indo para a Virgínia, o que isso fez com a latência e com o banco, e como medir o resultado: [VPC Peering em caso real: região mais barata e o impacto no banco](https://pages.formacaoaws.com.br/blog/vpc-peering-caso-real-regiao-mais-barata/).

## Checklist

- Confirme se existe requisito de negócio que prenda cada recurso a uma região. Se não existe, compare o preço em outras regiões.
- Crie as duas VPCs com ranges de IP diferentes.
- Crie o VPC Peering, aceite o pedido na outra região e configure as route tables dos dois lados (a aula só cita; veja a documentação da AWS).
- No security group do banco, libere o range da VPC, não os IPs públicos.
- Desligue o acesso público do RDS e ligue a resolução de DNS do peering, para o DNS público resolver para o IP privado.
- Calcule o data transfer: o que trafega hoje multiplicado pelo preço da região.
- Meça a latência com ping entre as duas regiões e teste a aplicação.
- Avalie se a comunicação com o banco pode virar fila SQS, que elimina data transfer e latência.
- Confira os preços atuais nas páginas oficiais da AWS.

No meu cenário, o RDS custava menos da metade na Virgínia e a EC2 continuou em São Paulo, onde o negócio exigia. O peering fez a ponte sem mexer na aplicação, e o SQS é o caminho se você puder mexer.