🆘

Disaster Recovery: RPO, RTO e 4 Estratégias

⏱ 13 min de leitura·+70 XP

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.

📘 Resilient· 26%

📘 Cost-Optimized· 20%

Definições que caem no exame

RPO (Recovery Point Objective)Quanto de DADO você pode perder. Se RPO = 1h, backup deve rodar pelo menos a cada hora.

RTO (Recovery Time Objective)Quanto TEMPO máximo para restaurar operação. Se RTO = 30min, restore e failover devem completar nesse prazo.

BCP (Business Continuity Plan)Plano amplo incluindo processos humanos, comunicação com clientes. DR é a parte técnica.

MTBF / MTTRMean Time Between Failures / Mean Time To Recover — métricas operacionais.

🗺️ Linha do tempo do desastre

  t = -RPO     t = 0 (desastre)        t = +RTO
     │             │                       │
     ▼             ▼                       ▼
  Último       Sistema               Sistema
  backup       cai                   restaurado
  válido
    │←─── dados perdidos ────→│←── tempo parado ──→│
        (max aceitável = RPO)   (max aceitável = RTO)

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.

🗺️ Comparação visual: infraestrutura rodando na secondary

Backup & Restore:   Secondary região = vazia. Só tem snapshots.
                    └── "construir tudo do zero"

Pilot Light:        Secondary = DB replicando + AMIs prontas
                    └── "fogo piloto aceso; acender resto rápido"

Warm Standby:       Secondary = aplicação rodando em tamanho 20%
                    └── "pronto mas aquecido; só scale up"

Multi-Site:         Secondary = capacidade total, recebendo tráfego
                    └── "nenhum 'secondary' — duas primárias"

Backup & Restore — simples e barato

O que replicarSnapshots EBS, RDS automated backups, DynamoDB PITR ou backups, S3 com Replication ou Versioning + Cross-Region.

ComoAWS Backup com cross-region copy. Data Lifecycle Manager para EBS. S3 CRR. Aurora automated backups replicam cross-region.

TestarExercício trimestral: restaurar snapshot, validar, derrubar. Sem teste, RTO "real" pode virar dias.

Usado quandoDados não-críticos; negócios que toleram horas fora; dev/staging.

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.

Data layerRDS cross-region read replica; Aurora Global Database; DynamoDB Global Tables.

ComputeAMIs atualizadas + Launch Templates prontos + ASG com desired=0.

NetworkVPC + subnets + SGs já provisionados via IaC (CloudFormation/CDK).

TriggerRoute 53 health check + failover record OU operação manual pela runbook.

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.

VantagemRTO de minutos, confiança alta (stack já testada).

Trade-offCusto permanente ~25% da primary.

PadrãoALB + ASG + RDS read replica + S3 CRR + Route 53 failover com TTL baixo.

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).

AWS Backup — o orquestrador

Backup PlansRegras declarativas (frequência, retention, lifecycle para cold storage).

Recursos cobertosEBS, RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, VMware, EC2 (completo), S3, Neptune, DocumentDB, Redshift.

Backup VaultRepositório lógico com policies + encryption KMS.

Vault LockWORM para backups — compliance SEC 17a-4. Ninguém, nem root, pode deletar antes do prazo.

Cross-regionCopy rule no plan. Backup original + réplica em outra região.

Cross-accountDelegated account em Organizations recebe cópias centralmente. Isola backups de ataques à conta de produção.

Backup Audit ManagerRelatórios de compliance (quem está protegido, que não está).

Route 53 — o DNS que faz failover

Health ChecksMonitora endpoint (TCP/HTTP/HTTPS). Pode usar CloudWatch alarm como fonte.

Failover routingPrimary + secondary records. Se primary unhealthy, responde secondary.

TTL baixoDiminua TTL antes do maintenance para acelerar propagação do failover (60s comum).

Multi-value answerRetorna até 8 IPs saudáveis. Client-side load balance rudimentar.

Geolocation / LatencyRoteia para região mais próxima / menor latência. Fallback se regional unhealthy.

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 Database + Multi-Site Active-Passive com Route 53 failover

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

✓ Backup & Restore com AWS Backup + cross-region copy

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

✓ AWS Elastic Disaster Recovery (DRS)

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?

Automatize o playbook com CloudFormation/CDK + SSM Automation. Pre-warm AMIs (copiadas ao invés de construídas). Reduza Route 53 TTL. Mantenha ASG com min > 0 (convertendo para Warm Standby).

❓ AWS Backup vs snapshot nativo: quando escolher qual?

Para orquestração multi-serviço + compliance + cross-region/cross-account, AWS Backup ganha. Para um volume EBS isolado, Data Lifecycle Manager (snapshots nativos) é suficiente e mais simples.

❓ Como testar DR sem impactar produção?

Game day: failover planejado em janela fora de pico, medindo RTO real. AWS Backup permite restore em vault separado. DRS tem recovery drills com ambiente isolado.

❓ Route 53 failover respondeu secondary mesmo com primary healthy. Por quê?

Health check pode ter falso-positivo (timeout baixo, network hiccup). Aumente threshold de failures e o intervalo. Check de HTTPS em endpoint privado pode falhar se sem rota pública.

⚠️

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.

🧩

Quiz rápido

3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito