Right-size AKS pods with the Vertical Pod Autoscaler

On most AKS bills the node pool is the largest cost, and over-sized pod requests are one of the most recoverable parts of it, because the saving is immediate and recurring once you act on it. Bring a fleet of pods' requests down to what VPA shows they actually use and the scheduler can pack them onto fewer nodes; the cluster autoscaler then removes the surplus virtual machines, and you stop paying for them on the very next billing hour. Unlike a reservation or a savings plan, this needs no upfront commitment and no lock-in, so the payback is effectively instant: the change pays for the few minutes of engineering time it took as soon as the first node is removed.

Frame the Advisor recommendation as a measurement exercise that produces a list of recurring savings with a risk grade attached, not a one-off cleanup. Turning VPA on in recommendation mode costs nothing and changes nothing in production, so the decision to enable it is risk-free; the cost question lives entirely in which recommendations you then apply. Right-sizing a stateless web service that VPA shows is using a fraction of its request is close to risk-free recoverable spend. Trimming a latency-sensitive workload that bursts at peak needs a quick look at the headroom before you act. Sort the workloads by the gap between requested and used capacity, grade each by risk, and the biggest, safest savings come first.

The arithmetic is one-sided on the easy wins. Lowering an inflated request is a configuration change measured in minutes, and it starts saving the moment the node count drops; the only real cost is the diligence of confirming a workload really is over-provisioned, which VPA's own recommendation gives you for free. Right-sizing also compounds with every other compute lever: shrink the cluster to its true size first, then buy a reservation or savings plan against the node pool that is actually left, so you never commit spend to capacity nobody was using.

Priya is the finance partner supporting the platform team. The Advisor recommendation lands against the production cluster, flagged as a cost opportunity, and the instinct is not to approve a blanket re-sizing project but to ask what the data actually says. The first move costs nothing and risks nothing: enabling VPA in recommendation-only mode does not touch a single running pod, it simply measures real consumption and produces a Target request for each workload. That turns a vague 'the cluster feels too big' into a concrete, per-workload gap between what is reserved and what is used.

Priya asks the team to read VPA's recommendations for the top workloads by request size. The web tier is reserving roughly five times the CPU and four times the memory it consumes, a batch service is sized for a peak it hits twice a day, and a couple of stateless APIs are simply over-provisioned with no real headroom needed. The list is reframed as recurring savings with a risk grade: the over-provisioned stateless APIs are close to risk-free spend to recover this sprint, the batch service is a deliberate trim that keeps a little headroom for its peak, and the web tier is a large, mostly safe saving worth a short load check first. The finance pack reads: 'The measurement is free and already done. Most of the recoverable node spend is in low-risk trims; only one workload needs a headroom review, and the saving recurs every month with no commitment.'

The cost model here is unusually favourable, because the measurement that finds the saving is free and the saving itself is recurring. Turning VPA on in recommendation mode adds no commitment and changes no running pod, yet it produces a per-workload Target you can compare against the current request to quantify exactly how much node capacity is reserved but unused. Each workload whose request sits well above its Target is recoverable spend: trim the request, let the autoscaler retire the surplus node, and the saving lands on the next bill and repeats every month thereafter.

Against that, the cost of leaving it is the standing overspend of running a cluster larger than its workload, plus the compounding waste of committing reservations and forecasts against an inflated size. The finance role is to attach the estimated monthly saving and a risk grade to each workload's recommendation, so the work is ordered by recoverable spend and the easy, low-risk trims are captured first while the few latency-sensitive workloads get the short review they warrant. Right-sizing then sets up the reservation conversation correctly: shrink to the true size, then commit against what is actually left.

Kubernetes is usually one of the larger lines on a cloud bill, and a meaningful share of it on most clusters is paid for capacity that pods reserved but never used. Requests set generously at launch, copied from a template, or never revisited as a service matured all force the cluster to run more virtual machines than the actual workload needs. Azure Advisor surfaces this as a single named recommendation to turn on the Vertical Pod Autoscaler in recommendation mode, which makes it one of the few cost levers you can act on this quarter without a commitment or a re-architecture.

The leadership question is not 'can we cut the Kubernetes bill?' in the abstract. It is 'does our cluster spend track the work it is actually doing, and do we have a routine that keeps it that way?' The defensible end state is that VPA's recommendations are read, the clearly over-provisioned workloads are right-sized, the node count falls, and the saving is realised and tracked rather than identified in a report nobody actions.

This is a return-on-effort decision, not a risky one. Turning VPA on in recommendation mode is free and changes nothing, so the only real choices are which recommendations to apply. The easy wins, trimming workloads that VPA shows are using a fraction of what they reserved, are close to free to capture and recur every month. The few latency-sensitive services that need headroom are the ones worth a deliberate review; everything else is money currently being left on the table.

After the AKS bill grew two quarters running while traffic stayed roughly flat, the CFO asked the obvious question at the review: are we paying for capacity we are not using? The honest answer at the time was that nobody knew, because pod requests had been set at launch and never measured against actual consumption, so the node count reflected reservations rather than demand.

The team's response was to stop guessing and start measuring. They enabled the Vertical Pod Autoscaler in recommendation mode across the cluster, which cost nothing and changed nothing, then read what it said each workload truly needed. Most services were reserving several times the CPU and memory they used. They trimmed the clearly over-provisioned ones, left a margin on the few latency-sensitive workloads, and watched the cluster autoscaler retire the surplus nodes. The next time the CFO asked, the answer had changed from 'we think it's about right' to 'we measured it, right-sized the over-provisioned workloads, and the node count tracks demand, with the saving showing up on the bill.' That shift, from a cluster sized by guesswork to one sized by measurement, is the return this capability delivers, and the measurement step is free.

Nearly every cluster that has grown for a while is carrying requests that were set defensively and never revisited, so it runs more nodes than the work needs. Turning on VPA in recommendation mode is the capability that makes that gap visible, and it does so for free and without touching production, which is about as low-risk as a cost lever gets.

The saving is recurring and the effort is small, while the alternative is paying every month for capacity nobody uses and then locking that overspend in with reservations bought against the wrong size. This is the rare class of cost work where the measurement is free, the easy wins are close to risk-free, and only a handful of latency-sensitive workloads need a deliberate look, which is exactly the trade leadership should be quickest to approve.