Disaster Recovery (DR) é o conjunto de estratégias para recuperar sistemas e dados após uma falha severa — desde a perda de uma única Availability Zone até a indisponibilidade de uma região inteira da AWS. A decisão de qual estratégia usar não é técnica isolada: é fundamentalmente uma decisão de negócio, equilibrando quanto tempo de indisponibilidade e quanta perda de dados são toleráveis contra quanto custa reduzir esses números.

🎯 Para a certificação

Questões sobre DR testam se você sabe traduzir requisitos de negócio em RTO e RPO numéricos, se consegue mapear esses números para uma das quatro estratégias clássicas (Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active-Active), entende a diferença entre proteção Multi-AZ e proteção Multi-Region, e sabe que um plano de DR não testado não é, na prática, um plano de DR confiável.

---

Resumo

Pense nas quatro estratégias de DR como pontos numa escada de custo vs. velocidade de recuperação — não existe "a melhor estratégia" no absoluto, existe a estratégia certa para o RTO e RPO que o negócio realmente precisa e está disposto a pagar.

• RTO (Recovery Time Objective): quanto tempo a aplicação pode ficar indisponível até ser restaurada — mede tempo de recuperação.
• RPO (Recovery Point Objective): quantos dados a organização pode se dar ao luxo de perder, medido em tempo — mede o "quão antigo" pode ser o último backup/estado recuperável.
• Backup & Restore: mais barato, RTO e RPO mais altos (horas).
• Pilot Light: componentes essenciais (tipicamente o banco de dados) já replicados e prontos; o resto é ligado sob demanda.
• Warm Standby: uma versão reduzida, mas funcional, já rodando o tempo todo em outra região; escala quando o desastre acontece.
• Multi-Site Active-Active: produção completa duplicada e ativa simultaneamente em múltiplas regiões, RTO/RPO próximos de zero, custo mais alto.

---

1. RTO e RPO — a base de qualquer decisão de DR

Antes de escolher uma estratégia, é preciso traduzir requisitos de negócio em dois números concretos — essa tradução é, na prática, o que a prova mais cobra sobre o tema.

• RTO (Recovery Time Objective): a pergunta é "quanto tempo depois do desastre a aplicação precisa estar de volta no ar?". Um RTO de 4 horas significa que a organização aceita ficar até 4 horas sem o sistema funcionando.
• RPO (Recovery Point Objective): a pergunta é "quanto tempo de dados a organização pode se dar ao luxo de perder?". Um RPO de 15 minutos significa que, na pior das hipóteses, os últimos 15 minutos de transações antes do desastre podem não estar recuperáveis.

Explicação didática: imagine uma linha do tempo com o momento exato do desastre marcado. O RPO olha para trás nessa linha — até onde no passado você consegue voltar sem perder dados além do tolerável. O RTO olha para frente — quanto tempo depois do desastre até o sistema estar operacional de novo. São eixos independentes: é perfeitamente possível ter um RPO baixo (pouca perda de dados, graças a backups frequentes) combinado com um RTO alto (demora para religar tudo), ou vice-versa — a estratégia escolhida precisa atender os dois simultaneamente.

💡 Para a prova: se o enunciado dá números específicos de RTO/RPO (ex: "RTO de 5 minutos, RPO de 30 segundos"), a resposta quase sempre é sobre escolher a estratégia mais barata que ainda atende ambos os números — não a mais cara "para garantir", nem a mais barata que não atende o requisito.

---

2. As quatro estratégias de DR

2.1 Backup & Restore

A estratégia mais simples e barata: dados são copiados regularmente (snapshots de EBS/RDS, backups de outros serviços) e armazenados de forma durável — tipicamente no S3, possivelmente replicados para outra região via Cross-Region Replication. Em caso de desastre, a infraestrutura inteira é recriada do zero na região de recuperação a partir desses backups.

