Disaster Recovery: RPO, RTO e 4 Estratégias
- ⬜🪣 S3 Profundo: Classes, Lifecycle e Object Lock(AWS Solutions Architect Associate)
- ⬜🗃️ Bancos: Multi-AZ, Read Replicas e DynamoDB(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
DR não é “fazer backup”. É a capacidade de reconstruir a operação após desastre maior (região AWS offline, ataque ransomware, deleção massiva). Negócio define duas constantes: RPO (quanta perda de dado é aceitável) e RTO (quanto tempo pode ficar fora). Essas duas medidas direcionam qual das 4 estratégias implementar.
Definições que caem no exame
As 4 estratégias de DR
| Estratégia | RPO típico | RTO típico | Custo | Como funciona |
|---|---|---|---|---|
| Backup & Restore | horas | horas | $ | Backups regulares para outra região. Restaurar infra + dados sob demanda. |
| Pilot Light | minutos | 10–30 min | $$ | Dados replicados + infra crítica mínima rodando. Escala em disaster. |
| Warm Standby | segundos–minutos | minutos | $$$ | Stack funcional com capacidade reduzida. Failover + scale up. |
| Multi-Site Active-Active | ~zero | segundos | $$$$ | Duas (ou mais) regiões rodando plena capacidade, balanceando tráfego. |
- → snapshot periódico
- → replicação contínua
- → replicação contínua
- → replicação bidirecional
- → imagem pronta
- → tráfego normal
- → failover
- → reparte tráfego
- Compute
- Banco de dados
- Armazenamento
- Rede e entrega
Custo e RTO andam em direções opostas, e a questão sempre te dá um dos dois como restrição. A distinção que mais decide ponto: Pilot Light PROVISIONA na falha, Warm Standby ESCALA — por isso o RTO do segundo é minutos e não dezenas de minutos.
- Backup & Restore — o mais barato. Só snapshot no S3, com replicação entre regiões. Nada de compute do outro lado. Na falha você provisiona tudo do zero e restaura: horas, às vezes dias. Custo quase zero. Serve para dado que a empresa tolera perder um dia.
- Pilot Light — o dado acordado, o compute dormindo. Réplica do banco ligada e recebendo replicação; servidor de aplicação desligado, mas com AMI e template prontos. Na falha você sobe o compute e aponta o DNS. Custo baixo porque compute é o que mais custa.
- Warm Standby — já está rodando, só é pequeno. A diferença em relação ao Pilot Light é esta: aqui a stack está ATIVA, com capacidade reduzida. Na falha você escala, não provisiona — o que corta o RTO para minutos. É a distinção que o exame cobra mais.
- Multi-Site — as duas regiões servem tráfego. Stack completa e ativa nas duas pontas, com Global Table ou replicação bidirecional. RPO e RTO próximos de zero, e o dobro do custo de infraestrutura. Só se justifica quando o minuto parado custa mais que a segunda região.
- Route 53 é quem executa o failover. Em todas as estratégias acima, é o health check do Route 53 que detecta a queda e redireciona. Sem ele, você tem a região secundária de pé e ninguém sendo mandado para lá.
Backup & Restore — simples e barato
Pilot Light — mínimo aquecido
Metáfora: chama mínima aguardando para acender o resto. Banco replicando em tempo real, AMIs prontas, mas sem instâncias rodando (exceto DB). Em caso de desastre, escalar compute layer rapidamente.
Warm Standby — stack reduzida ativa
Secondary região tem aplicação rodando com capacidade reduzida (ex: 20% da primary). Pode receber tráfego de teste constante (canary). Em failover, Route 53 muda DNS e ASG escala para capacidade total.
Multi-Site Active-Active — zero downtime
Duas regiões em capacidade plena, balanceando tráfego via Route 53 (latency/geo routing) ou Global Accelerator. Se uma cair, a outra absorve tudo. Exige data layer multi-master (DynamoDB Global Tables, Aurora Global com promotion rápida ou eventual consistency tolerada).
Trade-off crítico: Multi-Site é caro (2× infra) e introduz complexidade de consistência (conflict resolution em Global Tables, last-writer-wins). Use só quando RTO = segundos é requisito de negócio (financeiro crítico, trading, saúde).
O negócio aceita perder até 15 minutos de dado e precisa voltar ao ar em 1 hora. Qual estratégia de DR é a mais econômica que atende?
AWS Backup — o orquestrador
Route 53 — o DNS que faz failover
AWS Elastic Disaster Recovery (DRS)
DRS replica continuamente servers on-premises ou em outra cloud para EC2 dormente. Em failover, lança as instâncias replicadas. RPO em segundos, RTO em minutos. Custo baixo pois compute só roda em drill/failover.
Evolução do CloudEndure: DRS substituiu CloudEndure Disaster Recovery. É a ferramenta recomendada para DR de workloads x86 on-prem para AWS.
Cenários arquiteturais comuns
📋 Plataforma de saúde — nunca pode perder consulta marcada (RPO ~0) e tolera 2 minutos de downtime
Aurora Global RPO <1s. Multi-Site garante infra já provisionada. Route 53 com health check automatiza switch.
📋 Blog de conteúdo — tolera 24h de dados perdidos e 4h offline
Baixo custo, RPO/RTO folgados. Blog pode ser restaurado do snapshot.
📋 Data center on-prem com 50 VMs críticas, negócio quer migrar DR para AWS
DRS replica continuamente para EC2 dormente. Drill de failover sem impactar primary. Custo baixo até ativar.
Q&A estilo exame
❓ Como reduzir RTO em cenário Pilot Light que hoje leva 45min?
❓ AWS Backup vs snapshot nativo: quando escolher qual?
❓ Como testar DR sem impactar produção?
❓ Route 53 failover respondeu secondary mesmo com primary healthy. Por quê?
Perguntas frequentes
❓ Qual a diferença entre RPO e RTO?
❓ Como escolher entre as quatro estratégias de recuperação?
❓ Plano de recuperação sem teste vale algo?
Fixando
Qual é a diferença operacional entre Pilot Light e Warm Standby?
Um plano de DR documenta RTO de 30 minutos, mas nunca foi testado. O que o exame espera que você conclua?
Armadilhas: (1) Multi-AZ ≠ DR — é HA intra-region; (2) Backup não testado = backup não existe; (3) RPO não é frequência de backup, é “quanto pode perder”; (4) failover manual tem RTO enorme — automatize; (5) eventual consistency em Global Tables pode gerar dados divergentes em multi-site.
Take-aways: mapeie negócio → RPO/RTO → estratégia. Backup & Restore barato mas lento; Pilot Light e Warm Standby ótimo custo-benefício; Multi-Site para SLA crítico. Use AWS Backup centralizado, Route 53 health check para failover, e TESTE trimestralmente.
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…