# Migrar de região na AWS: de São Paulo à Virgínia sem downtime

> Como tirar uma aplicação de São Paulo para a Virgínia sem parar o serviço: Aurora Global Database no banco, Cross Region Replication no S3 e a virada.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Migração, Custos
- URL: https://pages.formacaoaws.com.br/blog/migrar-aplicacao-de-regiao-na-aws/
- Aula de origem: "Desafios para migrar uma aplicação de região na AWS" (https://www.youtube.com/watch?v=8dRuBy2PCc0)

Rodar na região de São Paulo custa mais caro, e levar a aplicação para a Virgínia baixa a fatura. O difícil é mover o banco e os arquivos sem derrubar o serviço: abaixo está a ordem que usei com um cliente, com o Aurora Global Database no banco e o Cross Region Replication no S3, sem downtime.

## Por que sair de São Paulo

Serviço que roda no Brasil é naturalmente mais caro na nuvem. A Virgínia é uma das regiões mais baratas da AWS, e dá para entregar a aplicação de lá com a mesma performance que ela teria em São Paulo. O motivador é custo.

## O que complica: banco e arquivos

No desenho, a aplicação tem três partes: a aplicação web, o banco no RDS e os arquivos no S3. A aplicação web é a parte simples: basta fazer o deploy dela na outra região. O problema é o banco e os arquivos.

![O ponto de partida: web, banco e S3 em São Paulo e a web já na Virgínia, com setas do banco e do S3 apontando para lá](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-de-regiao-na-aws/sp-para-virginia.svg)

A saída tradicional é fazer um backup ou dump do banco e restaurar na Virgínia. Com um banco de 500 GB, quanto tempo a aplicação fica parada?

E tem o risco de sincronismo: se você fez o backup, não desligou a aplicação e entrou dado novo em São Paulo, pode perder esse dado.

Um serviço de réplica ajuda, mas você passa a gerenciar mais um serviço só para isso, como o DMS, o serviço da AWS de migração de dados.

No meu cliente, o caminho foi outro: usar a sincronização que a própria AWS oferece para o banco e para os arquivos, e só depois fazer a virada.

## Passo 1: ensaiar tudo na homologação

Montamos um ambiente de homologação íntegro e simulamos o processo inteiro nele. Foi ali que vimos que o sincronismo do banco funcionava e que, no fim, daria para fazer o failover para a nova região assumir.

Só depois de tudo simulado aplicamos o mesmo processo em produção.

## Passo 2: montar a região de destino

Na Virgínia, primeiro a rede: VPC, subnets, NAT Gateway, VPC endpoints e o restante da estrutura. Depois, o deploy da aplicação web.

A aplicação web pode estar deployada dos dois lados, desde que não esteja recebendo requisição nem mandando fluxo para lugar nenhum.

## Passo 3: sincronizar o banco com o Aurora Global Database

O banco do cliente já era Aurora, que usa engines de mercado: PostgreSQL ou MySQL. O Aurora tem um recurso chamado **Aurora Global Database**, que estudamos a fundo.

Com ele, os dados de São Paulo passaram a ser sincronizados com a Virgínia, e os dois lados ficaram iguais em tempo real. No fim do processo, um failover faz a nova região assumir.

![RDS riscado, Aurora com PostgreSQL ou MySQL, e o banco de São Paulo ligado ao banco da Virgínia pelo Aurora Global Database (AGD)](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-de-regiao-na-aws/aurora-global-database.svg)

## Passo 4: sincronizar o S3 com o Cross Region Replication

A ideia mais intuitiva para o S3 é copiar os arquivos com um sync e, depois da virada, conferir a diferença. Funciona, mas é manual, não escala e deixa você preocupado se está tudo íntegro do outro lado. No meu cliente eram mais de 5 milhões de arquivos.

A AWS tem um recurso para isso: o **Cross Region Replication**. Você cria o bucket na região de destino, habilita o Cross Region Replication, e a AWS faz o sincronismo do S3 do ponto A para o ponto B.

Com os dois recursos, tudo funcionou do lado B praticamente sem tocar nos dados do lado A. Sem dump, sem fluxo manual e sem parar o serviço.

## Passo 5: fazer a virada

Com banco e arquivos sincronizados, a virada é o momento em que o usuário, que apontava para São Paulo, passa a apontar para a Virgínia. Usamos também um CDN nessa etapa.

Os detalhes do CDN (origem, behavior, os apontamentos que fizemos) e os outros recursos envolvidos ficam fora deste texto. O que importa é que a virada aconteceu sobre dados já sincronizados dos dois lados.

## Passo 6: cortar o fluxo e apagar São Paulo

Depois da virada, com a Virgínia assumindo, cortamos o fluxo que acontecia entre São Paulo e a Virgínia. Esperamos 48 horas e só então apagamos os dados em São Paulo e desligamos o banco de lá.

![Depois da virada: banco e S3 de São Paulo riscados, banco e S3 já na Virgínia, e um X sobre cada fluxo antigo (AGD no banco, CRR no S3)](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-de-regiao-na-aws/virada-e-limpeza.svg)

**Fluxo:** Homologação (ensaio do processo inteiro) → Virgínia (rede e aplicação web) → Sincronização (banco e arquivos nos dois lados) → Virada (com o CDN) → São Paulo (apagado após 48 horas)

## O que o cliente ganhou

Em junho de 2023, quando gravei a aula, contei que essa migração deu ao meu cliente uma redução de 30% a 40% na fatura, todo mês.

> **Importante:** esse percentual é o do caso citado na aula, não uma promessa. Antes de decidir, confira os preços atuais das duas regiões na página oficial de preços de cada serviço.

Conhecer os recursos da AWS é o que faz a diferença nessa hora. Sem esse domínio, a tendência é fazer como dá na cabeça: backup de um lado, sync para o outro, operações que trazem risco para a migração.

## Checklist

- Monte um ambiente de homologação íntegro e simule a migração inteira nele.
- Prepare a região de destino: VPC, subnets, NAT Gateway, VPC endpoints e a aplicação web.
- Banco em Aurora (PostgreSQL ou MySQL): sincronize com o Aurora Global Database.
- Arquivos no S3: crie o bucket de destino e habilite o Cross Region Replication.
- Faça a virada com o CDN e corte o fluxo entre as regiões.
- Espere um tempo (no meu caso, 48 horas) e só então apague os dados e desligue o banco na região antiga.

Se a sua aplicação roda em São Paulo e você quer avaliar se uma migração de região compensa e como fazê-la sem downtime, é conversa para a gente ter olhando a sua conta.