Right-Sizing Virtual Machines in Azure

The mistake of bringing the datacenter to the cloud

In the datacenter, hardware was a sunk cost: once you bought the server, using 10% or 90% of it cost the same. So everyone bought with plenty of headroom. When those workloads migrate to Azure without review, the habit comes along — and the company starts paying for CPU and memory it never uses. Right-sizing is the practice of matching each virtual machine to real consumption, and it is one of the fastest savings in the cloud.

As a Microsoft partner and CSP, RHC treats right-sizing not as a one-time event but as a continuous cycle of observation and adjustment.

Right-sizing starts with data

Guessing at size is dangerous: cut too much and you degrade the application, cut too little and you save nothing. The correct basis is performance data over time. Essential metrics:

• CPU — average and peaks (95th percentile), not just the snapshot.
• Memory — real consumption vs. provisioned.
• Disk (IOPS and throughput) — many VMs are mis-sized on disk, not CPU.
• Network — relevant for communication-heavy workloads.

Azure Monitor collects these metrics, and Azure Advisor turns the history into concrete resize or shutdown recommendations.

Understanding VM series

Right-sizing is not just lowering the number — it is choosing the right series. Azure organizes VMs into families with different profiles:

A database VM suffering on memory does not need more CPU — it needs to move from the D-series to the E-series. Choosing the right family sometimes saves more than reducing the size.

Burstable VMs for light workloads

Many servers run idle most of the time and only need power in short bursts. The B-series (burstable) was made for this: it accumulates CPU credits when idle and spends them at peaks, at a much lower cost than an equivalent general-purpose VM.

The right-sizing process

1. Observe — collect at least two to four weeks of metrics to capture business cycles.
2. Identify candidates — VMs with consistently low CPU and memory.
3. Choose the new size — family and SKU matched to the peak percentile, with a safety margin.
4. Test — validate in non-production or a controlled window.
5. Apply — resize (requires a VM restart).
6. Monitor — confirm performance holds after the change.

Beyond size: other sources of waste

Right-sizing goes hand in hand with other cost cleanups:

• VMs stopped but not deallocated — a VM "stopped" by the OS still bills compute; you must deallocate it through Azure.
• Orphaned disks — managed disks left over from deleted VMs keep billing.
• Idle public IPs and load balancers.
• Old snapshots accumulating storage cost.
• Non-production environments running 24×7 without need.

Right-sizing without losing resilience

Reducing size cannot compromise availability. Cautions:

• Keep a safety margin above the observed peak, not the average.
• Consider seasonality (month-end close, campaigns, year-end peaks).
• Combine with autoscale where load varies, instead of fixing a large VM.
• Document the baseline before changing, to compare afterward.

Checklist / Key takeaways

• Right-sizing starts with performance data, not a hunch.
• Look at CPU, memory, disk, and network — the bottleneck is not always CPU.
• Choose the right VM series before touching the size.
• Use the B-series (burstable) for light, intermittent workloads.
• Deallocate stopped VMs and clean up orphaned disks and IPs.
• Keep margin above the peak and account for seasonality.

Well-executed right-sizing usually frees up 20–40% of compute cost without users noticing any difference — and, treated as a cycle, keeps the bill lean over time. RHC runs this cycle based on your real data.