An e-commerce platform runs burst checkout APIs on Lambda and catalog services on EKS with spiky traffic. The team must scale functions without throttling, scale pods on custom latency metrics, and add nodes only when pods cannot schedule. Which auto scaling combination fits serverless and container patterns?

The combination of Lambda provisioned concurrency with Application Auto Scaling, HPA for pods, and Cluster Autoscaler for nodes fits the three scaling needs. Provisioned concurrency keeps burst checkout functions initialized and warm, while Application Auto Scaling adjusts that capacity with demand to reduce cold starts and throttling. HPA can scale catalog pod replicas using the required custom latency metric, responding to spiky user-perceived slowness. Cluster Autoscaler adds nodes when pods are pending because they cannot be scheduled, helping optimize bin-packing and cost. HPA on CPU utilization fails the metric requirement: CPU reflects resource saturation rather than request latency, so it may under-scale during I/O-bound latency spikes or over-scale during efficient high-CPU work. Reserved concurrency limits without provisioned capacity sets a maximum and isolation boundary but does not pre-initialize environments, leaving cold starts and possible throttling during sudden checkout bursts. EC2 Auto Scaling on CPU for nodes responds to aggregate CPU independently of Kubernetes scheduling, so it can scale out before pods are unschedulable or fail to add nodes when pending pods need them. An exam caveat: Lambda Application Auto Scaling, HPA, Cluster Autoscaler, and EC2 Auto Scaling act at different layers and respond to different signals; distinguish function capacity, pod replicas, and node provisioning. A practical check is to verify provisioned-concurrency utilization alarms, the custom-latency metric pipeline, and pending-pod events alongside Cluster Autoscaler logs during a load test before peak traffic.