A company hosts a web application on Amazon EC2 instances that are part of an Auto Scaling group behind an Application Load Balancer (ALB). The application experience spikes in requests that come thro

Configuring an Amazon CloudWatch alarm to monitor the ALB RequestCount metric is the standard and most cost-effective way to scale an Auto Scaling group based on application load. When combined with a target tracking scaling policy, Auto Scaling automatically adjusts the number of EC2 instances to maintain a desired average number of requests per target, effectively handling traffic spikes and providing reactive scaling for the given scenario.

Predictive scaling policies are designed for recurring, predictable load patterns, not for unpredictable spikes lasting 15-20 minutes, making it potentially an over-engineered solution for this requirement.

Monitoring the ALB UnhealthyHostCount metric would trigger scaling based on the health of instances, not the incoming request load, thus failing to address the requirement to scale based on request count.

While a user-defined metric for GET requests could technically work, the ALB RequestCount metric is a standard, readily available metric that directly fulfills the requirement without requiring custom metric publishing, making it more cost-effective and simpler.