Question

A media company runs a stateless web tier on an EC2 Auto Scaling group behind an ALB. During flash-sale events, traffic ramps sharply then drops in irregular waves. The team currently uses simple scaling policies with CloudWatch alarms on average CPU, plus a 300-second cooldown period. They observe that the group repeatedly scales out and scales in within short intervals (flapping), causing instances to churn and users to hit brief connection errors while capacity settles. The team wants scaling to respond quickly to sustained demand while avoiding rapid oscillation, with minimal manual tuning of thresholds. Which change best meets these requirements?

Accepted Answer

Replace the simple scaling policies with a target tracking scaling policy on average CPU utilization, allowing Auto Scaling to compute the required capacity and manage the scaling thresholds automatically.

Answer

Increase the cooldown period to 1800 seconds so the group cannot scale in or out more than once every 30 minutes during the event.

Answer

Switch to scheduled scaling that sets a fixed desired capacity for the duration of every flash-sale window based on the previous event's peak.

Answer

Add a second simple scaling policy on network throughput and lower the CPU alarm threshold so the group reacts faster to traffic spikes.