Una empresa opera una aplicación web en una única instancia EC2 que se ralentiza en los momentos de mayor tráfico cuando la utilización de la CPU supera el 95%. Un script user-data instala paquetes personalizados en la instancia al iniciar, lo que hace que el inicio de la instancia tarde varios minutos. La empresa creará un grupo de Auto Scaling utilizando una plantilla de lanzamiento, con tipos de instancia mixtos, capacidades de CPU variables y un límite de capacidad máxima. La empresa quiere reducir la latencia de la aplicación cuando se lanzan nuevas instancias durante los eventos de escalado. ¿Qué enfoque satisface este requisito?

La opción correcta es utilizar una política de escalado dinámico, habilitar warm pools y usar lifecycle hooks para ejecutar el script user-data. Las políticas de escalado dinámico reaccionan a los cambios de carga en tiempo real, lo cual es adecuado para picos de tráfico inesperados. Los warm pools mantienen un conjunto de instancias preinicializadas y listas para servir tráfico, eliminando el tiempo de inicio y la ejecución del script user-data durante un evento de escalado. Los lifecycle hooks permiten ejecutar acciones personalizadas (como el script user-data) antes de que una instancia se ponga en servicio, asegurando que esté completamente configurada y lista cuando se una al grupo. Las políticas de escalado predictivo (opciones A y C) son para cargas predecibles, no para picos repentinos. La opción A y C también sugieren una "política de mantenimiento de instancias" que no es un concepto estándar de AWS para este propósito. Establecer el tiempo de calentamiento en 0 segundos (opciones A y B) no resuelve el problema del script user-data ni el tiempo de inicio, solo indica a Auto Scaling que la instancia está lista inmediatamente, lo cual no es cierto en este escenario.