Una migración lift-and-shift dejó un único grupo de Auto Scaling donde cada instancia EC2 ejecuta componentes web, de base de datos y de caché de Redis, lo que provoca tiempos de respuesta variables e instancias sobrecargadas. La empresa quiere separar los componentes para mejorar la disponibilidad y el rendimiento. ¿Qué cambio de arquitectura satisfará este requisito?

La opción correcta desagrega la aplicación en componentes especializados, mejorando la disponibilidad y el rendimiento. Un Application Load Balancer (ALB) es ideal para aplicaciones web HTTP/HTTPS, distribuyendo el tráfico eficientemente. Amazon Aurora con Multi-AZ proporciona alta disponibilidad y escalabilidad para la base de datos. Amazon ElastiCache (Redis OSS) es un servicio gestionado de caché en memoria, diseñado para alto rendimiento y baja latencia, eliminando la sobrecarga de Redis en las instancias EC2. Las otras opciones son incorrectas porque: La primera opción usa un Network Load Balancer (NLB) para la aplicación web, que es más adecuado para tráfico de capa 4, y un ALB para Redis, lo cual es innecesario ya que ElastiCache es un servicio gestionado. La segunda opción usa un NLB para Redis en una sola AZ, lo que no proporciona alta disponibilidad. La tercera opción usa un NLB para la aplicación web y un grupo objetivo con destinos DNS apuntando al nombre de host de ElastiCache, lo cual es una configuración innecesaria y menos eficiente que usar ElastiCache directamente.