Una aplicación web se ejecuta en una única AWS Region sobre microservicios alojados en AWS Fargate (Amazon ECS) y utiliza una instancia de Amazon RDS for MySQL para los datos. Route 53 gestiona el DNS. Una alarma de CloudWatch activa una regla de EventBridge cuando la aplicación falla. Diseñe una solución de recuperación de desastres que proporcione recuperación en una segunda Region y minimice el tiempo de recuperación. ¿Qué enfoque cumple el requisito?

La opción correcta establece un patrón de recuperación de desastres de "piloto cálido" o "activo-pasivo" con un RTO (objetivo de tiempo de recuperación) bajo. Al aprovisionar previamente el clúster de ECS y Fargate en la segunda región y mantener una réplica de lectura de RDS entre regiones, los recursos de la aplicación ya están en funcionamiento y los datos están casi sincronizados. Cuando ocurre un fallo, la Lambda puede promover rápidamente la réplica de lectura a una instancia principal y actualizar Route 53 para dirigir el tráfico, minimizando el tiempo de inactividad. Las opciones incorrectas no cumplen con el requisito de minimizar el tiempo de recuperación: La primera opción requiere que la Lambda cree y restaure una nueva instancia de RDS a partir de una instantánea en el momento del fallo, lo cual lleva más tiempo que promover una réplica de lectura existente. La segunda opción es aún más lenta, ya que la Lambda tiene que crear el clúster de ECS y Fargate, además de restaurar la base de datos. La cuarta opción introduce una conversión de datos a DynamoDB, lo cual es un proceso complejo y lento para una recuperación de desastres, y no es una solución típica para una base de datos relacional como MySQL.