# VPC Peering em caso real: região mais barata e o impacto no banco

> Levei o banco de um cliente de São Paulo para a Virgínia, a latência foi de 100 para 600 ms e o RDS sofreu com concorrência. O que medi e o que resolveu.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos, Rede, Migração
- URL: https://pages.formacaoaws.com.br/blog/vpc-peering-caso-real-regiao-mais-barata/
- Aula de origem: "Cenário Real: Impactos na prática no uso de VPC Peering para reduzir custo com RDS na AWS em 50%" (https://www.youtube.com/watch?v=fj4v_vJKtNA)

Levar o banco de São Paulo para a Virgínia pode cortar o preço dele pela metade, mas, num cliente meu, a latência da aplicação foi de 100 para 600 milissegundos depois da mudança. Aqui você vê como eu achei a causa, por que não desfiz a mudança e o que resolveu sem devolver o custo.

## O cenário: só uma parte da aplicação precisa estar no Brasil

Um dos caminhos para reduzir custo na AWS é usar regiões mais baratas. São Paulo é a região mais cara, e muita gente põe a aplicação lá por vários motivos. O primeiro e mais óbvio é o requisito de negócio: a aplicação precisa falar com algum órgão do governo e, por exigência ou bloqueio, não pode rodar num servidor internacional.

Foi o caso de um cliente meu. A solução inteira estava no Brasil. Depois da análise, ficou claro que a solução inteira não precisava estar: só a parte que se comunica com o governo.

A aplicação web dele tem duas camadas, que eu resumo assim:

- **Worker.** Consome trabalhos de uma fila SQS, faz processamento de dados em batch e só conversa com o banco de vez em quando. É ele quem fala com o governo federal, com governos estaduais e com outros serviços que exigem a aplicação no Brasil.
- **API.** Atende os usuários, que chegam por um sistema que o cliente já tinha, e tem uma comunicação bem maior com o banco.

Para tirar uma parte de São Paulo e manter a comunicação, usamos o VPC Peering: um canal que corre por dentro da rede da AWS e liga duas regiões, aqui São Paulo e a Virgínia (us-east-1). Com ele, você escolhe qual recurso vai trabalhar na região mais barata, e as duas partes continuam se falando por esse canal.

## Passo 1: mover o banco e conferir o preço

A primeira ideia foi pegar o banco e levar para a Virgínia. Foi o que fizemos.

Para mostrar o tamanho do ganho, usei um exemplo de preço de lista, e não o banco do cliente: um RDS PostgreSQL sob demanda, com 4 vCPU e 32 GB de memória (db.r5.xlarge). O banco do cliente é outro, um SQL Server, como você vai ver adiante.

![O mesmo RDS PostgreSQL db.r5.xlarge sob demanda custa US$ 1,0470 por hora em São Paulo e US$ 0,5000 na Virgínia](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-caso-real-regiao-mais-barata/precos-por-regiao.webp)

Na Virgínia, o preço fica em cerca de metade: no exemplo, 50% a menos no custo do banco só com a mudança. Você paga um pouco de data transfer entre as regiões, cobrado por giga. No cliente, o volume era pequeno e o custo de tráfego entre as regiões também.

> **Importante:** os valores são os que apareciam na tela em dezembro de 2022, num exemplo. Não são a conta do cliente nem uma tabela atual. Confira na [página de preços do Amazon RDS](https://aws.amazon.com/rds/pricing/) antes de comparar.

## O que quebrou: a latência subiu e o banco sofreu

Com o banco na Virgínia e as duas camadas ainda em São Paulo, a aplicação inteira degradou. O Performance Insights do RDS do cliente, que é SQL Server, mostrava um consumo alto de uma espera chamada CXCONSUMER: 3,59 na carga por espera, com horas de pico bem maiores. Achei pouca informação sobre ela, e a que encontrei associava o CXCONSUMER ao paralelismo de operações.

O primeiro reflexo de quem não conhece a aplicação é voltar o banco para São Paulo. Isso resolve, mas devolve o custo. Antes de decidir, olhei as métricas. A aplicação estava no Elastic Beanstalk, que já traz bastante métrica por padrão, e uma delas é a latência:

- Antes: em torno de 100 milissegundos.
- Depois da mudança: 600 milissegundos.
- Ida e volta entre São Paulo e a Virgínia: de 150 a 200 milissegundos nos piores casos.

A distância explicava uns 200 milissegundos dos 500 a mais. Faltavam uns 300. Cruzando com as métricas de deadlock e de concorrência do RDS, o CXCONSUMER apontava a mesma coisa: a concorrência no banco estava subindo.

## Por que a latência vira concorrência

Pense no número de conexões simultâneas que o banco aceita como um funil. No meu desenho, só para ficar fácil, o banco suporta 4 conexões ao mesmo tempo e cada uma leva 50 milissegundos. Em São Paulo, as 4 terminam no milissegundo 50 e a quinta já entra.

Agora some a latência da outra região, no pior caso 200 milissegundos: as 4 conexões passam a ocupar as vagas até o milissegundo 250. Se chega mais uma no milissegundo 50, não há vaga. Ela espera a janela de 200 milissegundos, começa só aos 250 e termina aos 500. O que levaria 200 passou para 500, e as próximas esperam em fila atrás dela.

![Linha do tempo em milissegundos: em São Paulo, 4 conexões de 50 ms terminam aos 50 ms; com 200 ms de latência elas ocupam o banco até 250 ms, e a quinta só começa aos 250 e termina aos 500 ms](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-caso-real-regiao-mais-barata/conexoes-e-latencia.svg)

Isso vira bola de neve: a espera segura as vagas, segura as próximas conexões e o gargalo piora. É um modelo simplificado, com números do desenho. O ponto é que latência entre região e banco não só soma tempo: ela segura a vaga de conexão por mais tempo.

## Passo 2: mover a API junto do banco, e não desfazer

Cada aplicação tem as suas métricas. Não existe um número que seja saudável em geral, e por isso eu recomendo gastar tempo conhecendo a sua aplicação. Foi o que mudou a decisão.

Olhei as duas camadas:

- **Worker.** Não dava para mexer nele: é quem fala com o governo e precisa ficar em São Paulo. Além disso, ele conversa só de vez em quando com o banco e não mostrava grandes problemas. Dava para mitigar com cache ou outras soluções de código, mas o caso não pedia.
- **API.** Estava em São Paulo só porque os outros serviços estavam lá. Não tinha requisito de negócio para isso e era a camada com mais comunicação com o banco.

Então a mudança foi mover a API para a Virgínia, junto do banco. O worker continua em São Paulo e fala com o banco pelo VPC Peering:

**Fluxo:** Worker (em São Paulo, fala com o governo) → VPC Peering (canal pela rede da AWS) → API e Amazon RDS (região da Virgínia)

## Passo 3: medir de novo no Performance Insights

Antes, o CXCONSUMER estava em 3,59 na carga por espera do banco (AAS, sessões ativas médias). Depois de mover a API, ficou em 0,14. O problema foi resolvido.

![Top waits do Performance Insights: o CXCONSUMER estava em 3,59 antes e caiu para 0,14 depois de mover a API](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-caso-real-regiao-mais-barata/cxconsumer-antes-e-depois.webp)

O gráfico de carga de vários dias mostra a mesma virada. Os dois primeiros blocos são dias com o problema. No terceiro, a mudança entrou e o pico já é bem menor. Depois vem o fim de semana, quando essa aplicação não tem tráfego, e na segunda-feira a carga fica muito abaixo da dos dias com problema.

![Carga do banco no Performance Insights, em UTC: dois dias de picos altos, um pico menor no dia da mudança, o fim de semana parado e a segunda-feira bem abaixo](https://pages.formacaoaws.com.br/blog/assets/posts/vpc-peering-caso-real-regiao-mais-barata/carga-do-banco-por-dia.webp)

O Performance Insights traz muitas métricas. Quando você trabalha com RDS, habilite.

Com a decisão, o cliente não teve impacto no negócio e o ganho financeiro foi expressivo. Também implantamos cache nesse servidor, o que trouxe outro ganho e provavelmente vai permitir reduzir o tamanho do banco.

## Saber a hora de parar

Fomos avançando enquanto havia resultado. O custo do tráfego entre as regiões era pequeno, então fazia sentido seguir, desde que não houvesse impacto no negócio. Conhecer a aplicação serviu para não dar rollback às cegas e continuar na estratégia de custo.

## Checklist

- Liste o que da sua aplicação tem requisito de negócio para ficar em São Paulo e o que não tem.
- Compare o preço do mesmo recurso nas duas regiões, na página oficial.
- Meça o volume de data transfer entre as regiões antes de decidir.
- Habilite o Performance Insights do RDS.
- Anote a latência da aplicação antes da mudança, para comparar depois.
- Se a latência subir, olhe concorrência e deadlock no banco antes de desfazer.
- Mova junto do banco a camada que fala muito com ele e não tem requisito de ficar no Brasil.
- Meça de novo e decida se avança ou se para.

Mover só o que não precisa ficar no Brasil, medindo cada passo e sem desfazer às cegas, foi o que manteve a economia. Se você quer apoio para decidir o que pode sair de São Paulo na sua aplicação, o ponto de partida é conhecer a aplicação.