Skip to content
Costframe
Learning library / Practical guides

How to right-size Azure VMs

Right-sizing an Azure VM means selecting a SKU that meets observed and expected workload demand with acceptable headroom. Low CPU is only a candidate signal. Review memory, disk and network throughput, latency, burst behavior, licensing, architecture constraints, availability, and planned demand before changing production.

Costframe practical guide · 3 min read

Write the target SKU acceptance criteria

Match capacity to workload constraints

01

Observation window

Use at least 30 days when it captures normal cycles; extend it for month-end, quarterly, or seasonal workloads.

02

Candidate threshold

Sustained low CPU may start review, but no universal percentage proves a VM is oversized.

03

Constraint match

The target SKU must satisfy memory, disk limits, network limits, accelerators, architecture, region, availability, and licensing.

04

Net savings

Monthly saving = current net monthly cost − target net monthly cost, adjusted for commitments and dependent costs.

A procedure with accountable owners

  1. 1 / Collect representative metrics

    Inspect percentile and maximum CPU, available memory where instrumented, disk IOPS/throughput, network, latency, and restarts.

    Owner
    Platform + workload owner
    Cadence
    Monthly
    Verify
    Window covers known peaks and business cycles.

  2. 2 / Select compatible candidates

    Filter regional SKUs by required features and limits before comparing price.

    Owner
    Cloud engineering
    Cadence
    Per candidate
    Verify
    No hard capability is lost.

  3. 3 / Test and schedule

    Benchmark in a safe environment, define success and rollback thresholds, then use the normal change process.

    Owner
    Workload owner
    Cadence
    Per change
    Verify
    Test results and approval are recorded.

  4. 4 / Observe after change

    Compare service indicators and billed cost across a representative post-change window.

    Owner
    SRE + finance
    Cadence
    After change
    Verify
    SLOs hold and net cost falls as expected.

Illustrative candidate review

CPU
P95 11%; max 38% over 35 days
Memory
Peak 54%; instrumentation confirmed
Disk / network
Below target SKU limits with 30% headroom
Decision
Candidate only; stage and benchmark before approval

Thresholds are illustrative, not universal production rules.

Check the workload constraints that CPU does not show

Confirm the candidate SKU's memory, disk throughput, network limits and availability before comparing its rate. Workloads with batch peaks or memory pressure need more than average CPU. When a required metric is unavailable, ask the owner for application evidence and treat the size recommendation as needing review.

Test the proposed size against representative demand and retain a rollback path. A lower catalog rate is an estimate until the change is implemented and billed cost is measured on the relevant customer pricing basis. Include any new storage or licensing cost in the comparison.

Your next task

Write the target SKU acceptance criteria

For one candidate VM, record peak memory, IOPS, throughput and service latency alongside CPU. If memory is not instrumented, obtain workload evidence first. Define the test, maintenance window and rollback trigger before selecting the cheaper size.

Review a VM rightsizing candidate

What not to do

  • ×Using average CPU as the only signal
  • ×Ignoring memory because the platform metric is unavailable
  • ×Assuming a smaller SKU has the same IOPS and network limits
  • ×Applying the change without a rollback trigger

Sources and further reading

Microsoft: virtual machine sizes

Investigate changes in cloud cost

Continue learning