AWS organiza disaster recovery em quatro camadas: de backup e restore a multi-site ativo-ativo

A AWS organiza suas opções de disaster recovery (DR) em um espectro de quatro estratégias, do mais barato e simples ao mais caro e resiliente, segundo o whitepaper Disaster Recovery of Workloads on AWS, parte da documentação do Well-Architected Framework. A escolha entre elas depende de quanto downtime (RTO) e quanta perda de dados (RPO) o negócio tolera, e isso é decisão de arquitetura, não só de operação.

Para quem desenha workloads em múltiplas contas e regiões, esse espectro vira régua de decisão em toda reunião de capacity e de orçamento: cada camada a mais de resiliência custa dinheiro rodando ocioso. O arquiteto de soluções e o engenheiro de SRE que respondem pelo plano de continuidade do workload são o público direto desse documento.

O espectro: da perda de uma AZ à perda de uma Região

Se o cenário de desastre é a perda de um data center físico (uma Availability Zone) em um workload já bem arquitetado e de alta disponibilidade, o backup and restore costuma bastar. Se o desastre considerado é a perda de uma Região inteira, ou se há exigência regulatória de recuperação multirregião, entram pilot light, warm standby ou multi-site active/active.

Backup and restore: a base de tudo

Nessa abordagem, dados, código e configuração são copiados para a Região de recuperação, mas a infraestrutura só é reconstruída no momento do failover. O whitepaper reforça: sem infraestrutura como código, reconstruir o ambiente na Região de DR vira um processo manual e lento, capaz de estourar o RTO por conta própria.

Para backup com ponto de recuperação, a lista de serviços é ampla: snapshot de Amazon EBS, backup de Amazon DynamoDB, snapshot de Amazon RDS e Amazon Aurora, backup de Amazon EFS via AWS Backup, e snapshots de Amazon Redshift, Neptune, DocumentDB e das variantes de Amazon FSx. Para Amazon S3, o caminho é Cross-Region Replication (CRR) combinada com versionamento, para escolher o ponto de restauração.

O AWS Backup centraliza agendamento e monitoramento desses backups, inclusive com cópia entre contas e Regiões, o que protege contra cenários como comprometimento de credenciais. Um detalhe que passa despercebido: restaurar um backup é operação de control plane, então o whitepaper recomenda automatizar a restauração periódica via SDK, Amazon SNS e AWS Lambda, em vez de deixar essa etapa só para o momento do desastre. O objetivo é já ter um datastore operável de um backup recente, mesmo que a API de restauração fique indisponível na hora.

Um cuidado prático: ao usar replicação do S3 para a Região de DR, uma exclusão no bucket de origem gera um delete marker só na origem. É esse comportamento, e não um acidente de configuração, que protege a cópia na Região de DR contra uma exclusão maliciosa na Região primária.

Pilot light: núcleo sempre ligado, capacidade desligada

No pilot light, bancos de dados e armazenamento de objetos ficam sempre ativos na Região de DR, replicando dados continuamente; servidores de aplicação ficam com código e configuração prontos, mas desligados. A recomendação da AWS para "desligado" é literal: não manter o recurso provisionado, e sim ter pronta a automação que o sobe quando precisar.

Para replicação contínua de baixo RPO, o whitepaper lista Amazon S3 Replication, read replicas de Amazon RDS, Aurora Global Database, DynamoDB Global Tables, clusters globais de Amazon DocumentDB e o Global Datastore do Amazon ElastiCache (Redis OSS). O Aurora Global Database se destaca: replica para a Região secundária em menos de um segundo e permite promover uma Região secundária para leitura/escrita em menos de um minuto, mesmo numa interrupção regional completa, porque usa infraestrutura dedicada à replicação, sem competir com a capacidade que atende a aplicação.

Para reconstruir a infraestrutura na Região de DR em escala reduzida, o padrão é usar pseudo-parâmetros do CloudFormation para aplicar lógica condicional no template: a mesma definição de infraestrutura gera uma versão completa na Região primária e uma versão enxuta na Região de DR. AMIs golden, mantidas por um pipeline de Image Builder e copiadas entre Regiões, garantem que a imagem usada para escalar na hora do failover já tem tudo que o workload precisa.

Para quem roda workloads legados hospedados em EC2 (não em RDS), on-premises ou em outra nuvem, o AWS Elastic Disaster Recovery (DRS) implementa pilot light de forma gerenciada: replica em nível de bloco para uma VPC de staging na AWS e, no failover, cria automaticamente um deployment em escala real na VPC de destino.

Warm standby: a cópia fica ligada, só reduzida

O warm standby estende o pilot light mantendo uma cópia completa, porém reduzida, do ambiente de produção sempre ativa na Região de DR. A diferença prática é o tempo de recuperação: como o workload já está rodando, mesmo que em escala menor, o failover vira um problema de escalar (Auto Scaling) e redirecionar tráfego, não de subir infraestrutura do zero. Isso também facilita testar o failover com regularidade, algo que o pilot light dificulta por ter componentes desligados.

Failover de tráfego: prefira operação de data plane

Um ponto técnico que atravessa pilot light e warm standby é como redirecionar tráfego no failover. O whitepaper recomenda usar operações de data plane, que têm metas de disponibilidade mais altas que as de control plane. Com Amazon Route 53, health checks acionam failover automático de DNS, uma operação de data plane confiável; para failover manual controlado, o AWS Application Recovery Controller (ARC) cria health checks que funcionam como interruptores operados via AWS CLI ou SDK. Já trocar pesos de uma weighted routing policy no Route 53 é operação de control plane, e por isso menos resiliente.

O AWS Global Accelerator oferece caminho equivalente via IP anycast, com roteamento automático por health check e menor latência por usar o backbone da AWS. O Amazon CloudFront, por sua vez, faz failover de origem por requisição: cada chamada que falha na origem primária é redirecionada à secundária, mas as próximas continuam tentando a primária.

O que fica em aberto

O whitepaper situa o multi-site active/active como o topo do espectro, com as duas (ou mais) Regiões servindo tráfego simultaneamente, mas não detalha sua arquitetura na seção disponível aqui, o que é material para outro artigo. Para o arquiteto de soluções, o recorte prático é: comece pela estratégia mínima que atende o RTO/RPO do negócio, documente o trade-off de custo (pilar Cost Optimization) contra o de confiabilidade (pilar Reliability), e use o AWS Resilience Hub para validar continuamente se a arquitetura escolhida realmente bate a meta na prática, não só no papel.

Fonte: AWS Whitepaper — Disaster Recovery of Workloads