Right-size or shut down underutilised virtual machines

Compute is usually the biggest single category on an Azure invoice, and underutilised VMs are the most recoverable part of it because the saving is immediate and recurring. Resize a machine to a SKU one tier smaller and the hourly rate falls the moment the resize completes; shut an idle dev box down outside working hours and you stop paying for roughly two-thirds of the week. Unlike a reservation or a savings plan, right-sizing 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 on the very next billing hour.

Frame each Advisor recommendation as a recurring saving with a risk grade rather than a one-off cleanup. A shutdown on an idle test VM is close to risk-free recoverable spend. A resize on a busy production database is a saving with a trade-off that needs a quick look at the workload's peaks before you act. Sort the list by estimated monthly saving, grade each by risk, and you have a prioritised plan where the biggest, safest savings come first.

The arithmetic is one-sided on the easy wins. A shutdown schedule or a one-tier resize costs minutes of engineering time and starts saving on the next bill; the only real cost is the diligence of confirming a machine truly is oversized before you shrink it. Right-sizing combines naturally with reservations afterwards: shrink the estate to its true size first, then buy a reservation against what is actually left, so you are never committing spend to capacity you did not need.

Priya is the finance partner watching the Azure compute line outgrow the customer base. Advisor lists fourteen right-size and shutdown recommendations across two subscriptions with an estimated annual saving against each. The instinct is not to wave through a blanket 'optimise everything' instruction; it is to sort the list by saving and grade each line by risk. Right-sizing needs no commitment and no lock-in, so every captured recommendation drops the bill on the very next billing hour and keeps dropping it, which makes the payback effectively instant and the saving recurring rather than one-off.

Priya splits the list into three buckets. The idle non-production machines, dev build agents and test boxes that nobody touches after hours, are near risk-free recoverable spend: an auto-shutdown schedule stops paying for roughly two-thirds of the week with no workload risk at all. The clearly oversized machines sitting at single-digit CPU are a one-tier resize, a small saving each but recurring and low-risk. The handful of busy production resizes are the only lines that carry a trade-off and get a workload check before action. The finance pack reads: 'The shutdown and resize buckets are recoverable spend we can capture this sprint with instant payback and no commitment; once the estate is right-sized we buy a reservation against what is actually left, so we never pre-pay for capacity we were about to remove.'

The savings model here is unusually attractive because the return is immediate and recurring with no commitment attached. A resize or a shutdown schedule lowers the bill on the next billing hour and keeps it lowered, so unlike a reservation there is no break-even period to wait out and no risk of over-committing. Each Advisor recommendation carries its own estimated saving, which means the work can be ranked by return and worked biggest-first rather than in the order the report happens to list it.

The cost of inaction is the saving you are choosing not to take, compounded every month it is deferred. A fleet of dev machines left running out of hours, or a production tier sitting two SKUs too large, is recoverable spend that walks out of the door on every invoice. Against that, the remediation cost is minutes of engineering time per machine for the easy wins and a short workload review for the few production resizes that carry a trade-off. The finance role is to attach the estimated saving and a risk grade to each recommendation so the easy, large, recurring savings are captured first and the reservation is bought against the right-sized estate, not the oversized one.

Compute is typically the largest line on the cloud bill, and a meaningful share of it on most estates is paid for capacity that is barely used: machines oversized at provisioning, dev environments left running overnight, servers that kept their on-premises sizing after a migration. Azure Advisor surfaces this as a list of named machines with an estimated saving against each, 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 cloud bill?' in the abstract. It is 'does our compute spend track the work we are actually doing, and do we have a routine that keeps it that way?' The defensible end state is that idle machines are shut down or scheduled, oversized ones are resized, and the savings are realised and tracked, not just identified in a report that nobody actions.

This is a return-on-effort decision, not a risky one. The easy wins, shutting down idle non-production machines and resizing clearly oversized ones, are close to free to capture and recur every month. The few production resizes that carry a performance trade-off are the ones worth a deliberate review; everything else is money currently being left on the table.

After a quarterly review where the cloud bill grew faster than revenue, the CFO asked the platform lead the blunt version of the question: how much of what we are paying for is actually being used? The honest answer at the time was that nobody had a current number, because sizing decisions were made at provisioning and rarely revisited, and Advisor's recommendations were visible but never systematically actioned.

The team's response was to stop treating right-sizing as an occasional cleanup and start treating it as a routine. They pulled every Advisor cost recommendation, shut down or scheduled the idle non-production machines, resized the clearly oversized ones, reviewed the few production resizes against their real peaks, and then bought a reservation against the estate that was left. The next quarter the answer to the CFO's question had changed from 'we are not sure' to 'compute spend now tracks utilisation, we captured a recurring saving against the idle and oversized machines, and we have a monthly routine that keeps it that way.' That shift, from sizing set once and forgotten to spend that is continuously matched to work, is the confidence signal this capability delivers, and the easy wins cost only the engineering time to make the change.

Most cost levers involve a trade: a reservation locks in commitment, a re-platforming consumes engineering quarters, a headcount freeze costs delivery. Right-sizing is the rare one where the easy wins, idle machines shut down and clearly oversized ones resized, cost only the time to make the change and start saving immediately, with no commitment and no lock-in. That makes it the lever to pull first, before any commitment-based discount, because committing against an oversized estate freezes the waste in place for the term.

The risk of inaction is not dramatic, it is quiet and compounding: a compute bill that grows faster than usage, unit economics that drift the wrong way, and cost decisions stacked on top of capacity nobody is using. This is the class of saving leadership should be quickest to mandate, because the upside recurs every month and the cost of capturing it is a routine, not a project.