A gaming studio runs real-time matchmaking on EKS with sharp evening spikes where pods queue while nodes sit full, then idle capacity wastes spend overnight. CPU-based pod limits alone cannot add nodes. Which auto scaling pattern handles bursty container demand cost-effectively?
Select an answer to reveal the explanation.
Short Explanation
You've got those evening rushes hitting like a sold-out arcade, so you'll need pods to multiply fast and extra nodes to jump in when servers fill up. This paired autoscaling keeps your matches moving at peak, then sheds idle capacity overnight to save you money.
Full Explanation
Horizontal Pod Autoscaler scales Deployments based on CPU, memory, or custom metrics such as queue depth, while Cluster Autoscaler watches for unschedulable pods and provisions or terminates worker nodes within managed node groups, with scale-down delays and disruption budgets preventing flapping, so bursty evening demand gets both pod and infrastructure capacity and overnight idle nodes are reclaimed. Vertical Pod Autoscaler adjusts requests and limits rather than replica or node count, requiring restarts and failing to add capacity when nodes are full, so queuing persists during spikes. Cluster Autoscaler alone without pod scaling keeps replica counts fixed, so throughput cannot rise with demand until manual intervention and latency suffers despite new nodes. Lambda concurrency controls serverless function parallelism and does not manage EKS pods or EC2 nodes, making it irrelevant to container cluster elasticity. Exam caveat: use custom metrics for queue-driven workloads and set resource requests accurately for both scalers. Practical check: load-test a spike, observe pod scale then node scale, and verify overnight scale-in savings.