A machine provisioned to handle a launch day load it saw once, a database tier chosen for headroom nobody measured, a fleet copied from a template that was generous to begin with. The result is the most common waste in any Azure estate: compute running at single digit utilization, billing at full rate around the clock. Rightsizing the overprovisioned tier of a typical estate recovers fifteen to thirty percent of compute spend, and unlike a discount it requires no commitment and no negotiation. It is pure waste removal, gated only by the discipline to act on the evidence.
The reason most estates carry oversized VMs is that the original size was a guess made under uncertainty, never revisited once real load data existed. Rightsizing starts by replacing the guess with measurement. Azure Advisor and the monitoring data behind it give the utilization picture across CPU, memory, disk, and network over a meaningful window. The window matters: a fourteen day sample misses the month end batch, so the baseline should span at least a full business cycle.
A VM is correctly sized when its dimensions match its real demand with a deliberate, not accidental, margin. Four signals reveal the gap.
The fastest way to break a production workload is to rightsize on a sample that missed its busiest moment. A reporting server idle most of the month runs hard at close. A retail platform that looks calm in February is a different machine in November. The measurement window must contain the real peak, or the saving becomes an incident.
Rightsizing is not a single action. Depending on the workload, the right move is a step down within a family, a shift to a more efficient family, or a change in how the machine runs rather than how big it is.
The simplest move: drop from a larger to a smaller member of the same VM family, halving the cost when the data shows the workload uses half the resource. Same architecture, same behavior, lower bill. This is the bulk of the recoverable saving in most estates.
A workload that is memory bound on a balanced family belongs on a memory optimized one, and a CPU light one may belong on a burstable B series that bills for a baseline and bursts when needed. Matching the family to the demand profile often beats simply shrinking within the wrong family.
Some machines do not need to be smaller, they need to not run all the time. A non production VM on an auto shutdown schedule running twelve weekday hours costs roughly a third of a continuous one. For the right workloads, scheduling beats resizing because it touches no architecture at all.
The single most expensive sequencing error in Azure cost work is buying reservations on an unoptimized footprint. The order of operations determines whether the two plays compound or collide.
A three year reservation bought on an oversized fleet locks in the oversizing for three years. The discount applies, but to a footprint that should have been thirty percent smaller, so the estate pays a reduced rate on capacity it never needed. Worse, the reservation creates resistance to rightsizing later, because shrinking the VM strands the commitment. Optimization that should have happened first is now fighting a contract.
Rightsize the footprint to its true steady state, let it stabilize, and only then size reservations or a savings plan against the optimized baseline. The commitment now covers exactly the capacity the workload uses, the discount lands on a clean number, and there is no stranded reservation to unwind. Waste removal first, rate reduction second, every time.
Rightsizing is not a one time project. Without governance, the estate drifts back to oversized within a year as new workloads arrive at default sizes and old ones grow on autopilot. The saving has to be defended structurally.
An allowed SKU policy removes the oversized families from the provisioning menu entirely, so new resources cannot start oversized. The guardrail makes the right size the default and the large size the documented exception.
A standing quarterly rightsizing review against fresh Advisor data catches the drift before it compounds. The environment tag scopes where to cut hardest, with non production reviewed more aggressively than production.
When the cost lands on the team budget through chargeback, oversizing becomes the team's own line item to defend. Local ownership does more to hold rightsizing than any central mandate, because the incentive is now aligned.
The utilization evidence model, the four sizing signals, the three reduction moves, the sequence against reservations, and the governance cadence that holds the saving instead of letting sprawl creep back. Sent on request.
We measure the real utilization across a full business cycle, identify the step downs, family shifts, and scheduling moves that hold under peak, sequence them before any commitment, and install the guardrails and review cadence that keep the estate from drifting back. Pure waste removal, no commitment required.
Yes, and mature estates do. The pipeline has three stages. Azure Monitor and Log Analytics collect per session host metrics: CPU, memory pressure, session density, and login storm behavior. A sizing engine, either Azure Advisor recommendations consumed programmatically or a custom Logic App reading the Log Analytics workspace, maps observed utilization against the AVD VM catalog. And a deployment stage rebuilds host pools through image templates and autoscale plans rather than resizing hosts by hand.
The honest constraint is that AVD right sizing is a fleet decision, not a per VM decision. Session hosts are built from a shared image and pooled, so the automation optimizes the host pool SKU and the host count, not individual machines. The highest yield levers in practice are autoscale schedules that drain and deallocate hosts outside working hours, and multi session density tuning that moves the estate from oversized personal hosts to correctly pooled ones. Together they routinely cut AVD compute spend 30 to 50 percent.
Automate the purchase side with the same seriousness. Reserved instance and savings plan coverage for AVD baseline capacity can be managed programmatically against utilization data, buying reservations for the steady floor and leaving burst capacity on pay as you go. The instrument choice is covered in savings plan versus RI, the entitlement layer in AVD licensing, and the broader program in Azure cost optimization.