• RTO: alto (horas) — envolve provisionar infraestrutura nova e restaurar dados.
• RPO: depende da frequência dos backups (tipicamente horas).
• Custo: o mais baixo entre as quatro estratégias — você paga essencialmente só pelo armazenamento dos backups, sem manter infraestrutura de recuperação ativa.

2.2 Pilot Light

O nome vem da analogia com um aquecedor a gás: a "chama piloto" fica sempre acesa (um componente essencial, tipicamente o banco de dados, mantido replicado e atualizado continuamente em outra região), mas o restante do sistema (servidores de aplicação, load balancers) fica desligado ou não provisionado, sendo ligado apenas quando o desastre realmente acontece.

• RTO: menor que Backup & Restore (minutos a algumas dezenas de minutos) — porque o dado mais crítico e demorado de restaurar (o banco) já está pronto; só falta subir a camada de aplicação.
• RPO: baixo — como o banco replica continuamente, a perda de dados tende a ser mínima.
• Custo: moderado — menor que manter tudo rodando, mas maior que Backup & Restore puro, já que a replicação contínua do banco tem custo constante.

2.3 Warm Standby

Uma versão reduzida, mas totalmente funcional, do ambiente de produção já roda continuamente na região de recuperação — tipicamente com uma capacidade menor (menos instâncias, tipos de instância menores) do que a produção real. Quando o desastre acontece, essa versão reduzida precisa apenas escalar (ex: via Auto Scaling Group aumentando capacidade), não ser criada do zero.

• RTO: baixo (minutos) — o sistema já está no ar, só precisa de mais capacidade.
• RPO: baixo — dados já replicados continuamente.
• Custo: mais alto que Pilot Light, porque envolve manter instâncias de aplicação rodando o tempo todo, mesmo que em escala reduzida.

2.4 Multi-Site Active-Active

O ambiente de produção roda simultaneamente, em capacidade total, em múltiplas regiões, com tráfego sendo distribuído entre elas (tipicamente via Route 53 com política de roteamento Latency ou Weighted). Se uma região falhar, o tráfego simplesmente continua sendo servido pelas regiões remanescentes.

• RTO: próximo de zero — não há "recuperação" no sentido tradicional, porque não existe um momento de indisponibilidade total a ser corrigido.
• RPO: próximo de zero, dependendo da estratégia de replicação de dados entre regiões (geralmente o componente mais desafiador tecnicamente dessa estratégia).
• Custo: o mais alto das quatro — envolve manter capacidade de produção completa duplicada, ativa o tempo todo, em múltiplas regiões.

2.5 Resumo comparativo

💡 Para a prova: a pegadinha mais comum é o enunciado dar um RTO/RPO generoso (ex: horas) e a alternativa "certa" tentar induzir você a escolher uma estratégia mais cara que o necessário (ex: Active-Active quando Backup & Restore já atenderia). A resposta correta em DR quase sempre é a estratégia mais barata que ainda cumpre o RTO/RPO exigido — superdimensionar não é a resposta certa, mesmo parecendo "mais seguro".

---

3. Multi-AZ vs Multi-Region — dois problemas diferentes

Esse é outro par de conceitos que a prova gosta de testar em contraste direto — e vale reforçar aqui porque frequentemente aparece misturado com DR.

• Multi-AZ: protege contra a falha de uma única Availability Zone dentro da mesma região (ex: RDS Multi-AZ, ver o conteúdo dedicado a RDS). Não é, por si só, uma estratégia de DR contra falha regional — é uma camada de alta disponibilidade dentro da região.
• Multi-Region: protege contra a indisponibilidade de uma região inteira — um cenário muito mais raro, mas que exige as estratégias descritas na seção 2 (Backup & Restore, Pilot Light, Warm Standby ou Active-Active), já que Multi-AZ sozinho não ajuda em nada se a região inteira estiver fora do ar.

