Disaster Recovery na AWS: Estratégias Multi-Região para Garantir Continuidade de Negócio

Eduardo Souza | CEO Dominit

Toda empresa acredita ter um plano de disaster recovery até o dia em que precisa executá-lo de verdade — e é exatamente nesse momento que a maioria descobre que o plano só existia no papel. Disaster Recovery na AWS não é sobre ter backup (isso é só o ponto de partida); é sobre garantir que a empresa consegue voltar a operar dentro de um tempo aceitável, com uma perda de dado aceitável, mesmo que uma região inteira da AWS fique indisponível. Neste guia avançado, você vai entender como definir RTO e RPO corretamente, as quatro estratégias de DR reconhecidas pela AWS, e como testar um plano de recuperação antes que um incidente real force esse teste por você.

RTO e RPO: as Duas Métricas Que Definem Qualquer Estratégia de DR

Antes de escolher qualquer estratégia técnica de disaster recovery, a empresa precisa responder a duas perguntas de negócio — não de tecnologia:

RTO (Recovery Time Objective) — quanto tempo o negócio consegue tolerar um sistema fora do ar antes que o impacto se torne inaceitável? Um e-commerce e um sistema de relatórios internos têm RTOs completamente diferentes, mesmo rodando na mesma conta AWS.

RPO (Recovery Point Objective) — quanto dado a empresa pode se dar ao luxo de perder, medido em tempo? Um RPO de uma hora significa que, no pior cenário, a empresa aceita perder até uma hora de transações desde o último ponto de recuperação válido.

O erro mais comum nessa etapa é a área de tecnologia definir RTO e RPO sozinha, sem envolver quem entende o real impacto financeiro e reputacional de cada minuto de indisponibilidade — o resultado costuma ser uma estratégia tecnicamente elegante, mas desalinhada do que o negócio realmente precisa (ou paga por algo mais caro do que o necessário).

As Quatro Estratégias de Disaster Recovery da AWS

A AWS organiza as estratégias de DR em um espectro que vai de mais barato/mais lento a mais caro/mais rápido — a escolha certa depende diretamente do RTO e RPO definidos:

Estratégia	RTO típico	RPO típico	Custo relativo	Como funciona
Backup and Restore	Horas	Horas	Mais baixo	Backups armazenados, restaurados sob demanda em caso de desastre
Pilot Light	Dezenas de minutos	Minutos	Baixo-médio	Núcleo mínimo dos sistemas críticos já rodando, escalado no momento do desastre
Warm Standby	Minutos	Segundos a minutos	Médio-alto	Versão reduzida do ambiente de produção rodando continuamente na região de DR
Multi-Site Active-Active	Quase zero	Quase zero	Mais alto	Ambiente completo rodando simultaneamente em múltiplas regiões

Não existe estratégia “certa” de forma absoluta — existe a estratégia certa para o RTO/RPO que o negócio realmente exige. Aplicar Multi-Site Active-Active a um sistema que tolera horas de indisponibilidade é desperdício de investimento; aplicar Backup and Restore a um sistema crítico de receita é risco inaceitável.

Backup and Restore: a Base de Qualquer Estratégia de DR

Mesmo estratégias mais sofisticadas de DR dependem de uma disciplina de backup sólida como fundação. Isso inclui backups automatizados e testados regularmente (não só configurados uma vez e esquecidos), armazenamento em uma região diferente da região primária (backup na mesma região não protege contra a falha da região inteira), e política de retenção alinhada ao RPO definido — não ao que é tecnicamente mais barato de manter.

O erro mais caro nessa camada não é a ausência de backup — é a ausência de teste de restauração. Um backup que nunca foi restaurado de verdade é uma suposição, não uma garantia.

Pilot Light e Warm Standby: o Meio-Termo Mais Comum em Empresas de Médio Porte

Para a maioria das empresas de médio porte, o equilíbrio entre custo e velocidade de recuperação está nas estratégias intermediárias:

Pilot Light mantém apenas os componentes centrais e mais difíceis de recriar rapidamente (geralmente o banco de dados, replicado continuamente) já rodando na região de DR, enquanto o restante da infraestrutura é provisionado sob demanda no momento do desastre — reduzindo custo continuo, ao custo de um RTO maior do que estratégias mais robustas.

Warm Standby mantém uma versão reduzida (mas funcional) de todo o ambiente rodando continuamente na região de DR, escalada para capacidade total apenas quando o failover é acionado — um RTO mais baixo que Pilot Light, com um custo de operação contínuo maior.

A escolha entre as duas costuma depender de quanto RTO em minutos realmente importa para o negócio, e de quanto custo contínuo a empresa está disposta a pagar por essa margem de velocidade adicional — a mesma lógica de trade-off explícito que o AWS Well-Architected Framework pede que toda decisão de arquitetura considere.

Multi-Site Active-Active: Quando o RTO Zero Justifica o Investimento

Multi-Site Active-Active roda o ambiente completo, simultaneamente, em múltiplas regiões, com tráfego distribuído entre elas em condições normais — não é uma região de DR “esperando”, é uma segunda produção ativa o tempo todo. Em caso de falha de uma região, o tráfego é redirecionado para a(s) região(ões) restante(s), sem o processo de “acordar” um ambiente de DR.

