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

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.

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.

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

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

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

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

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

6Cortar 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á.

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.

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.