Una empresa ejecuta una aplicación web global en instancias de Amazon EC2 detrás de un Application Load Balancer y almacena datos en Amazon Aurora. La empresa necesita una solución de recuperación ante desastres que pueda tolerar hasta 30 minutos de inactividad y una posible pérdida de datos. La solución de DR no necesita manejar la carga de producción cuando la infraestructura principal está en buen estado. ¿Qué debería implementar un arquitecto de soluciones?

La opción correcta es la que mejor se alinea con los requisitos de RTO (30 minutos de inactividad) y RPO (posible pérdida de datos) para recuperación ante desastres, utilizando un enfoque de "piloto frío" o "standby pasivo". Implementar la infraestructura según sea necesario y usar Route 53 para conmutación por error activo-pasivo significa que la infraestructura de la aplicación se lanza solo durante un desastre, lo que es rentable y cumple con el RTO. Crear una réplica de Aurora en una segunda región asegura la replicación de datos con una mínima pérdida (RPO). Las opciones incorrectas son: Alojar una implementación reducida con conmutación por error activo-activo es un enfoque de "standby caliente", más costoso y no necesario dado el RTO/RPO permitido. Replicar la infraestructura principal con conmutación por error activo-activo y restaurar Aurora desde una instantánea es un enfoque de "multisitio activo-activo" o "standby caliente" con un RPO más alto, no óptimo para los requisitos. Realizar copias de seguridad con AWS Backup y crear una nueva instancia principal de Aurora en la segunda región implica un RTO y RPO potencialmente más altos, ya que la infraestructura y la base de datos deben crearse desde cero, lo que podría exceder los 30 minutos.