Esse nível de resiliência tem um custo de arquitetura e operação significativamente maior — replicação de dado em tempo real entre regiões, resolução de conflitos de escrita concorrente, e complexidade adicional de deployment em múltiplos ambientes simultaneamente. Faz sentido para sistemas onde cada minuto de indisponibilidade tem um custo de negócio claramente maior do que o custo adicional de operar essa arquitetura — tipicamente sistemas de receita direta em escala, não a maioria dos sistemas internos de uma empresa.

AWS Elastic Disaster Recovery: Simplificando a Estratégia de Pilot Light

O AWS Elastic Disaster Recovery (DRS) automatiza boa parte da complexidade de manter uma estratégia de Pilot Light ou Warm Standby: replica continuamente servidores (incluindo cargas rodando fora da AWS) para uma região de destino, com um custo de infraestrutura mínimo enquanto o ambiente de DR não está ativo, escalando para capacidade total apenas no momento do failover.

Isso reduz significativamente a complexidade de configurar e manter uma estratégia de DR intermediária manualmente — o tipo de solução que costuma fazer sentido para empresas que reconhecem a necessidade de uma estratégia mais robusta que backup simples, mas não têm o volume de investimento (ou a necessidade real) para justificar Multi-Site Active-Active.

Testando o Plano de DR: o Passo Que a Maioria das Empresas Pula

A diferença entre um plano de disaster recovery real e um documento que existe só para auditoria é o teste:

Teste de restauração de backup — validar que o backup realmente restaura um ambiente funcional, não só que o processo de backup “roda sem erro”.

Simulação de failover controlado — executar o processo de failover para a região de DR em um ambiente controlado (fora do horário de pico, com aviso à equipe), medindo se o RTO real bate com o RTO planejado.

Revisão pós-teste com toda a equipe envolvida — cada teste revela gaps que a documentação não previu; o valor do teste não é só validar que funciona, é encontrar o que não funciona antes que um desastre real force essa descoberta.

Empresas que tratam teste de DR como evento anual isolado, em vez de rotina, frequentemente descobrem no momento real do desastre que a documentação está desatualizada em relação à infraestrutura que de fato existe hoje.

Custo de Disaster Recovery: Como Justificar o Investimento

Investimento em DR é, por natureza, um investimento em algo que a empresa espera nunca precisar usar — o que torna difícil justificá-lo financeiramente sem conectar diretamente ao custo real de indisponibilidade. A pergunta certa não é “quanto custa ter DR”, é “quanto custaria por hora se esse sistema ficasse fora do ar, e esse valor justifica o custo mensal da estratégia de DR escolhida?”.

A mesma disciplina de acompanhamento contínuo de custo que já cobrimos em FinOps AWS se aplica à infraestrutura de DR: revisar periodicamente se o nível de investimento em recuperação ainda corresponde à criticidade real do sistema, conforme o negócio muda.

Perguntas Frequentes Sobre Disaster Recovery na AWS

Qual a diferença entre backup e disaster recovery?

Backup é a cópia dos dados; disaster recovery é a estratégia completa — incluindo infraestrutura, processo e tempo — para restaurar a operação do sistema inteiro após uma falha, não só os dados.

Como defino o RTO e RPO certos para minha empresa?

Envolvendo áreas de negócio, não só tecnologia, para quantificar o impacto real de indisponibilidade e perda de dado por sistema — sistemas diferentes dentro da mesma empresa costumam ter RTO/RPO diferentes.

Preciso de Multi-Site Active-Active para ter um bom DR?

Não. A maioria das empresas de médio porte é bem atendida por Pilot Light ou Warm Standby — Multi-Site Active-Active só se justifica quando o custo de qualquer indisponibilidade, mesmo mínima, é claramente maior que o custo adicional dessa arquitetura.

Com que frequência devo testar meu plano de disaster recovery?

Pelo menos uma vez por ano, idealmente com mais frequência para sistemas críticos — e sempre após mudanças relevantes de arquitetura, já que a documentação de DR desatualizada é uma das causas mais comuns de falha real de recuperação.

O AWS Elastic Disaster Recovery substitui a necessidade de um plano de DR?

Não — ele automatiza a parte técnica de replicação e failover, mas o plano de DR ainda precisa definir RTO/RPO, processo de decisão de quando acionar o failover, e comunicação durante o incidente.

Disaster Recovery Como Investimento em Continuidade, Não Como Item de Checklist

Disaster Recovery na AWS não é um documento assinado uma vez e guardado numa pasta — é uma capacidade que só existe de verdade quando testada e mantida atualizada conforme a infraestrutura evolui. A escolha entre as quatro estratégias reconhecidas pela AWS não é uma questão de qual é “melhor”, é uma questão de qual RTO e RPO o negócio realmente precisa, e quanto ele está disposto a pagar por essa garantia.

As empresas que tratam DR como disciplina contínua — testada, revisada e ajustada conforme o negócio muda — são as que descobrem que o plano funciona no momento em que mais importa, em vez de descobrir, tarde demais, que ele só existia no papel.