Una empresa ejecuta una aplicación web de tres niveles on-premises: frontend Apache, capa intermedia monolítica Java y almacenamiento PostgreSQL. Una promoción reciente sobrecargó todos los niveles, la aplicación falló y la base de datos alcanzó los límites de capacidad de lectura. Se planean varias promociones. Debe diseñar una migración a AWS que maximice la escalabilidad y minimice el esfuerzo operativo. ¿Cuáles tres pasos logran esto? (Elija tres).

La refactorización del frontend para servir activos estáticos desde S3 y usar CloudFront mejora la escalabilidad y el rendimiento al descargar el Apache y distribuir el contenido globalmente, reduciendo la carga en el servidor de aplicaciones. Reubicar la aplicación Java en Elastic Beanstalk con auto scaling automatiza la escalabilidad y la gestión operativa para la capa intermedia. Migrar PostgreSQL a Amazon Aurora PostgreSQL con AWS DMS y usar Aurora Auto Scaling para réplicas de lectura maximiza la escalabilidad de lectura y la disponibilidad de la base de datos, abordando los límites de capacidad experimentados. Las opciones incorrectas son: Reubicar Apache en EC2 con EFS para activos estáticos es menos escalable y más complejo operativamente que S3/CloudFront para activos estáticos. Refactorizar la aplicación Java a Docker en Fargate es una opción válida para la capa intermedia, pero Elastic Beanstalk ofrece una solución más rápida y con menor esfuerzo operativo para una aplicación monolítica existente, ya que automatiza el despliegue y la escalabilidad sin necesidad de gestionar contenedores directamente. Reubicar la base de datos en una instancia EC2 solo aumenta los recursos de forma vertical y no resuelve los problemas de escalabilidad de lectura ni de alta disponibilidad de forma tan efectiva como Aurora.