Uma aplicação é executada em us-east-1 em três Zonas de Disponibilidade, atrás de um Application Load Balancer, e seu banco de dados MySQL é executado em uma instância do Amazon EC2. A empresa exige um design de recuperação de desastres entre regiões com um RTO (Recovery Time Objective) inferior a 5 minutos e um RPO (Recovery Point Objective) inferior a 1 minuto. Servidores de aplicação foram implantados em us-west-2 e verificações de saúde do Route 53 com failover de DNS para us-west-2 estão configuradas. Que ação adicional o arquiteto de soluções deve tomar para atender aos objetivos de recuperação?

A opção correta é migrar para um banco de dados global do Amazon Aurora. O Amazon Aurora Global Database foi projetado para recuperação de desastres entre regiões com um RTO de menos de 1 minuto e um RPO de menos de 5 segundos, superando os requisitos do problema (RTO < 5 min, RPO < 1 min). Ele replica dados assincronamente para uma região secundária com latência mínima. Migrar para uma instância do Amazon RDS para MySQL com uma réplica de leitura entre regiões seria uma opção, mas o Aurora Global Database oferece um RTO e RPO significativamente melhores devido à sua arquitetura otimizada para replicação global e failover rápido. Migrar para uma instância do Amazon RDS para MySQL com implantação Multi-AZ não atende aos requisitos de recuperação de desastres entre regiões, pois o Multi-AZ oferece resiliência dentro de uma única região. Criar um banco de dados MySQL em standby em uma instância do Amazon EC2 em us-west-2 exigiria gerenciamento manual da replicação e failover, o que provavelmente não atenderia ao RTO e RPO exigidos de forma consistente e confiável.