APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Disponibilidade, leitura escalável e recuperação de dados são capacidades diferentes. Uma instância RDS Multi-AZ com um único standby usa esse standby para disponibilidade, sem o oferecer como destino de leitura. Read replicas assíncronas podem atrasar-se; leituras que exigem estado recente precisam de um caminho compatível. Num Auto Scaling group, o sinal EC2 não substitui a saúde da aplicação no ALB. A integração de health checks ELB deve estar configurada quando esse estado deve orientar substituição. A escala também respeita limites: atingir o máximo do grupo impede crescimento adicional sem revisão, mesmo que uma política continue a pedir capacidade.
Aplicação guiada
Um restauro RDS para um ponto no tempo cria outra instância. Planeia configuração, endpoint, acesso e validação antes de redirecionar consumidores. O relógio de recuperação deve incluir o serviço utilizável, não apenas o recurso criado. Num ensaio, indisponibilidade às 10:00 e validação às 10:35 dá 35 minutos; recuperar dados até 09:50 deixa dez minutos de intervalo. Com RTO 45 e RPO 5, apenas RTO é cumprido. Ensaios AWS Backup precisam de validação e limpeza controlada. Em S3, distingue delete marker de eliminação de uma versão: se versões anteriores existem, identifica a cópia correta e recupera com autorização, preservando requisitos de retenção.
O relatório de DR deve separar início da interrupção, infraestrutura pronta, serviço validado e ponto de dados recuperado, com resultados dos controlos funcionais.
Armadilhas comuns
Backup como prova de restauro; standby como réplica de leitura; ALB unhealthy como substituição automática sem integração; RTO como RPO.
Tópicos relacionados: Stacks, imagens e deployments · Automação operacional controlada
Demonstra o resultado do serviço e o estado dos dados em relação aos objetivos acordados.
Referência: AWS Backup restore testing · SOA-C03; exam guide 1.1