RTO, RPO e níveis de DR

O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável entre a ocorrência de um desastre e a restauração do sistema à operação. Se seu RTO for de 4 horas, sua empresa poderá tolerar 4 horas de indisponibilidade. O objetivo de ponto de recuperação (RPO) é a quantidade máxima aceitável de perda de dados, medida em tempo — se seu RPO for de 1 hora, você deverá conseguir recuperar o sistema para um ponto de no máximo 1 hora antes do desastre. Ambas as métricas são definidas pelos requisitos do negócio, não por preferências técnicas.

A AWS define quatro estratégias principais de recuperação de desastres, ordenadas do menor custo/maior RTO ao maior custo/menor RTO: 1) Backup and Restore — a mais barata, com RTO de horas. 2) Pilot Light — núcleo mínimo sempre em execução, com RTO de minutos a horas. 3) Warm Standby — reduzida, mas funcional, com RTO de minutos. 4) Multi-Site Active-Active — a mais cara, com RTO próximo de zero. Sua escolha depende do custo empresarial da indisponibilidade em comparação com o custo da infraestrutura de DR.

Na estratégia Backup and Restore, você cria snapshots regularmente dos seus dados e os armazena em outro local (por exemplo, no S3 com replicação entre regiões). Em caso de desastre, você restaura os dados a partir do backup mais recente. Essa é a estratégia mais barata porque não mantém uma infraestrutura em espera em execução. A desvantagem é o RTO mais longo (horas para restaurar bancos de dados grandes a partir de snapshots) e o RPO mais alto (os dados criados desde o último backup são perdidos). O AWS Backup automatiza agendamentos de snapshots no EC2, RDS, EFS, DynamoDB e outros serviços.

A estratégia Pilot Light mantém os componentes essenciais do seu sistema em execução em uma região de DR, com capacidade mínima — como uma chama-piloto que pode rapidamente acender a chama completa. Normalmente, isso significa replicar continuamente o banco de dados para a região de DR e manter a infraestrutura básica de rede (VPC, sub-redes e grupos de segurança). Os servidores da aplicação NÃO estão em execução, mas podem ser iniciados rapidamente a partir de AMIs ou modelos de inicialização pré-criados. O RTO normalmente varia de 30 minutos a várias horas, dependendo da quantidade de trabalho manual necessária.

A estratégia Warm Standby executa uma cópia totalmente funcional e reduzida do seu ambiente de produção na região de DR. Diferentemente de Pilot Light, a camada da aplicação está em execução (talvez com 1 ou 2 instâncias em vez de 20), e o banco de dados é um banco de dados secundário do Aurora Global Database ou uma réplica de leitura do RDS. Durante o failover, você aumenta a escala do ambiente de DR para corresponder à capacidade de produção. O RTO normalmente é inferior a 15 minutos. Essa é a estratégia de DR mais comum para cargas de trabalho de criticidade média a alta.

Multi-Site Active-Active executa a capacidade total de produção em duas ou mais regiões simultaneamente. Todas as regiões atendem tráfego ativo, e os dados são replicados quase em tempo real (ou em um modelo multimestre). Não há atraso de failover — quando uma região falha, o Route 53 ou o Global Accelerator encaminha imediatamente todo o tráfego para as regiões íntegras restantes. Isso proporciona os menores RTO e RPO, mas também o maior custo, pois você paga pela capacidade total de produção em todas as regiões o tempo todo.

Seu RPO determina diretamente qual tecnologia de replicação você precisa. RPO = 0 exige replicação síncrona — nada é perdido. Um RPO em segundos exige replicação assíncrona quase em tempo real, como o Aurora Global Database (<1s de atraso). Um RPO em minutos permite replicação assíncrona com pequeno atraso (DynamoDB Streams, réplicas de leitura do RDS). Um RPO em horas pode ser alcançado com snapshots periódicos (agendamento horário do AWS Backup). Estabeleça claramente o requisito de RPO do seu negócio antes de escolher uma tecnologia.

As arquiteturas sem servidor (Lambda, DynamoDB e API Gateway) são naturalmente mais resilientes, mas ainda exigem planejamento de DR. As DynamoDB Global Tables fornecem operação ativa-ativa entre várias regiões para a camada do banco de dados. O Lambda pode ser implantado em uma segunda região a partir do mesmo pipeline de CI/CD. O API Gateway deve ser provisionado na região de DR. O principal risco é a divergência de configuração entre regiões — use o AWS CDK ou Terraform para implantar uma infraestrutura idêntica nas duas regiões a partir da mesma base de código.

Considere uma empresa com receita anual de US$ 10 milhões. Se a indisponibilidade custar US$ 1.000 por minuto, uma interrupção de 8 horas (RTO=8h) custará US$ 480.000. Um ambiente de espera ativa-passiva com RTO=15 minutos reduz a perda potencial para US$ 15.000 por incidente. Se o ambiente de espera custar US$ 5.000 por mês (US$ 60.000 por ano), ele só será economicamente viável se ocorrer mais de uma interrupção significativa por ano. Essa análise de justificativa de custos é exatamente o que o exame SAA-C03 solicita que você faça ao selecionar estratégias de DR.

Um plano de DR que nunca foi testado é apenas um documento. A AWS recomenda enfaticamente simulações regulares de DR: pratique os procedimentos de failover, meça o RTO e o RPO reais e identifique lacunas. Use o AWS Fault Injection Simulator (FIS) para simular a degradação regional de forma controlada. Documente guias operacionais com as etapas de failover para que, sob o estresse de um incidente real, a equipe de plantão siga um procedimento claro e testado em vez de improvisar.

Muitos setores têm requisitos regulatórios para DR. O PCI DSS exige planos de DR documentados e testes. A HIPAA exige procedimentos de backup de dados e recuperação de desastres. O SOC 2 avalia controles de disponibilidade, incluindo DR. Use o AWS Config e o gerenciador de auditoria da AWS para avaliar e documentar continuamente se seus recursos de DR (backups, réplicas e verificações de integridade) estão configurados corretamente. Isso fornece evidências para auditorias de conformidade sem coleta manual.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: RTO é o tempo máximo de inatividade aceitável, e RPO é a perda máxima de dados aceitável, as quatro camadas de DR equilibram o custo e a velocidade de recuperação e seu requisito de RPO determina qual tecnologia de replicação usar. Sempre teste seu plano de DR para validar o RTO e o RPO reais. A seguir, exploraremos detalhadamente a estratégia de Backup e Restore.