Disaster Recovery não é sobre tecnologia — é sobre quanto tempo e quanto dado você pode perder antes de a empresa sentir. Defina o RPO e o RTO primeiro. Depois escolha a estratégia. A AWS tem opções para cada ponto nesse espectro, mas o custo varia dramaticamente entre elas.
Os dois números que definem tudo: RPO e RTO
RPO (Recovery Point Objective): quanto de dado você pode perder. Se o RPO é de 1 hora, significa que você aceita perder até 1 hora de transações em caso de desastre. Se é de 0, você precisa de replicação síncrona em tempo real.
RTO (Recovery Time Objective): quanto tempo leva para voltar a operar. Se o RTO é de 4 horas, o sistema pode ficar fora por até 4 horas. Se é de 15 minutos, você precisa de failover quase automático.
A relação entre RPO/RTO e custo é direta: quanto menores os dois números, mais cara é a estratégia. O erro mais comum é definir RPO=0 e RTO=0 para tudo — isso é ativo-ativo global e custa uma fortuna. A maioria dos sistemas tolera mais do que parece quando você senta com o negócio e faz as perguntas certas.
Os 4 padrões de DR na AWS
1. Backup & Restore
O mais simples e mais barato. Você mantém backups dos dados e das configurações na AWS (geralmente no S3) e, em caso de desastre, provisiona a infraestrutura do zero com esses backups.
RPO: horas (depende da frequência de backup)
RTO: horas (tempo para provisionar + restaurar)
Custo: muito baixo — você paga só pelo armazenamento dos backups
Quando usar: sistemas não críticos, workloads de desenvolvimento e homologação, dados de baixo impacto.
Como funciona na prática: AMIs das instâncias EC2 armazenadas no S3, snapshots de RDS com retenção definida, backups do EFS. Para restaurar, você usa Terraform ou CloudFormation para recriar a infraestrutura e restaura os dados dos backups.
2. Pilot Light
Você mantém a infraestrutura crítica mínima rodando na AWS em modo “dormindo” — banco de dados replicado em tempo real, mas sem servidores de aplicação. Em caso de desastre, você escala rapidamente os recursos que faltam.
RPO: minutos (replicação de banco em tempo real)
RTO: horas (tempo para escalar a aplicação)
Custo: baixo a médio — você paga pela replicação do banco e por instâncias mínimas
Quando usar: sistemas de importância média, onde o banco é o recurso mais crítico e a aplicação pode ser recriada rapidamente.
Como funciona: RDS com réplica de leitura em outra região. Em caso de failover, você promove a réplica a primário e sobe as instâncias EC2 da aplicação (via Auto Scaling) apontando para o novo banco.
3. Warm Standby
Uma versão reduzida do ambiente de produção rodando continuamente na região de DR. Não tem capacidade total, mas está funcional. Em caso de desastre, você aumenta a capacidade para igualar a produção.
RPO: segundos a minutos (dados replicados continuamente)
RTO: minutos (tempo para escalar capacidade)
Custo: médio a alto — você paga por uma infraestrutura menor mas sempre ligada
Quando usar: sistemas críticos com RTO de minutos, onde você pode justificar o custo de manter um ambiente paralelo menor.
Como funciona: ambiente de DR com instâncias menores (t3.small em vez de m5.large, por exemplo), banco replicado, load balancer configurado. O Route 53 redireciona o tráfego automaticamente via health checks.
4. Active-Active (Multi-Site)
Dois ambientes idênticos rodando simultaneamente, em regiões diferentes, com tráfego distribuído entre eles. Em caso de falha de uma região, a outra absorve 100% do tráfego automaticamente.
RPO: zero (ou próximo de zero)
RTO: segundos (failover automático via Route 53)
Custo: muito alto — você paga por dois ambientes completos mais o custo de egresso de replicação entre regiões
Quando usar: sistemas extremamente críticos onde qualquer downtime tem impacto financeiro ou de segurança mensurável. Exemplos: e-commerce de alto volume, sistemas financeiros, infraestrutura crítica nacional.
Comparativo das estratégias
| Estratégia | RPO | RTO | Custo relativo | Complexidade |
|---|---|---|---|---|
| Backup & Restore | Horas | Horas | $ | Baixa |
| Pilot Light | Minutos | 1–4 horas | $$ | Média |
| Warm Standby | Segundos | 15–60 min | $$$ | Alta |
| Active-Active | ~Zero | Segundos | $$$$ | Muito Alta |
Custo de DR multi-região: o que você paga a mais
Egresso de replicação: dados replicados entre regiões AWS custam US$ 0,02/GB. Para um banco de dados de 1 TB que replica continuamente, o log de transações diário pode representar dezenas de GB — e esse custo se acumula.
Instâncias em standby: no warm standby, você paga por instâncias que não estão servindo produção. Se a produção custa US$ 5.000/mês em instâncias, o warm standby adiciona mais US$ 1.500–2.500/mês em capacidade reduzida.
Transferência de Route 53 health checks: o Route 53 faz health checks de minutagem e cobra por verificação. Para múltiplos endpoints em múltiplas regiões, isso se acumula.
Replicação de S3 cross-region (CRR): se você replica dados do S3 entre regiões, paga pelo armazenamento em ambas e pelo egresso da replicação.
Quando cloud privada secundária é mais econômica
Para empresas brasileiras com workloads estáveis, uma arquitetura de DR usando cloud privada como site secundário pode ser significativamente mais barata que DR multi-região na AWS.
Por que funciona:
- A cloud privada em BRL elimina o câmbio da equação de DR
- Egresso entre datacenter primário e secundário via link dedicado tem custo fixo previsível
- Não há cobrança por GB de replicação entre os sites
- Para warm standby ou pilot light, manter VMs menores em cloud privada custa uma fração do que em AWS
Quando faz mais sentido:
- Seu ambiente primário está parcialmente em cloud privada — faz sentido ter o DR também em cloud privada
- O workload de DR é estável e bem dimensionado — você sabe exatamente quantas VMs vai precisar
- A previsibilidade de custo em BRL é um requisito de gestão financeira
Precisa de DR com custo previsível em BRL usando cloud privada como site secundário? Fale com um arquiteto Adentro — temos Tiers III em três localizações.