Disaster Recovery: 4 estratégias (backup a multi-site)
- ⬜🏛️ Well-Architected Framework aplicado em review(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
As 4 estratégias clássicas
Backup & Restore:
RTO: horas a dia
RPO: horas (snapshot frequency)
Custo: baixo (~0 em standby, só storage)
Uso: tier-3 apps, dev, conteúdo estático
Pilot Light:
RTO: 10-60 min
RPO: minutos (DB replicação contínua)
Custo: 5-15% do primário
Uso: tier-2 apps corporativos
Warm Standby:
RTO: 1-10 min
RPO: segundos
Custo: 30-50% do primário
Uso: tier-1 apps de negócio
Multi-Site Active/Active:
RTO: segundos (zero no ideal)
RPO: zero (DB sync replication)
Custo: 2x primário (ou mais)
Uso: missão-crítica (trading, payments)Onde isso entra no exame
As quatro estratégias e seus RTO/RPO são cobrança garantida, e a pegadinha é sempre o custo: pilot light replica dado com compute desligado; warm standby mantém uma versão reduzida ligada. Se o requisito é RPO próximo de zero, backup and restore está eliminado de saída.
Serviços AWS por camada de DR
Data replication:
- S3 Cross-Region Replication (CRR) + Same-Region (SRR)
- RDS cross-region read replicas (async)
- Aurora Global Database (write forwarding, RPO ~1s)
- DynamoDB Global Tables (multi-region multi-master)
Compute capacity:
- AMI cross-region copy (pipeline em CodeBuild)
- Launch Templates versionados, EC2 Image Builder
Orchestration:
- AWS Elastic Disaster Recovery (DRS, ex-CloudEndure)
replica bloco-nível pra região/AZ target, RPO segundos
- AWS Backup pra snapshots centralizados cross-account
cross-region (RDS/EBS/EFS/FSx/DynamoDB)
Traffic steering:
- Route 53 health checks + failover routing
- Route 53 Application Recovery Controller (ARC)
- Global Accelerator (anycast IP, cross-region)
Tests:
- AWS Fault Injection Service (FIS) pra game days
- Resilience Hub avalia RPO/RTO declarados vs realidade- → tráfego normal
- → failover
- → replicação global
- → CRR
- → provisiona igual
- → imagem pronta
- → valida
- Rede e entrega
- Compute
- Banco de dados
- Armazenamento
- Gestão e governança
Multi-região exige replicar quatro coisas: dado, imagem, infraestrutura e o gatilho de failover. Faltar qualquer uma faz o plano falhar no dia — e a que falta com mais frequência é a imagem.
- Comece pelo que dispara o failover. Route 53 com health check é o padrão; Global Accelerator troca em segundos e mantém IP fixo. Sem esse gatilho você tem região secundária de pé e ninguém sendo mandado para lá.
- Cada camada replica de um jeito. Aurora Global Database dá RPO de cerca de 1 segundo e promoção em menos de um minuto. S3 usa Cross-Region Replication. DynamoDB usa Global Tables. Não existe um botão só — são decisões por camada.
- A camada que todos esquecem: a imagem. AMI, imagem de container e artefato de deploy precisam existir na região secundária. Muito plano de DR falha no drill porque o banco replicou e não havia AMI para subir a aplicação.
- IaC é o que torna a secundária idêntica. A mesma definição aplicada nas duas regiões. Infra secundária montada à mão divergindo da primária é a causa mais comum de "o failover funcionou mas a aplicação não".
- DR não testado não é DR. Simulação periódica com cronômetro é o que transforma o número no documento em RTO real. Sem drill, o RPO/RTO do plano é uma aspiração — e o SAP-C03 pergunta isso de forma direta.
Um plano de DR multi-região replica o Aurora e o S3, mas no primeiro teste a aplicação não subiu na região secundária. Qual camada foi esquecida?
DR que funciona de verdade
DR não testado não existe. Game days regulares (trimestral mínimo), com cenários: falha de AZ inteira, falha de região, data corruption (requer restore point-in-time, não só failover), credenciais comprometidas. Automatizar o possível com playbook em Step Functions + SSM Automation — humano sob stress erra.
Antipattern: declarar "RTO 5 minutos" no SLA sem nunca ter testado failover real. Em incidente, descobre que IAM roles não existem na região DR, que DNS TTL é 3600s, que CDK nunca fez deploy lá. Teste trimestral não-negociável.
AWS Elastic Disaster Recovery (DRS) + Resilience Hub + FIS cobrem a maior parte do stack DR moderno. Combine com automação em Step Functions pra runbook executável, não PDF estacionado.
Perguntas frequentes
❓ Como escolher a estratégia de recuperação?
❓ Recuperação entre regiões é sempre necessária?
❓ Por que plano de recuperação falha na hora?
Fixando
Qual combinação atende RPO próximo de zero e RTO de menos de um minuto para um banco relacional?
Por que o teste periódico de DR é considerado parte do plano, e não uma verificação opcional?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…