Rightsizing Azure virtual machines means matching each VM's size and family to the workload it actually runs, rather than the size someone guessed at provisioning time. The savings are durable because they reduce the per-hour rate permanently, and they compound: a rightsized fleet is also the clean baseline you commit to with reservations and savings plans. The discipline is using real utilization data, not intuition, and changing size in safe steps.
This article is part of our Azure cluster. Start with the complete guide to Azure cost optimization, the pillar this piece links up to. Rightsizing is the heart of the Cut step in our See, Cut, Lock, Run method.
Read at least two weeks of CPU, memory, disk IO, and network for each VM. Two weeks captures the weekly cycle and the month-end or batch peaks that a shorter window misses. Use Azure Monitor metrics, and enable memory metrics through the monitoring agent, because Azure does not collect guest memory by default and memory is often the binding constraint.
Step 1: Find the over-provisioned VMs
Azure Advisor flags VMs that look under-utilized and suggests smaller sizes or shutdown, which is a fast first list. Treat it as a starting point, not gospel, because Advisor works from a limited window and default thresholds. Combine it with your own utilization export to catch VMs idling at single-digit CPU and high-memory VMs whose memory sits mostly unused. The biggest savings usually hide in a small number of large VMs, so rank candidates by size and cost, not by count.
Step 2: Pick the right family, then the right size
Azure VM families are tuned to different workload shapes: general purpose for balanced loads, compute optimized for CPU-bound work, memory optimized for databases and caches, and burstable B-series for low-baseline workloads that occasionally spike. Choosing the wrong family is a bigger error than choosing the wrong size within it. A web tier idling most of the day may belong on a burstable family; a steady CPU-bound service belongs on compute optimized. Once the family fits, drop to the size whose capacity sits comfortably above the high-percentile utilization with headroom for spikes, not the peak-of-peaks.
Hundreds of VMs and no time to size them all?
Our Azure cost audit profiles every VM against real utilization, recommends the family and size for each, and sequences the changes by savings and risk. On the performance model, you pay only from realized savings. No savings, no fee.
Book an Azure cost audit →Step 3: Downshift safely, in steps
Resize one step at a time rather than jumping several sizes, and start with non-production. Resizing an Azure VM requires a restart, so schedule it in a change window and confirm the workload tolerates the smaller capacity over a full cycle before going further. For stateful workloads, verify the new size still meets disk throughput and IOPS limits, which are tied to VM size as well as disk tier. Keep a rollback size noted so reverting is a known, fast operation if a workload turns out to need more.
Step 4: Handle the special cases
Some workloads should not be rightsized in place. Intermittent or dev and test VMs are better scheduled to deallocate when idle than shrunk, a play covered in dev and test pricing and scheduling. Spiky workloads may suit the burstable family or autoscaling rather than a fixed smaller size. And a VM that turns out to be unused entirely should be deleted, not resized, which is why a waste sweep precedes rightsizing in any full pass.
| Symptom | Likely fix |
|---|---|
| Steady low CPU, fixed size | Drop a size, or move to burstable |
| High memory, low CPU | Move to memory-optimized, smaller vCPU |
| Idle most of the day | Schedule deallocation |
| Never used | Delete, do not resize |
| Spiky, unpredictable | Burstable family or autoscale |
Step 5: Lock it in, then commit
Rightsizing drifts back as teams scale up "just to be safe". Set budgets and anomaly alerts so re-inflation is caught, the Lock step of our method. Only once the fleet is right and stable should you buy reservations or a savings plan against it, and the choice between those is covered in Azure Reservations vs Azure savings plan for compute. Committing first locks the oversized fleet in for the term.
VM families and resize behavior above reflect Azure as of May 2026. Verify current family options, resize restart requirements, and per-size disk limits in Azure documentation before changing production VMs, as the catalog evolves.
The Azure Cost Optimization Field Guide includes the VM rightsizing worksheet and the family-selection guide we use on engagements. It is the downloadable companion to this article.
The short version
Measure two weeks of real utilization, find the over-provisioned VMs, pick the right family then the right size, downshift in safe steps starting outside production, handle dev and idle cases with scheduling or deletion, and lock the result before you commit. To run this across the whole estate, follow how to run an Azure cost optimization assessment. When you want every VM sized correctly without tying up your team, that is exactly what our Azure cost optimization service delivers.