A county ECS service behind an Application Load Balancer must add tasks when each target is overloaded with requests. Which metric-driven scaling approach fits?
Select an answer to reveal the explanation.
Short Explanation
When the ALB starts handing each task a firehose of requests, grow the team—raise desired count off request-per-target, don’t just give one tired worker a bigger hat.
Full Explanation
Scaling an Amazon ECS service’s desired count from ALB request density—such as ALBRequestCountPerTarget or equivalent request-per-target tracking—fits a county web tier that must add tasks when each target is overloaded. The approach works because Application Load Balancer metrics reflect how much citizen or staff traffic each registered task is actually handling. When request-per-target rises, Application Auto Scaling increases desired count so more tasks share the load across Availability Zones, restoring headroom without rewriting the application. Horizontal task scale is the natural fit for request-driven ECS services behind an ALB.
Scaling only by increasing each task’s CPU reservation with no change to desired count fails by concept because that is a vertical reservation change, not horizontal capacity growth; overloaded request fan-out needs more targets, not merely a larger CPU claim on the same task count. Disabling the load balancer and scaling solely on EC2 instance memory pressure in the cluster fails because it removes the request-distribution and target-health signals that define overload for a multi-AZ web service, and host memory is a weak proxy for ALB request saturation. Scheduling a fixed desired count of one task for all hours fails because a pinned single task cannot absorb demand spikes and leaves the county portal with a single point of failure regardless of request volume.
Exam caveat: request-based scaling still needs sensible min/max counts, cooldown or stabilization settings, and healthy target registration or you can thrash or starve capacity. Operational check: baseline ALBRequestCountPerTarget during peak permit hours, set a target tracking policy against that metric, and confirm in a load test that desired count rises before latency SLOs break.