💡 Para a prova: se o cenário menciona "proteção contra perda de uma AZ", a resposta é sobre arquitetura Multi-AZ dentro da região (ex: RDS Multi-AZ, ASG distribuído em múltiplas AZs). Se menciona "falha da região inteira" ou "outage regional", a resposta envolve uma das quatro estratégias de DR Multi-Region da seção 2 — os dois problemas não se resolvem com a mesma ferramenta.

---

4. Serviços AWS que apoiam cada camada de uma estratégia de DR

• Dados: S3 com Cross-Region Replication, RDS com snapshots cross-region ou Read Replicas cross-region, DynamoDB Global Tables (replicação multi-região ativa-ativa nativa para NoSQL).
• Infraestrutura como código: CloudFormation ou Terraform para recriar rapidamente a infraestrutura de aplicação na região de recuperação — essencial para Backup & Restore e Pilot Light, onde parte da infraestrutura não existe até o momento do desastre.
• Roteamento: Route 53 com Failover routing (para direcionar tráfego para a região de recuperação quando a região primária falha) ou Latency/Weighted routing (para Active-Active, distribuindo tráfego entre regiões ativas simultaneamente).
• Monitoramento e automação: CloudWatch Alarms disparando automações (ex: via Lambda ou Systems Manager) que executam parte do processo de failover, reduzindo o RTO ao eliminar etapas manuais.

💡 Para a prova: DynamoDB Global Tables é um caso interessante — ele já oferece replicação ativa-ativa nativa entre regiões para a camada de dados, o que pode ser a peça que falta para viabilizar uma estratégia Active-Active mesmo quando outras partes do sistema (aplicação) ainda precisam de uma arquitetura tradicional de failover.

---

5. Testes de DR e runbooks

Um plano de DR que nunca foi testado é, na prática, uma suposição, não uma garantia. Elementos importantes:

• Runbooks: documentação passo a passo (idealmente parcialmente ou totalmente automatizada) de exatamente o que fazer durante um failover — quem aciona o quê, em que ordem, com quais comandos/scripts.
• Game days / testes de failover controlados: exercícios periódicos (não apenas na teoria) que efetivamente executam parte ou todo o processo de failover, num ambiente controlado, para validar que o RTO/RPO teóricos correspondem à realidade.
• Validação de restaurações: testar regularmente que os backups realmente restauram corretamente — um backup corrompido ou incompleto só é descoberto tarde demais se nunca for restaurado como teste.

💡 Para a prova: se o cenário descreve uma organização que "tem um plano de DR documentado, mas nunca testado", isso costuma ser apresentado como uma falha real de processo — a resposta correta geralmente envolve implementar testes periódicos (game days), não apenas confiar na documentação existente.

---

6. Boas práticas

• Mapeie RTO e RPO por aplicação — nem todo sistema precisa da mesma estratégia; sistemas críticos podem justificar Warm Standby ou Active-Active, enquanto sistemas internos de menor criticidade podem se contentar com Backup & Restore.
• Escolha a estratégia mais barata que ainda atende o RTO/RPO exigido — não superdimensione por precaução, isso é custo desnecessário.
• Automatize o processo de recovery com Infrastructure as Code e runbooks, reduzindo dependência de execução manual sob pressão durante um incidente real.
• Mantenha backups off-site (em outra região) e valide restaurações regularmente, não apenas na criação.
• Combine Multi-AZ (para falhas comuns, dentro da região) com uma estratégia de DR Multi-Region (para o cenário raro, mas possível, de falha regional) — são camadas complementares, não substitutas uma da outra.
• Teste failovers periodicamente através de game days, validando que o RTO/RPO real corresponde ao planejado.

---

7. Como cai na certificação

