Uma aplicação web stateful crítica é executada em duas instâncias EC2 Linux atrás de um ALB com um banco de dados RDS para MySQL. O DNS está no Route 53. Os objetivos de resiliência são: RPO da camada de aplicação de 2 minutos e RTO de 30 minutos; RPO da camada de banco de dados de 5 minutos e RTO de 30 minutos. A empresa não quer grandes mudanças de arquitetura e deseja latência ideal após o failover. Qual solução atende a esses objetivos?

A opção correta atende aos objetivos de RPO e RTO com latência otimizada. O AWS Elastic Disaster Recovery (DRS) replica continuamente os dados das instâncias EC2 para uma região de recuperação, permitindo um RPO de minutos e um RTO de 30 minutos, pois as instâncias podem ser lançadas rapidamente. Uma réplica de leitura entre regiões para o RDS, promovida a instância primária, atinge um RPO de 5 minutos e RTO de 30 minutos. O Global Accelerator roteia o tráfego para o ALB mais próximo, garantindo baixa latência após o failover. As outras opções são incorretas porque: Usar Amazon Data Lifecycle Manager para snapshots EBS ou AWS Backup para EC2 e RDS não atende ao RPO de 2 minutos para a camada de aplicação, pois a restauração de snapshots leva mais tempo. Colocar uma distribuição CloudFront na frente do ALB não é a melhor solução para failover de desastre entre regiões para uma aplicação stateful, e o Global Accelerator é mais adequado para otimização de latência em cenários de DR.