Una aplicación web con estado crítica se ejecuta en dos instancias EC2 con Linux detrás de un ALB con una base de datos RDS para MySQL. El DNS está en Route 53. Los objetivos de resiliencia son: RPO de la capa de aplicación de 2 minutos y RTO de 30 minutos; RPO de la capa de base de datos de 5 minutos y RTO de 30 minutos. La empresa no quiere cambios arquitectónicos importantes y desea una latencia óptima después de la conmutación por error. ¿Qué solución cumple estos objetivos?

La opción correcta cumple con los RPO y RTO especificados sin cambios arquitectónicos importantes. AWS Elastic Disaster Recovery (DRS) replica las instancias EC2 a nivel de bloque, permitiendo una recuperación rápida con un RPO bajo (minutos) y un RTO bajo (minutos a horas), satisfaciendo los requisitos de la capa de aplicación. Una réplica de lectura de RDS entre regiones se puede promover a instancia principal en caso de desastre, logrando un RPO bajo (minutos) y un RTO bajo (minutos) para la base de datos. Global Accelerator dirige el tráfico al ALB más cercano y saludable, garantizando una latencia óptima y una conmutación por error rápida entre regiones. Las opciones incorrectas fallan en los RPO/RTO o introducen cambios arquitectónicos no deseados. Amazon Data Lifecycle Manager y AWS Backup para EC2 generalmente tienen RTO más altos que DRS. Las copias de seguridad de RDS con replicación pueden tener un RPO más alto que una réplica de lectura. CloudFront no es un mecanismo de conmutación por error entre regiones para ALB, y la opción que lo menciona no incluye un Global Accelerator para la conmutación por error de ALB.