Vertical pod autoscaling, VPA, observes the actual CPU and memory a workload consumes and adjusts its resource requests to match, closing the gap between what a pod reserves and what it uses. That gap is the dominant source of Kubernetes overprovisioning: a node schedules pods against their requests, so a fleet that requests double what it uses needs roughly double the nodes. VPA reclaims that headroom and lets the cluster autoscaler remove the spare nodes. The risk is that changing a running pod's resources requires recreating it, so VPA in full automatic mode can evict pods at inconvenient times. The practical answer is to run VPA in recommendation mode first, then enable automatic updates only where disruption is tolerable.
Here is how VPA works, where it conflicts with horizontal scaling, and the rollout sequence that captures the saving without breaking production.
Why do requests, not usage, drive the bill?
Kubernetes schedules and bills indirectly. The scheduler places pods on nodes according to their CPU and memory requests, not their live usage, and you pay for the nodes. A pod that requests four cores but uses one still occupies four cores of schedulable capacity, so three cores per replica sit idle yet provisioned. Multiply that across a fleet and the cluster runs far more nodes than the real workload needs. This is why rightsizing requests is the highest leverage move in Kubernetes cost work: it directly reduces the node count the cluster autoscaler has to keep running.
How does VPA decide the right request?
VPA watches historical and live resource consumption and produces a recommendation for requests, typically targeting a percentile of observed usage with headroom for spikes. It runs in three modes that matter for safety.
- Off, or recommendation mode. VPA computes and reports target requests but changes nothing. This is where you start, so you can compare recommendations against current requests before any disruption.
- Initial mode. VPA sets requests only when a pod is first created, so existing pods are never evicted, but new pods get right set values.
- Auto mode. VPA actively updates running pods, which requires evicting and recreating them. This captures the most saving but introduces restart risk, so reserve it for workloads that tolerate restarts.
Where does VPA conflict with horizontal autoscaling?
VPA and the horizontal pod autoscaler can fight if both act on the same signal. The horizontal autoscaler adds replicas when CPU rises; VPA raises the CPU request of each replica from the same usage. Pointed at the same metric they oscillate. The standard resolution is to let the horizontal autoscaler scale on a workload metric such as requests per second or queue depth, and let VPA handle memory and the CPU request floor, so each controls a distinct dimension. For workloads that scale cleanly on replica count, horizontal scaling tuned for cost is often the better primary lever, with VPA in recommendation mode informing the per replica size.
What is the safe rollout sequence?
- Deploy VPA in recommendation mode across the namespace and let it observe at least one full traffic cycle, including any weekly peak.
- Compare recommended requests against current requests to size the prize. A fleet requesting two to three times its usage is common and tells you the reclaim is worth the effort.
- Apply recommendations to stateless, restart tolerant workloads first, in initial or auto mode, and watch for evictions and throttling.
- Hold stateful and latency sensitive workloads in recommendation mode and apply changes during maintenance windows.
- Confirm the cluster autoscaler then removes the freed nodes, because the saving only lands when node count actually falls.
A worked example
A scaling fintech ran a stateless API tier on Kubernetes where every deployment requested resources copied from an old template. VPA in recommendation mode showed the tier requested close to three times the CPU and twice the memory it used at peak. We applied recommendations to the stateless services first, kept the stateful datastore in recommendation mode, and let the cluster autoscaler retire the freed nodes over a week. The node count for that tier fell by roughly a third with no change in latency, because the pods had always been oversized rather than busy. The reclaimed headroom was part of the wider program that left the company materially lighter on cloud spend. Figures are verified against billing data and anonymised.
Frequently asked questions
What does vertical pod autoscaling actually do?
Is it safe to run VPA in automatic mode?
Can VPA and the horizontal pod autoscaler run together?
Talk this through with us
We help platform teams roll out vertical pod autoscaling and rightsize Kubernetes requests across AWS, Azure, GCP, and OCI without disrupting production. We take zero provider commissions and answer only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee scoped up front or a no risk Gainshare basis. Book a strategy call to scope it for your estate, and follow more analysis in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.