Una empresa ejecuta una aplicación web de misión crítica en instancias de Amazon EC2 detrás de un Application Load Balancer en un grupo de Auto Scaling. La aplicación utiliza una base de datos Amazon Aurora PostgreSQL implementada en una única Availability Zone. La empresa desea alta disponibilidad con un tiempo de inactividad mínimo y una pérdida de datos mínima, y con el menor esfuerzo operativo. ¿Qué solución cumple estos requisitos?

La opción correcta cumple los requisitos de alta disponibilidad con mínimo tiempo de inactividad y pérdida de datos, y bajo esfuerzo operativo. Configurar el grupo de Auto Scaling en múltiples Zonas de Disponibilidad (AZ) distribuye las instancias EC2, asegurando que la aplicación siga funcionando si una AZ falla. Configurar la base de datos Aurora PostgreSQL como Multi-AZ crea una réplica en espera en otra AZ, permitiendo una conmutación por error automática y rápida con mínima pérdida de datos. Amazon RDS Proxy mejora la resiliencia de la aplicación al gestionar las conexiones a la base de datos, lo que reduce el impacto de las conmutaciones por error y simplifica el manejo de conexiones. Las otras opciones son incorrectas porque: Colocar instancias EC2 en diferentes regiones e implementar replicación entre regiones para Aurora es más complejo y costoso, y Route 53 no proporciona una conmutación por error tan rápida como Multi-AZ para la base de datos. Usar una sola AZ para el grupo de Auto Scaling y depender de instantáneas horarias para la recuperación de la base de datos resultaría en un tiempo de inactividad significativo y posible pérdida de datos. Configurar el grupo de Auto Scaling en múltiples regiones y usar S3 con Lambda para la persistencia de datos es una arquitectura más compleja y no es la solución más sencilla para la alta disponibilidad de una base de datos Aurora PostgreSQL.