Rightsizing Virtual Machines in Azure

What rightsizing means in practice

When a VM is provisioned, you choose a SKU — for example, Standard_D4s_v5, which gives you 4 vCPUs and 16 GiB of RAM. If the application running on that VM consistently uses 1.5 vCPUs and 6 GiB of RAM, you are paying for roughly twice the resources you need.

Rightsizing identifies that gap and moves the VM to a smaller SKU — in this case, perhaps Standard_D2s_v5 (2 vCPUs, 8 GiB RAM). The cost difference between a D4s_v5 and a D2s_v5 in East US is approximately $140/month vs $70/month on pay-as-you-go — a $70/month saving per VM. Multiply that across dozens of over-provisioned VMs and the annual savings become significant.

Rightsizing is not only about downsizing. It also means choosing the right VM family. A workload running at 70% CPU but only 10% memory would be better served by the compute-optimised F-series than by a general-purpose D-series, which may mean both better performance and lower cost.

Finding rightsizing candidates with Azure Advisor

Azure Advisor analyses VM performance data from Azure Monitor and produces rightsizing recommendations automatically. The recommendations appear in the Advisor portal under the Cost category and are also accessible via CLI.

Advisor flags VMs where average CPU utilisation over the past 7 days is below 5%, or where the P95 CPU is below 10%. It then suggests a smaller SKU and shows the estimated monthly savings. Recommendations are actionable directly from the portal — you can resize with one click from the Advisor recommendation card.

To retrieve Advisor rightsizing recommendations from the CLI:

# List all Advisor cost recommendations
az advisor recommendation list \
  --category Cost \
  --output table

# Filter specifically for VM resize recommendations
az advisor recommendation list \
  --category Cost \
  --query "[?contains(shortDescription.problem, 'resize') || contains(shortDescription.problem, 'Right-size')]" \
  --output table

Each recommendation includes the current SKU, the suggested SKU, the estimated annual saving, and a confidence score based on the monitoring window. A high-confidence recommendation means the data is consistent across the full monitoring period rather than based on a single quiet day.

Analysing VM performance with Azure Monitor

Before acting on any recommendation, validate it with Azure Monitor. Advisor uses a 7-day window and a single CPU metric; that may miss weekly peak patterns or memory pressure that Advisor does not always surface clearly.

Key metrics to review before resizing:

• Percentage CPU — view P50, P95, and maximum over a 30-day window. A VM with P95 CPU of 8% but a single spike to 90% once per week still has a legitimate case for its current size if that spike is latency-sensitive.
• Available Memory Bytes — divide available memory by total memory to get utilisation percentage. Advisor does not always catch memory pressure clearly; check this manually.
• Disk IOPS and throughput — if the workload is disk-bound, the attached disk tier may be the real bottleneck, not the VM SKU.
• Network In/Out — verify the target SKU supports the required network bandwidth for your workload before committing to a resize.

# Query CPU utilisation for a specific VM over 30 days
az monitor metrics list \
  --resource /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vm-name} \
  --metric "Percentage CPU" \
  --interval PT1H \
  --start-time 2026-02-17T00:00:00Z \
  --end-time 2026-03-19T00:00:00Z \
  --aggregation Average Maximum \
  --output table

Choosing the right VM family

Rightsizing is not only about size — it is also about family. Azure organises VM SKUs into families optimised for different workload profiles. Choosing the right family can save money and improve performance simultaneously.

The B-series deserves special attention for rightsizing. If a workload runs at low CPU most of the time but needs occasional bursts — a lightly trafficked web app, a CI runner, an admin panel — the B-series is often 15–30% cheaper than a D-series of equivalent nominal size because you are paying for CPU credits rather than dedicated capacity. The trade-off is that sustained high CPU will drain credits and throttle performance.

Rightsizing guidance by workload type

The resizing process

Resizing a VM in Azure involves two possible paths depending on whether the target SKU is available on the same hardware cluster as the current VM.

In-place resize (no deallocation): If the target SKU is within the same VM family and the hardware supports it, Azure may be able to resize without a full stop. This is visible in the portal — a green tick next to the target size indicates it is available without deallocation. In practice, this is not always available, particularly when moving across v-series generations.

Stop-deallocate and resize: The standard path. Stop and deallocate the VM (not just stop — deallocate releases the hardware), change the size in the portal or CLI, then start the VM again. The VM will get a new dynamic IP if no static IP is assigned. Plan this as a maintenance window.

# Resize a VM to a new SKU (requires the VM to be deallocated first)
az vm deallocate \
  --resource-group myResourceGroup \
  --name myVM

az vm resize \
  --resource-group myResourceGroup \
  --name myVM \
  --size Standard_D2s_v5

az vm start \
  --resource-group myResourceGroup \
  --name myVM

Rightsizing and Reserved Instances

If you have purchased Reserved Instances, rightsizing requires extra care. An RI is a billing commitment to a specific SKU family and region. If you resize a VM away from the SKU family covered by your RI, the reservation will not apply and the VM will bill at pay-as-you-go rates — while you continue paying for the unused reservation.

The correct sequence is: rightsize first, confirm the new stable SKU, then purchase reservations. If you already have reservations, check whether the target SKU family is covered by instance size flexibility groups. Most D-series and E-series reservations apply across the entire series (D2s, D4s, D8s, etc.) through the normalisation factor system, so downsizing within the same family does not waste the reservation.