An e-commerce platform has predictable weekday spikes at 9 a.m., flash-sale surges, and steady baseline traffic on EC2 Auto Scaling groups behind an ALB. The team wants low latency during spikes without overprovisioning overnight. Which auto scaling policy combination maintains performance with cost-efficient metric-based scaling?
Select an answer to reveal the explanation.
Short Explanation
You know the morning rush is coming, so start the ovens early then adjust to orders. Predictive scaling pre-warms capacity for patterns while target tracking fine-tunes to live demand.
Full Explanation
The correct combination pairs proactive capacity with reactive adjustment because predictive scaling analyzes historical CloudWatch data to provision EC2 capacity just before the predictable 9 a.m. weekday surge, avoiding cold-start latency, while target tracking on ALB RequestCountPerTarget continuously maintains load per instance at an optimal level, automatically adding capacity during unpredictable flash-sale surges and removing it overnight to minimize cost, and this request-based metric directly correlates with user-perceived latency behind a load balancer where CPU can remain deceptively low during I/O waits or queueing. The scheduled-plus-predictive-only combination fails on responsiveness because without dynamic target tracking it cannot react to unscheduled flash sales, leaving new traffic to queue until the next scheduled action. The predictive-plus-CPU-tracking combination fails on signal fidelity because average CPU is a lagging host-level proxy that under-scales thread-constrained web workloads and over-scales background tasks, so latency spikes even when CPU looks healthy. The predictive-plus-ALB-tracking with high overnight minimum fails on efficiency because preserving idle instances overnight directly violates the no-overprovisioning constraint and inflates cost without latency benefit during steady baseline traffic. Exam caveat: distinguish predictive, scheduled, and dynamic policies and always match the scaling metric to the load balancer architecture rather than defaulting to CPU. Practical check: validate in CloudWatch that RequestCountPerTarget tracks latency, test predictive forecast coverage for at least two weekly cycles, and confirm scale-in overnight reduces DesiredCapacity to baseline.