Un ingeniero de SysOps está solucionando problemas de rendimiento de la aplicación web de una empresa que se ejecuta en instancias EC2 dentro de un grupo de Auto Scaling. Los picos de tráfico ocurren de forma impredecible y rápida durante el día. El grupo de Auto Scaling no escala horizontalmente lo suficientemente rápido durante los picos pronunciados, lo que provoca respuestas lentas para los usuarios. La empresa quiere controlar los costos al tiempo que garantiza un escalado rápido: los picos de tráfico más grandes deben causar mayores aumentos de capacidad que los picos más pequeños. ¿Cómo se debe configurar el grupo de Auto Scaling para lograr este comportamiento?

La política de escalado por pasos (step scaling policy) es la solución correcta porque permite especificar diferentes ajustes de escalado (aumentos de capacidad) basados en el tamaño de la alarma de CloudWatch. Esto es ideal para picos de tráfico impredecibles y rápidos de diferentes magnitudes, ya que un pico mayor activará un ajuste de capacidad proporcionalmente mayor. Una política de escalado simple solo realiza un ajuste fijo en respuesta a una alarma, lo que no se adapta a la necesidad de ajustes de capacidad variables. Una política de seguimiento de destino mantiene una métrica en un valor objetivo, pero no está diseñada para responder con diferentes incrementos de capacidad basados en la magnitud del pico. Los lifecycle hooks de EC2 Auto Scaling se utilizan para realizar acciones personalizadas durante los eventos de escalado, no para definir cómo se escala el grupo, y cambiar manualmente el recuento máximo de instancias no es una solución automatizada.