Azure Cost Optimization: Reduce, Reserve, Rightsize

The full discount stack on steady state Azure compute runs to 80 percent below pay as you go. Most estates capture less than a third of it, then lock the waste into their next commitment.

Prepared by Redress Compliance  ·  June 2026  ·  Representative Azure estate scenario (benchmark scenario, not a quote)

Both instruments discount the same compute; they differ in what you commit to. A reservation locks a VM family in a region; a savings plan locks a dollar per hour spend that flexes across families, regions, and eligible compute services. Microsoft pays you more for the narrower promise.

The effective cost ladder below is the planning view we use. The worked numbers model a steady state general purpose VM base (benchmark scenario, not a quote); published maxima vary by SKU and region.

One mechanic decides how the two instruments coexist. When a VM is covered by both, the reservation discount applies first and the savings plan only picks up uncovered usage. Size a savings plan over a base that reservations already cover and you have double committed: the plan bills its dollar per hour anyway.

The decision rule we apply: reservations for the stable core, a savings plan for the variable middle, pay as you go only for the spiky edge. In the worked estate that split is roughly 55, 25, and 20 percent of compute respectively, and total coverage lands inside our target band of 75 to 85 percent.

Rightsizing comes before any commitment purchase. The reason is contractual, not technical: a reservation on an oversized SKU locks the oversizing in for the term. Shrink first, then reserve the smaller footprint.

The guardrail against throttling is evidence, not optimism. We size against 30 days of P95 utilization, never averages. A VM averaging 12 percent CPU with a P95 of 70 percent is not oversized; a VM with a P95 of 18 percent is one full size step too big, and one step down halves its cost.

Two silent billers deserve a named check in every pass. A VM stopped from inside the guest OS keeps billing until it is deallocated from the control plane. And unattached managed disks bill at full rate indefinitely after their VM is deleted.

Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025.

Azure Hybrid Benefit lets you bring Windows Server and SQL Server licenses with active Software Assurance, or subscription licenses, and stop paying the software meter inside the VM rate. It stacks with reservations, and the stack is where the headline numbers come from.

The worked block below models 200 Windows VMs in a 4 vCPU general purpose class (benchmark scenario, not a quote). The compute meter is $200 per VM per month at list; the Windows software meter adds $140.

The license math has a floor most teams miss. Windows Server Hybrid Benefit consumes a minimum of 8 core licenses per VM, so each 4 vCPU machine in this fleet still burns an 8 core allocation: 1,600 core licenses for 200 VMs. On small VMs, the benefit is materially less efficient than the per core arithmetic suggests.

SQL Server is where the exchange rates get interesting. One SQL Server Enterprise core converts to 4 vCores of Azure SQL Managed Instance or Database in the general purpose tier; Standard converts 1 to 1. Enterprise cores pointed at general purpose tiers quadruple their coverage, which is why we map editions before any migration wave.

• Dual use window: Hybrid Benefit allows 180 days of running the same license on premises and in Azure in parallel, which is the migration runway. Use it; it expires per license, not per project.
• Software Assurance is the gate: the benefit requires active SA or subscription licenses. Price the SA renewal against the meter savings; in this fleet the meter saving is $28,000 per month, and the SA renewal on 1,600 Windows Server Standard cores runs well below that.
• Unused on premises licenses are inventory: most estates we baseline hold more eligible Windows and SQL licenses than they apply. The audit takes a week and the benefit applies from the next billing cycle.

The Microsoft Azure Consumption Commitment is a contractual floor: spend the committed amount by the end date or be invoiced for the difference. The interaction nobody models at signature is simple. Every optimization in sections 1 to 3 slows your MACC burn.

Three decrement mechanics matter. Reservation and savings plan purchases decrement the MACC at purchase, pretax, and Azure benefit eligible Marketplace offers decrement 100 percent of the pretax purchase amount. Consumption covered by a reservation does not decrement again at the list rate; the discounted purchase already counted.

The worked scenario: a $30M three year MACC signed against a $12M unoptimized run rate, followed by the 30 percent optimization this paper describes. The optimized estate consumes $8.4M per year (benchmark scenario, not a quote).

The mitigation stack runs in order. First, route eligible third party software through Azure Marketplace; the 100 percent pretax decrement turns existing spend into commitment burn, trimming the gap to $2.4M in the worked table. Second, time reservation purchases inside the term, since they decrement at purchase; third, renegotiate.

Every estate we rebaseline after a one off optimization sprint shows the same decay: the saved percentage erodes by a third within two quarters as new workloads land uncovered, untagged, and unsized. Optimization is a posture, not a project. Three phases make it stick.

The cadence has owners, not dashboards. Coverage decisions sit with one named role, reviewed weekly against the utilization alert floor of 92 percent. Anomaly detection runs on the daily spend feed, and every quarter the commitment portfolio is rebalanced while the reservation exchange window remains open under current policy.

The discipline that protects the next negotiation is the burn report. A single page, monthly: run rate against forecast, coverage against band, MACC decrement against the contract curve. When Microsoft sizes your renewal, you answer from your curve, not theirs.