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

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.

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 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.

1Crie 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.

2Crie 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, aceitar o pedido e atualizar as route tables.

3Libere 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.

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.

4Feche 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.

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.

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, 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.

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.
• 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.

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.