• Cenário "RTO de horas, RPO de horas, orçamento limitado" → Backup & Restore.
• Cenário "banco de dados precisa estar pronto rapidamente, mas o restante da aplicação pode ser provisionado sob demanda" → Pilot Light.
• Cenário "RTO de minutos, sistema reduzido já rodando, escalando sob demanda" → Warm Standby.
• Cenário "RTO/RPO próximos de zero, tráfego distribuído ativamente entre regiões" → Multi-Site Active-Active.
• Cenário "proteção contra perda de uma única AZ" → arquitetura Multi-AZ dentro da região, não uma das quatro estratégias de DR Multi-Region.
• Cenário "proteção contra falha da região inteira" → uma das quatro estratégias de DR Multi-Region, dependendo do RTO/RPO exigido.
• Cenário "réplica NoSQL ativa-ativa nativa entre regiões" → DynamoDB Global Tables.
• Cenário "plano de DR documentado mas nunca testado" → implementar testes periódicos (game days) e validação de restaurações.
• Cenário "enunciado dá RTO/RPO generosos, mas a alternativa tenta induzir a uma estratégia mais cara que o necessário" → escolher a estratégia mais barata que ainda atende os números dados.

---

8. Exercícios práticos

1. Escolha e justifique uma estratégia de DR para uma aplicação crítica com RTO menor que 5 minutos e RPO menor que 30 segundos.
2. Explique como implementar uma estratégia Pilot Light para um serviço baseado em RDS, especificando o que fica replicado continuamente e o que é provisionado apenas no momento do desastre.
3. Liste os passos conceituais para testar um failover regional através de um game day, sem impactar o ambiente de produção real.
4. Avalie os trade-offs de custo entre Warm Standby e Multi-Site Active-Active, e descreva um cenário de negócio que justificaria cada uma.
5. Explique por que Multi-AZ, isoladamente, não é suficiente como estratégia de proteção contra uma falha de região inteira.

---

9. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Laboratório Prático

Objetivo: implementar uma estratégia de Pilot Light simplificada usando RDS com snapshot cross-region, e simular um exercício de failover manual documentado como runbook.

Pré-requisitos: conta AWS com permissão para RDS, EC2 e Route 53, em duas regiões diferentes.

Tempo estimado: 40 minutos

Possíveis custos: moderado — envolve recursos em duas regiões; recomenda-se deletar tudo ao final.

Passos:

1. Na região primária, crie uma instância RDS simples com alguns dados de teste.
2. Configure snapshots automáticos e copie um snapshot manualmente para a região de recuperação (simulando replicação cross-region).
3. Na região de recuperação, não crie a instância de aplicação ainda — apenas prepare um template (ex: uma CloudFormation stack ou um script simples) capaz de provisionar rapidamente a infraestrutura de aplicação quando necessário.
4. Escreva um runbook simples (passo a passo em texto) descrevendo exatamente o que fazer em caso de desastre: restaurar o snapshot do RDS na região de recuperação, executar o template de infraestrutura de aplicação, e atualizar o registro Failover do Route 53 para apontar para a nova região.
5. Simule o desastre: restaure o snapshot do RDS na região de recuperação, criando uma nova instância a partir dele.
6. Execute o template de infraestrutura de aplicação preparado no passo 3.
7. Cronometre o tempo total desde o início da simulação até o sistema estar operacional na região de recuperação, e compare com o RTO que essa estratégia teoricamente deveria entregar.

Resultado esperado: você experimenta na prática a diferença entre ter apenas backups (Backup & Restore) e ter o componente crítico (banco de dados) pronto para restauração rápida (Pilot Light), além de reforçar a importância de um runbook testado, não apenas documentado.

Limpeza dos recursos: delete as instâncias RDS e de aplicação criadas em ambas as regiões, os snapshots de teste, e reverta qualquer alteração no Route 53.

---

Referências:

• AWS Whitepaper — Disaster Recovery of Workloads on AWS: https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html
• AWS Architecture Center — Disaster Recovery: https://aws.amazon.com/architecture/disaster-recovery/
• DynamoDB Global Tables: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html
• Route 53 Failover routing: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html