A SysOps engineer is troubleshooting performance issues for a company's web application that runs on EC2 instances inside an Auto Scaling group. Traffic surges happen unpredictably and rapidly during the day. The Auto Scaling group is not scaling out quickly enough during sharp spikes, causing slow responses for users. The company wants to control costs while ensuring quick scaling — larger traffic surges should cause larger capacity increases than smaller surges. How should the Auto Scaling group be configured to achieve this behavior?

A step scaling policy allows you to define different scaling adjustments based on the size of the alarm breach. This directly addresses the requirement for larger capacity increases during larger traffic surges, providing fine-grained control over scaling behavior and cost optimization. Simple scaling policies make a single scaling adjustment and then enter a cooldown period, which isn't suitable for rapid, varied scaling needs. Target tracking policies aim to keep a metric at a specific target value, but they don't inherently allow for different-sized capacity increases based on the magnitude of the load increase. Lifecycle hooks are used for performing custom actions during instance launch or termination, not for defining scaling logic itself. Manually changing the maximum instance count defeats the purpose of automated scaling.