FinOps Inform
Azure VM cost optimisation: the sequence that saves the most
Discover how effective Azure VM cost optimization can save 10–20% through rightsizing and cleanup before securing discounts.
Fix the waste before you buy the discount by leveraging Azure Cost Management With AI: Rightsizing, Reservations. Rightsizing and idle cleanup come first, because every pound spent buying a Reserved Instance or Savings Plan against an oversized fleet locks in cheaper waste rather than eliminating it. Get the baseline right, then commit.
Run the sequence in that order and the numbers are consistent enough to plan around:
- Month one: rightsizing and cleanup typically recovers 10–20% of compute spend
- On the corrected baseline: commitment discounts add a significant additional reduction, varying by the instrument
- Today's actions: deallocate idle VMs, schedule non-production shutdowns, and run Azure Advisor's cost workbook
Quick stat: Combining rightsizing with Reserved Instances or Savings Plans commonly cuts Azure VM compute spend substantially beyond the initial waste recovery, with some Hybrid Benefit configurations achieving large discounts off pay-as-you-go pricing.
Key Takeaways
Rightsizing and idle cleanup before buying commitments is the single highest-leverage sequence for cutting Azure VM costs.
| Point | Details |
|---|---|
| Fix the baseline first | Rightsize and deallocate idle VMs before purchasing any Reserved Instance or Savings Plan. |
| Expect layered savings | Cleanup typically recovers 10–20% in month one; commitments add 30–65% on the corrected baseline. |
| Validate Advisor recommendations | Cross-check Advisor's flagged VMs against raw Azure Monitor metrics before acting. |
| Watch disk and network waste | Orphaned disks and unattached public IPs keep billing after VM deletion. |
| Get help executing the sequence | Koritsu AI runs a free assessment and only charges a share of verified savings. |
Azure VM cost optimisation: a practical checklist you can act on today
Most engineering teams already know they're overspending on compute. What trips them up is sequencing. Here's the order that actually works, starting with the question every FinOps conversation should open with: is this VM the right size?
1. Decide if a VM is oversized. Look at P95 CPU and memory over a genuine working window, not a snapshot. Don't judge on averages; a nightly batch job will drag the mean down and hide a legitimately busy VM.
2. Understand the deallocate/stopped distinction. A VM marked "Stopped" still reserves compute capacity on the host and keeps billing you. Only "Stopped (Deallocated)" releases the host resource and stops compute charges, though attached disks keep billing regardless of VM state.
3. Lock down provisioning with tags, RBAC, and policy. Enforce mandatory cost-centre and environment tags via Azure Policy at creation time, not retrospectively. Restrict who can provision production-tier SKUs through RBAC role assignments, so a developer testing something can't accidentally spin up a 32-core box and forget about it.
4. Use autoscaling properly. VM Scale Sets should scale on a real signal, CPU, queue depth, or custom metric, not a flat schedule that overprovisions for peak all day.
5. Fix disk and network waste. Downgrade Premium SSD to Standard SSD where latency tolerance allows it, and sweep for orphaned disks and unattached public IPs left behind after VM deletions.
6. Check Spot VM fit. Batch jobs, dev/test environments, and fault-tolerant workloads on AKS agent pools are strong Spot candidates; anything stateful and latency-sensitive isn't.
Pro Tip: Run a "shutdown audit" before you run a rightsizing audit. Half the oversized VMs teams find were meant to be switched off weeks ago and nobody owned the decision.
- Tag everything before you touch sizing
- Validate Advisor's flagged list against raw metrics, not just the recommendation text
- Never resize a production VM without a scheduled restart window
How Azure Advisor and Cost Management find your quick wins
Azure Advisor's underutilisation check samples metrics at 30-minute intervals over a configurable lookback window, between 7 and 90 days, and flags VMs with sustained low CPU against defined thresholds. It's a reasonable starting point, but treat the flagged list as the floor of what's fixable, not the ceiling: Advisor is conservative by design, so extend your own thresholds for a systematic sweep rather than relying solely on its defaults.
The Cost Optimization workbook pulls Advisor items, reservation opportunities, and Savings Plan gaps into one view, and its Quick Fix column applies some changes directly without a separate change ticket.
| Workflow step | What it checks |
|---|---|
| Identify | Advisor lookback window flags sustained low CPU/memory |
| Validate | Cross-check against Azure Monitor raw metrics over 30 days |
| Change | Apply resize or shutdown via portal tutorial |
| Rollback | Keep original size documented for 48 hours post-change |
- Export Advisor recommendations monthly and diff them against last month's list to catch drift
- Never resize without a rollback size noted somewhere your team can find it fast
When should you buy Reserved Instances or Savings Plans?
Reserved Instances lock in a one or three year commitment against a specific VM size or a flexible instance size group, with exchange and cancellation options if your fleet shifts. Azure Savings Plans commit to an hourly spend target instead, applying automatically across VM families and regions, which suits teams whose workload mix changes often.
The numbers make the case for committing, but only once the baseline is correct:
Savings by instrument: Reserved Instances typically cut compute costs by 39–61% versus pay-as-you-go. Savings Plans can reduce eligible compute spend by up to 65%. Stack either with Azure Hybrid Benefit for existing Windows Server or SQL Server licences, and some configurations approach 70–75% off the original PAYG rate.
Choose Reserved Instances when your fleet composition is stable and predictable, and Savings Plans when you run mixed instance families or expect to shift sizes over the commitment term. A tranche approach, buying partial coverage now and expanding quarterly as usage data firms up, reduces the risk of overcommitting while still capturing early savings.
Before any purchase:
- Complete a full rightsizing audit; buying coverage against an oversized fleet locks in the waste at a discount rather than removing it
- Model reservation coverage against 90 days of actual usage, not projected usage
- Check upcoming renewal and retirement dates for any VM series you're about to commit against
- Avoid common reservation mistakes such as committing before consolidation
Governance patterns that stop the savings unravelling
Savings from a rightsizing sprint erode within a quarter if nothing structural changes. Azure Policy can restrict which VM SKUs a subscription is allowed to provision, and enforce tagging at creation so cost allocation doesn't require detective work six months later.
- Use RBAC to limit who can create production-class VMs; most waste starts with a developer given more permission than their task needs
- Build automation runbooks for scheduled start/stop, and pair auto-shutdown with an auto-start trigger so nobody's forced to manually spin a VM back up at 7am
- Configure Cost Management budgets with alert thresholds at 50%, 80%, and 100% of forecast, and link action groups so an alert can trigger an automated remediation, not just an email nobody reads
Disk and storage choices that quietly inflate your bill
Unmanaged disks cost more to operate and complicate backup and scaling, so migrate to managed disks as a baseline hygiene step. Beyond that, the tier decision matters more than most teams realise.
Premium SSD makes sense for latency-sensitive production workloads; Standard SSD covers most general-purpose VMs at a meaningfully lower rate; Standard HDD suits archival or infrequently accessed data only. Snapshots and backups rarely need performance tiers, shift them to Standard Storage and the saving is almost pure margin.
Persistent cost risk: Deallocating a VM stops compute billing, but attached disks keep charging regardless of VM state, and orphaned disks left behind after VM deletion bill indefinitely until someone notices.
- Sweep monthly for disks with no attached VM
- Sweep for unattached public IP addresses; they bill even when idle
- Check every snapshot's storage tier before assuming it's cheap
Where do Spot VMs fit into an optimisation plan?
Spot VMs offer the deepest discounts Azure sells, but they come with eviction risk, so the workload has to tolerate interruption without drama.
- Suitable: batch processing, CI/CD runners, dev/test, fault-tolerant AKS agent pools
- Unsuitable: stateful databases, anything with a hard latency SLA
- Handle eviction with checkpointing or externalised state, never assume a job will finish uninterrupted
- Use Spot Priority Mix in VM Scale Sets to blend Spot and standard instances, keeping a guaranteed floor of standard capacity while Spot absorbs the burst
Architected properly, Spot capacity for the right workload class is one of the more durable patterns once the eviction handling is solid.
A two-month sequence for measurable Azure VM cost savings
Here's the operational cadence we run with engineering teams, because a savings target without a calendar rarely survives contact with the next sprint.
- Weeks 1 to 2: Classify every VM by spend, tag ownership against a named person or team, and flag the top 20% by cost for review first.
- Weeks 3 to 4: Fix the fixable layer, shutdown, resize, delete, and enforce tagging and RBAC so new waste doesn't reopen the gap you just closed.
- Weeks 5 to 8: Buy commitments in tranches against the corrected baseline, and monitor reservation utilisation weekly rather than at renewal time.
Pro Tip: Assign an owner per high-spend resource group during classification, not after. Decisions without an accountable owner stall for weeks.
Continuous monitoring is what keeps the fleet from drifting back to where it started, which is exactly the gap our AI agent Kori is built to close.
How to measure Azure VM savings and reservation coverage
Track total compute spend, committed versus on-demand percentage, Spot share of compute, idle VM count, and orphaned disk spend as a monthly dashboard, not a quarterly report.
A useful FinOps query pattern splits EffectiveCost by PricingCategory, OnDemand, Committed, Dynamic, and computes committed coverage as a percentage per resource group.
| Metric | Reporting cadence |
|---|---|
| Committed vs on-demand % | Weekly |
| Idle VM count | Weekly |
| Reservation utilisation | Weekly |
| Orphaned disk spend | Monthly |
What engineers get wrong and what actually delivers savings
Most teams buy commitments before they finish rightsizing, which is the single costliest sequencing error I see. The organisational fix, ownership per VM and working start/stop automation, matters more than any tooling choice. We've watched this order swap deliver a documented 52% reduction for a UK bidding platform.
— Kori
Get a free assessment of your Azure VM spend
You've now got the sequence. Executing it across a large fleet, correctly, every month, is the part that consumes engineering time you don't have. Koritsu AI runs the rightsizing and commitment-timing work described above as a hands-on engagement, and we only take a share of the savings we actually verify against your billing, no fee if we find nothing.
The UK bidding platform case study shows what that looks like in practice: a 52% reduction achieved by running exactly this rightsizing-then-commit sequence, with Kori continuously monitoring afterwards so the fleet doesn't drift back into waste. If you want the same audit run against your own environment, start a free assessment and see what your baseline actually costs before you buy another reservation.