Why this matters
An Azure VM bills by the size you assign, not by the CPU it uses. A 16 vCPU D-series VM costs the same at light load and at heavy load. That gap is why rightsizing matters. The goal is not the smallest size, but the cheapest size that keeps headroom for peaks, maintenance, failover and growth.
The SKU family matters as much as the size. General purpose D-series, memory optimized E-series, compute optimized F-series, burstable B-series, storage optimized L-series and GPU N-series have different ratios of CPU, memory, local disk and network. Moving from E-series to D-series to save money fails when the workload needs memory. Moving from D-series to B-series fails when CPU credits run out during a busy period.
Rightsizing also changes what you can commit to. Reserved instances and savings plans are tied to a size or family. Resize first, then match commitments to the new shape. Commit before rightsizing and you may lock in the wrong capacity.
Before you start
You need a baseline before you touch a VM. Turn on Azure Monitor metrics for every VM and deploy the Azure Monitor Agent where you need guest memory and disk data. Host metrics do not include memory used inside the guest. Collect at least two weeks that include a normal weekly cycle and known batch jobs. Longer is better for seasonal workloads.
Write down the performance limits for each workload. CPU alone is not enough. Record peak CPU, guest memory pressure, disk IOPS and throughput, network throughput, and application latency. For B-series, record CPU credits remaining and credits consumed. For GPU or storage workloads, record the device counters that show saturation.
Check constraints before you pick a target size. Confirm the size exists in the region and availability zone, supports the VM generation, and meets disk, network and accelerated networking needs. Check whether the VM is in a scale set, behind a load balancer, or covered by a backup policy. Check Azure Policy for allowed SKUs and any quota limits on the subscription.
Set a maintenance window and a rollback plan. Copy the current size, disk layout and extension list into the change ticket. If the VM cannot take a reboot, plan a temporary second instance or use a scale set update. Treat rightsizing as a production change.
How to do it
The work is a loop: measure, classify, pick, test, resize, and watch. Do not shrink every VM by the same amount. A database, a build agent and a web front end have different bottlenecks. The steps below keep the change controlled and repeatable.
Use Azure Resource Graph to pull the inventory with size, location, tags, power state and resource group. Use Azure Advisor cost recommendations as a starting point, not as the final answer. Advisor sees host metrics and may miss guest memory, batch cycles and dependency constraints.
Choose the target family first, then a size within that family. Keep one step of headroom for failover and startup spikes. If the workload is spiky but predictable, consider a scale set or autoscale instead of a larger fixed size. If the workload is steady and memory heavy, an E-series size may be cheaper than a larger D-series size with unused CPU.
- Inventory every VM. Use Azure Resource Graph to query size, location, tags, power state and scale set membership. Export the result so finance and operations work from the same list.
- Collect guest and platform metrics. Use Azure Monitor and VM insights to capture CPU, memory, disk, network and CPU credits for at least two weeks. Mark known peaks, batch runs and backup windows.
- Classify each workload. Label each VM as CPU bound, memory bound, disk bound, network bound or bursty. That label decides the family, not the current size.
- Shortlist target sizes. Check region, zone, VM generation, disk throughput, network limits and policy allowed SKUs. Confirm the target size is available before the change window.
- Test on a clone. Resize a copy and run the same smoke tests and batch jobs. Watch for driver, extension and licensing issues that only appear after the reboot.
- Resize in a change window. Use the portal, Azure CLI az vm resize or PowerShell Update-AzVM. If the target size is not on the current hardware cluster, deallocate the VM first, then resize and start it.
- Validate the guest. Check memory, disk mounts, network interfaces, extensions and application health. Recheck thread pools, heap sizes and other tuning that assumes a fixed core count.
- Update templates and budgets. Change the size in Bicep, ARM templates or Terraform so the next deployment does not undo the work. Add a budget alert and put the new size on the monthly review.
How to check it worked
Compare the same metrics before and after for at least one full weekly cycle. CPU should fit the new capacity, but memory pressure, disk latency and application response time matter more. A smaller VM that swaps or queues disk is not a saving.
Open Azure Cost Management and compare actual cost by VM resource for the days after the change. Do not rely on the price sheet alone. Disks, public IP addresses, backup, monitoring and commitments are separate line items. Check that the old size no longer appears in the cost data.
Review Azure Advisor after the change. A new recommendation may appear if the VM is still oversized. If the VM is now undersized, Advisor may not flag it, so use your own alerts. Set alerts on CPU, available memory, disk queue depth and application latency.
For scale sets, confirm the model and every instance show the new size. For VMs covered by reservations, confirm the commitment still matches the new family and size. If it does not, work with finance before the next billing cycle.
Mistakes to avoid
The common mistake is to size from average CPU. A VM that idles all week and spikes at month end needs burst capacity or autoscale, not a size that fits the average. Look at peak CPU, memory and disk waits together.
Another mistake is to drop to B-series without a credit budget. Burstable VMs suit low steady workloads, but a busy build agent or database can exhaust credits and then run slowly. Watch CPU credits remaining and the workload's tolerance for slowdown.
Do not resize one instance of a scale set by hand. Change the scale set model, then update instances in a controlled way. Update the infrastructure as code, the runbook and the monitoring baseline. A resize that exists only in the portal will be lost at the next deployment.
Do not ignore the noncompute bill. A larger VM may be the obvious cost, but unattached disks, old public IPs and duplicate backups often survive a resize. If the team lacks time, Cloudverg's Cloud cost audit at $4,500 fixed price is one option among others: a read-only review that ranks rightsizing and idle resource findings. It is not the only route. A careful internal review using the steps above can do the same job.
Frequently asked questions
How often should I rightsize Azure virtual machines?
Review each VM at least once a quarter and after a major release, a migration or a sustained change in traffic. Use at least two weeks of data that includes a normal week and known peaks. Steady workloads can go longer between reviews.
Can I resize an Azure VM without downtime?
Not always. Many size changes need a reboot, and some need the VM to be deallocated first because the target size is not available on the current hardware cluster. Use a load balancer, availability set or scale set to keep the service up during the change.
Does resizing an Azure VM always lower the bill?
No. The compute rate changes, but disks, public IPs, backup, monitoring and commitment plans continue to bill. Check actual cost in Azure Cost Management after the change, not just the VM size.