Uma empresa executa um aplicativo on-premises com um banco de dados MySQL. A empresa está migrando o aplicativo para a AWS para melhorar a elasticidade e a disponibilidade. O banco de dados de produção apresenta intensa atividade de leitura durante a operação normal. A cada 4 horas, a equipe de desenvolvimento extrai uma exportação completa do banco de dados de produção para popular um banco de dados de staging; durante essa exportação, os usuários experimentam latência inaceitável e a equipe de desenvolvimento não pode usar o staging até que a exportação seja concluída. Um arquiteto de soluções deve recomendar uma arquitetura de substituição que elimine a latência do aplicativo e permita que a equipe de desenvolvimento use o ambiente de staging sem atrasos. Qual solução atende a esses requisitos?

A opção correta é usar Amazon Aurora MySQL com Aurora Replicas Multi-AZ para produção e database cloning para o ambiente de staging. O Aurora MySQL oferece alta performance e escalabilidade de leitura com Aurora Replicas, eliminando a latência para usuários. O database cloning do Aurora permite criar uma cópia do banco de dados de produção quase instantaneamente e sem impacto na performance, resolvendo o problema da exportação demorada e da indisponibilidade do staging. As outras opções são incorretas porque: Usar mysqldump para backup e restauração ainda causaria latência na produção e atrasos no staging, como na situação atual. Usar Amazon RDS for MySQL com réplicas de leitura e a instância em standby para staging não é viável, pois a instância em standby é para recuperação de desastres e não pode ser usada para staging sem impactar a disponibilidade e a performance da produção.