How to review an Azure oversized virtual machine
A VM is a rightsizing candidate when observed demand and known workload constraints may fit a less expensive compatible SKU with safe headroom. No single CPU threshold proves a production VM is oversized.
Compare one compatible target VM sizeWho reviews this signal?
- Accountable owner
- Workload owner / SRE
- Review cadence
- Monthly
Check observation dates and read-only scope. Your team approves and implements changes outside Costframe.
How this finding happens
- →Initial capacity includes a large safety margin that is never revisited.
- →Workload demand falls after migration, architecture change, or customer churn.
- →The SKU was selected for one constraint—memory, IOPS, network, GPU, licensing—that is no longer required.
Virtual machine · West Europe
14 daily readings · not a capacity guarantee
Read all 14 CPU samples
| Day | CPU |
|---|---|
| 1 | 6% |
| 2 | 11% |
| 3 | 8% |
| 4 | 7% |
| 5 | 16% |
| 6 | 10% |
| 7 | 8% |
| 8 | 5% |
| 9 | 7% |
| 10 | 22% |
| 11 | 12% |
| 12 | 8% |
| 13 | 6% |
| 14 | 9% |
- Resource and billing context
- 14-day CPU sample
- Configured team: Developer experience
- Memory utilization
- Disk IOPS and performance
Confirm peak build needs, dependencies, a safe test and rollback before changing capacity.
Collected evidence and verification limits
Checked when available
- ✓Current VM SKU, region, OS, availability and architecture constraints
- ✓CPU percentile and maximum across a representative window
- ✓Memory, disk, network, latency, and restart signals where available
- ✓Current and compatible target-SKU prices on the same rate basis
Not always verifiable
- —Guest memory is not universally available without appropriate monitoring.
- —Historical telemetry may omit rare month-end or seasonal peaks.
- —Lower SKUs can change disk, network, accelerator, and availability limits—not only vCPU and RAM.
Missing or stale evidence is a limitation, not a passed check.
Why this finding might be wrong
These conditions lower confidence or require manual owner review before action.
- Memory-bound or license-bound workload with low CPU
- Standby, failover, or disaster-recovery capacity
- Batch workload whose critical peaks fall outside the window
- Latency-sensitive workload that needs deliberate headroom
Plan the change and recovery path.
- Confirm the observation window covers releases, month-end, weekends, and known peaks.
- Filter candidate SKUs by every hard constraint before comparing price.
- Benchmark the target in staging or a safe replica and define rollback thresholds.
- Schedule the resize through the workload’s change process and observe service indicators.
Rollback / recovery
Return to the prior SKU if latency, errors, throttling, queue depth, memory pressure, or workload-specific SLOs breach the agreed threshold.
How savings are calculated
Estimated net monthly saving = current net VM cost − compatible target net VM cost. Include licensing and dependent-resource changes when material.
Do not quote a quantified saving when the billing scope, pricing basis or required workload evidence is incomplete or stale. Treat a modeled amount as estimated until suitable billed outcomes support it.
Check the billed outcome
Post-change SLOs remain healthy and billed compute cost declines over a comparable window.
Compare one compatible target VM size
Build a current-versus-target worksheet covering memory, disk IOPS, network limits, licensing and regional availability. Include batch peaks and a rollback threshold. Missing memory telemetry is a reason to obtain workload evidence, not to assume unused capacity.
Follow the VM sizing procedureIf the owner cannot resolve a dependency or recovery requirement, keep the candidate in review rather than treating it as approved.