Reduce Azure spending through rightsizing, reservations, governance, monitoring, and FinOps practices

FinOps GuideCost OptimizationReservations & Savings PlansHybrid Benefit

Azure Cost Optimization Best Practices: Monitor,
Reduce, and Control Cloud Spend with FinOps

"Reservations or Savings Plans?" is the wrong question, and it's the one almost every cost-optimization article asks. Microsoft's own discount engine doesn't make you choose — it applies Reservations first, then Savings Plans to what's left, then lets Hybrid Benefit stack on top of both. The teams getting the deepest discounts aren't picking a winner between these tools. They're layering all three, in the right order, on top of infrastructure that's been right-sized first.

32% wasted

Share of enterprise cloud spend reported as waste in Flexera's 2025 State of the Cloud report — idle resources, oversized VMs, missed discounts

RI first, then SP

Azure's exact discount stacking order: Reserved Instances apply to matching usage first; Savings Plans cover whatever's left

80%+ combined

Stacking Azure Hybrid Benefit on top of a Reservation or Savings Plan can push combined discounts past 80% on eligible Windows/SQL workloads

Cyclical, not linear

The FinOps Foundation's three phases — Inform, Optimize, Operate — repeat continuously. FinOps is a practice, not a project with an end date

Table of Contents

1. 01FinOps Isn't a Project — It's the Inform, Optimize, Operate Loop
2. 02Where the Waste Actually Comes From
3. 03Right-Size First: Why Purchase Order Matters
4. 04Reserved Instances vs Savings Plans — Why "vs" Is the Wrong Frame
5. 05The Discount Stacking Order Most Teams Don't Know
6. 06Azure Hybrid Benefit: The Discount That Stacks on Top
7. 07Tagging and Cost Allocation: Seeing Where the Money Goes
8. 08Budgets, Alerts, and Anomaly Detection
9. 09Step-by-Step: Building a FinOps Practice
10. 10Anti-Patterns
11. 11Frequently Asked Questions

Most Azure cost optimization content collapses into a single recurring question — Reserved Instances or Savings Plans, right-sizing or reservations, tagging or automation — as if cost control were a menu you pick one item from. It isn't, and the actual FinOps Foundation framework this guide is built around treats it explicitly as a continuous loop, not a one-time decision: gain visibility into what you're spending and why (Inform), act on that visibility to eliminate waste and apply the right discount instruments (Optimize), and then operate that improved state continuously rather than treating the optimization as finished (Operate) — before the cycle repeats, because your infrastructure, usage, and pricing options all keep changing. The organizations getting real, durable savings aren't the ones that found the single best discount mechanism. They're the ones running this loop consistently, layering multiple discount tools correctly, and treating cost as an operational metric monitored monthly rather than a line item reviewed once a year.

Figure 1 — The FinOps loop: Inform, Optimize, Operate — cyclical, not a one-time project

The FinOps Foundation defines three phases that feed into each other continuously: Inform builds visibility into actual spend, Optimize acts on that visibility to reduce waste and apply the right discount instruments, and Operate tracks the improved state against business goals on an ongoing basis. The loop closes back to Inform because infrastructure, usage patterns, and Azure's own pricing offers all continue to change — treating any single pass through this loop as "done" undoes the value of running it at all.

01FinOps Isn't a Project — It's the Inform, Optimize, Operate LoopFramework

FinOps (Financial Operations) is a cloud financial management discipline combining people, process, and technology to maximize the business value extracted from cloud spend — and the FinOps Foundation's own definition is explicit that its three phases are cyclical, not a linear sequence with an endpoint.

Phase	What it covers	Typical activities
Inform	Visibility into cloud spending	Tagging, cost allocation, accurate forecasting, showback/chargeback reporting
Optimize	Acting on that visibility	Right-sizing, eliminating idle resources, applying commitment-based discounts
Operate	Continuous governance	Tracking usage against business goals, budgets and alerts, sharing results with stakeholders

The scope of FinOps as a discipline has also expanded beyond its original cloud-only framing — the FinOps Foundation now applies the same practice, tooling, and cultural habits across public cloud platforms (Azure, AWS, GCP), SaaS spend, data platforms like Snowflake and Databricks, and increasingly AI infrastructure and workload costs specifically. The core loop doesn't change; only the scope of what it's applied to expands.

This guide's structure follows the loop deliberately

Sections 2 and 7-8 map to Inform (understanding where spend goes, building visibility through tagging and monitoring). Sections 3 through 6 map to Optimize (the specific mechanisms — right-sizing, Reservations, Savings Plans, Hybrid Benefit). Section 9's step-by-step guide is built to establish the Operate phase as an ongoing practice, not a final step to complete once and move on from.

02Where the Waste Actually Comes FromInform

Before optimizing anything, it's worth being precise about what's actually driving unnecessary spend — the categories are consistent across most organizations' cloud estates.

Waste category	Typical savings opportunity
Oversized/underutilized VMs	15-25% savings from right-sizing to actual utilization
Non-production resources running 24/7	50-70% savings from auto-shutdown scheduling on dev/test workloads
Missed commitment discounts	Up to 65% (Savings Plans) or 72% (Reservations) on eligible, stable compute usage
Orphaned/idle infrastructure	Unattached disks, idle public IPs, forgotten test resources — pure elimination, not a discount
Unapplied Azure Hybrid Benefit	Additional savings on top of compute discounts, for eligible Windows Server/SQL Server licensing

Industry reporting puts total enterprise cloud waste at roughly a third of spend

Flexera's 2025 State of the Cloud report found that 32% of cloud spend is wasted across enterprises — a figure consistent with other industry estimates that, without deliberate cost governance, organizations typically overspend on cloud by 30-45% through the categories above. For a mid-to-large Azure estate, this translates to a genuinely significant, recoverable amount, which is the underlying reason FinOps as a discipline exists — the waste is real, identifiable, and addressable with known techniques, not a vague or unavoidable cost of doing business in the cloud.

03Right-Size First: Why Purchase Order MattersOptimize

This is a sequencing mistake specific enough to name directly: purchasing Reserved Instances or Savings Plans against your current resource sizing, before right-sizing, locks in a discount on waste rather than eliminating the waste itself.

• Right-sizing removes the waste; commitment discounts discount whatever's left. A VM running at 15% average CPU utilization, downsized appropriately, might need a smaller instance size entirely — buying a 3-year reservation against the oversized instance first means committing to paying a discounted rate on capacity you never needed.
• The recommended sequence, consistently cited across current guidance: analyze 30-90 days of usage in Cost Management to understand your actual compute baseline, act on right-sizing recommendations first, and only then purchase commitment discounts against the corrected baseline.
• Start conservative on commitment size. Commit to roughly 60-70% of your corrected baseline initially, rather than 100%, and increase incrementally as confidence in the baseline's stability grows — this reduces the risk of over-committing against a baseline that later shifts.

Commitments are genuinely hard to walk back — the sequencing mistake compounds

Both Reserved Instances and Savings Plans, once purchased, generally cannot be cancelled or modified for the remainder of their 1-year or 3-year term — this makes the right-sizing-first sequence not just a nice-to-have but a real risk-management practice. A reservation purchased against an oversized VM locks in discounted waste for the full commitment term; correcting the sizing afterward doesn't undo the commitment, and unused reservation capacity from a subsequent right-sizing effort is simply forfeited value.

04Reserved Instances vs Savings Plans — Why "vs" Is the Wrong FrameCorrection

Both are commitment-based discount instruments requiring a 1-year or 3-year term in exchange for reduced rates — but they work on fundamentally different axes, and Microsoft explicitly supports and recommends using both simultaneously rather than choosing one exclusively.

Aspect	Reserved Instances	Savings Plan for Compute
Commitment type	Specific VM family, size, and region	A fixed hourly dollar spend amount
Discount range (illustrative)	Up to 72% — deeper, but less flexible	11-65% (Microsoft's own published estimate range)
Flexibility across VM families/regions	None — discount only applies if configuration matches exactly	Full — applies automatically across VM families, regions, and eligible services
Capacity guarantee	Optional capacity reservation available	Not offered
Service coverage	VMs, and select database services (separately)	Broader — VMs (nearly all series), AKS node pool compute, Azure Virtual Desktop session hosts, Databricks VM compute, App Service Premium v3, Container Instances, Functions Premium
Best fit	Stable, unchanging, 24/7 production workloads	Evolving architectures, frequent scaling, workloads that move across VM families or regions

Microsoft explicitly supports using both at the same time — this isn't a workaround, it's the recommended pattern

Reserved Instances and Azure reservations continue to be available for purchase alongside Savings Plans, and Microsoft's own guidance states plainly that you may leverage both Reserved Instances and the savings plan at the same time. The practical pattern current FinOps guidance converges on: purchase Reserved Instances for your most stable, predictable workloads — the VMs and databases you're confident will run unchanged for the full term — and use a Savings Plan to cover the remaining compute baseline, where specific resources may change but the overall spend level is predictable.

The capacity guarantee distinction matters for DR and compliance-sensitive workloads specifically

Savings Plans do not infer capacity guarantees — they discount usage but don't reserve physical capacity in a target region. Reserved Instances can optionally include a capacity reservation that guarantees the reserved capacity is actually available when needed. For workloads where confirmed capacity availability matters specifically — disaster recovery failover targets, or compliance-mandated minimum capacity — Reserved Instances with capacity reservation is the correct instrument, not a Savings Plan, regardless of which offers the better raw discount percentage for that workload.

Figure 2 — The exact discount stacking order: Reservation first, Savings Plan on the remainder, Hybrid Benefit on top

Reservations apply first to any matching usage, taking the deepest available discount. Savings Plans then apply only to compute usage a Reservation didn't already cover — and within the Savings Plan's commitment, Azure applies the discount to the highest-savings-rate usage first, maximizing the value extracted from the committed hourly spend. Azure Hybrid Benefit, where eligible, then removes the separate OS licensing surcharge on top of whichever compute discount already applied — three genuinely additive layers, not three competing options.

05The Discount Stacking Order Most Teams Don't KnowCorrection

This is a precise, documented mechanic that materially affects how to think about purchasing both instruments together: when both a Reserved Instance and a Savings Plan could apply to the same usage, Azure applies the Reservation first, and the Savings Plan only picks up whatever usage the Reservation didn't already cover.

Rule	What it means in practice
Reservations apply before Savings Plans	A VM matching an active reservation gets the reservation's discount; the Savings Plan commitment is preserved for other usage
Within a Savings Plan, highest-rate usage is covered first	If two VMs are eligible in the same hour at different discount rates, the Savings Plan commitment is applied to the higher-rate VM first, maximizing value extracted from the commitment
Unused commitment is forfeited, not refunded	If actual usage falls below the committed hourly spend, the difference isn't banked or refunded — it's simply lost value for that hour
Usage above commitment bills at standard rates	Once the Savings Plan's hourly commitment is fully consumed, additional usage in that hour is billed at normal pay-as-you-go rates, not free

This ordering is exactly why "reserve the stable stuff, savings-plan the rest" works as a strategy

Understanding this stacking order explains precisely why the "Reservations for stable workloads, Savings Plan for the variable baseline" pattern from Section 4 is the mathematically correct approach, not just a reasonable-sounding compromise: Reservations claim the deepest discount on the portion of your estate that's genuinely predictable, and the Savings Plan's flexible commitment then covers everything else without needing to guess which specific VMs will be running in a given hour — because the discount follows the usage automatically, applying itself to whatever's most valuable to discount first.

06Azure Hybrid Benefit: The Discount That Stacks on TopOptimize

Azure Hybrid Benefit is the third layer in Figure 2's stack, and it's worth understanding as structurally different from Reservations and Savings Plans — it doesn't discount compute, it eliminates a separate license charge entirely.

• What it does. If you have existing Windows Server or SQL Server licenses covered by Software Assurance, Azure Hybrid Benefit lets you apply those licenses to Azure VMs instead of paying Azure's separate Windows/SQL licensing surcharge.
• Why it stacks additively. A Reservation or Savings Plan discounts the underlying VM hardware/compute cost. Hybrid Benefit separately eliminates the OS or database licensing charge layered on top of that compute cost. These are two different cost components, discounted independently — which is exactly why combining them produces a larger combined discount than either alone.
• The combined result. Applied together on eligible Windows or SQL workloads, the combined discount from a compute commitment plus Hybrid Benefit can reach 80% or more off the full pay-as-you-go rate.

This is a genuinely underused discount, specifically because it requires a separate, deliberate configuration step

Unlike Reservations and Savings Plans, which are purchasing decisions made once, Azure Hybrid Benefit has to be actively applied per eligible resource — it's a checkbox or configuration setting, not something that activates automatically just because you own the licenses. Organizations with existing Windows Server or SQL Server Software Assurance licenses that haven't explicitly enabled Hybrid Benefit on their eligible Azure VMs are leaving a real, immediately available discount unclaimed — this is one of the highest-value, lowest-effort items to check during the Inform phase of the FinOps loop.

07Tagging and Cost Allocation: Seeing Where the Money GoesInform

None of the discount instruments in Sections 4-6 matter if nobody can answer the basic question "which team, project, or business unit is actually generating this cost" — tagging is the mechanism that makes cost visible at the level decisions actually get made.

Tag category	Purpose
Cost center / business unit	Enables showback or chargeback reporting to the teams actually generating spend
Environment (prod/dev/test)	Distinguishes workloads eligible for aggressive optimization (auto-shutdown, spot pricing) from production workloads that aren't
Application/workload owner	Gives every resource a named, accountable owner — critical for identifying orphaned infrastructure
Project or initiative	Enables cost tracking against specific time-bounded projects, separate from ongoing operational spend

Enforce tagging with Azure Policy, don't rely on manual discipline

A tagging standard that depends on every engineer remembering to apply tags correctly, every time, at deployment, degrades in practice — Azure Policy can enforce required tags at deployment time, denying or flagging resources that don't meet the standard, which is a meaningfully more durable approach than documentation and hoping. This is the same governance-at-scale principle that applies to security policy enforcement — a rule too important to leave to individual discipline belongs at a layer that can't be bypassed.

08Budgets, Alerts, and Anomaly DetectionOperate

The Operate phase of the FinOps loop depends on knowing when spend deviates from expectations — before the monthly bill arrives as a surprise, not after.

• Budgets with proactive alerts. Set budgets at the subscription, resource group, or management group level, with alert thresholds (e.g., 80%, 100%, 120% of budget) that notify the right stakeholders before spend becomes a crisis.
• Anomaly detection. Cost Management's anomaly detection surfaces unusual spend patterns automatically — a sudden spike from a misconfigured autoscale rule, an accidentally-provisioned expensive SKU, or a runaway resource — without requiring someone to notice it manually in a dashboard.
• Regular reporting to stakeholders. The Operate phase explicitly includes sharing results with stakeholders — cost visibility that stays entirely within a platform team's dashboards doesn't drive the organizational behavior change FinOps is meant to enable.

Alerts should reach the people who can actually act, not just a shared inbox nobody monitors

A budget alert that fires into a distribution list nobody actively watches provides the appearance of governance without the substance of it. Route cost anomaly and budget alerts to the specific team or individual who owns the resource generating the spend — tied back to the tagging structure from Section 7 — so the alert reaches someone who can actually investigate and act, not just someone who receives another notification to eventually triage.

09Step-by-Step: Building a FinOps PracticeHow-To

1. Establish tagging standards and enforce them via Azure Policy

   Define required tags (cost center, environment, owner) before optimizing anything — you can't allocate or prioritize savings work without knowing which team owns which spend.

2. Analyze 30-90 days of usage in Cost Management to build an accurate baseline

   This baseline is the foundation for every subsequent decision — right-sizing targets, commitment purchase sizing, and anomaly detection thresholds all depend on it being accurate.

3. Act on Azure Advisor's right-sizing recommendations first, before any commitment purchase

   Eliminate oversized and idle resources against the corrected baseline before purchasing Reservations or Savings Plans — per Section 3, purchasing against uncorrected sizing locks in discounted waste.

4. Check Azure Hybrid Benefit eligibility across your Windows/SQL estate

   Confirm which eligible VMs don't yet have Hybrid Benefit applied — this is immediately available savings with minimal effort, independent of any commitment decision.

5. Purchase Reserved Instances for your most stable, predictable workloads

   Target the VMs and databases you're confident will run unchanged for the commitment term — the always-on production infrastructure that isn't going to change VM family or region.

6. Purchase a Savings Plan sized to 60-70% of your remaining, more-variable compute baseline

   Cover the compute spend that's predictable in aggregate but variable in specific configuration — start conservative and increase the commitment incrementally as confidence grows.

7. Configure budgets and alerts at the subscription or resource-group level, routed to actual owners

   Tie alert routing back to the ownership tags from Step 1, so notifications reach someone who can investigate and act, not a shared inbox.

8. Enable anomaly detection and review it as a regular operational practice

   Don't treat anomaly detection as a set-and-forget feature — build reviewing flagged anomalies into a recurring cadence, whether weekly or monthly.

9. Schedule a recurring review to close the loop back to Inform

   Monthly or quarterly, re-run the usage analysis, re-check commitment utilization against actual usage, and re-evaluate whether Reservation/Savings Plan sizing still matches reality — this is what makes FinOps a practice rather than a one-time project.

10Anti-PatternsTraps

Anti-pattern	Why it feels right	Why it isn't
Choosing either Reservations OR Savings Plans, treating them as competing options	"Pick the one with the better discount"	Microsoft explicitly supports and recommends layering both — Reservations for stable workloads, Savings Plans for the variable remainder
Purchasing commitment discounts before right-sizing	"Lock in savings now, optimize later"	Locks in a discounted rate on waste for the full 1-3 year term — right-sizing first is what current guidance consistently recommends
Committing 100% of current baseline to a Savings Plan immediately	"Maximize the discount from day one"	Over-commits against a baseline that may shift — start at 60-70% and increase incrementally as confidence grows
Leaving Azure Hybrid Benefit unapplied on eligible VMs	"We already have a Reservation/Savings Plan discount"	Hybrid Benefit is a separate, additive discount on the licensing component — not applying it leaves real, immediately available savings unclaimed
Treating a cost optimization initiative as a completed, one-time project	"We did the FinOps work last quarter"	The FinOps loop is explicitly cyclical — infrastructure, usage, and pricing all keep changing, and yesterday's right-sizing becomes today's waste as workloads evolve
Routing cost alerts to a shared inbox nobody actively monitors	"At least the alert exists"	An alert nobody acts on provides the appearance of governance without the substance — route to specific, accountable owners tied to tagging

Key Takeaways

→FinOps is a continuous loop, not a project with an end date. Inform, Optimize, Operate feed into each other and repeat — treating any single pass as "done" undoes the value of running it.

→Right-size before buying commitment discounts, not after. A Reservation or Savings Plan purchased against oversized infrastructure locks in a discount on waste for the full term.

→Reservations and Savings Plans aren't competing options — Microsoft recommends layering both. Reservations for stable, predictable workloads; Savings Plans for the variable remainder.

→The discount stacking order is fixed: Reservation first, Savings Plan on the remainder, Hybrid Benefit on top of both. Understanding this order is what makes the "layer both" strategy mathematically correct, not just reasonable-sounding.

→Azure Hybrid Benefit is a separate, additive discount most organizations under-claim. It requires deliberate configuration per resource — check eligibility explicitly rather than assuming it's automatic.

→Neither Reservations nor Savings Plans can be cancelled once purchased. Start conservative (60-70% of baseline), and treat the purchase decision with the seriousness a multi-year commitment deserves.

→Tagging and alert routing only work if they reach accountable owners. Visibility that stays in a platform team's dashboard, or alerts that land in an unmonitored inbox, don't drive the behavior change FinOps depends on.

Frequently Asked Questions

Should I choose Azure Reserved Instances or Savings Plans?

Rather than choosing one exclusively, current guidance and Microsoft's own documentation recommend using both together, since they're explicitly designed to be layered — Azure applies Reserved Instance discounts first to any matching usage, then Savings Plans cover whatever compute usage isn't already covered by a reservation. The practical pattern most FinOps guidance converges on: purchase Reserved Instances for your most stable, predictable, always-on workloads (the VMs and databases you're confident will run unchanged for the commitment term, which can reach discounts up to roughly 72%), and use a Savings Plan — committed to a flexible hourly dollar amount rather than a specific VM configuration — to cover your remaining, more variable compute baseline (with published Microsoft savings estimates in the 11-65% range). This combination typically delivers a higher overall effective discount than committing exclusively to either instrument alone.

In what order does Azure apply Reserved Instance and Savings Plan discounts?

Reserved Instances are applied first, to any usage that matches an active reservation's VM family, size, and region. Savings Plans are then applied only to eligible compute usage that wasn't already covered by a reservation — the Savings Plan commitment isn't "spent" on usage a reservation already discounted. Within the Savings Plan itself, if multiple eligible resources are running in the same hour at different discount rates, Azure applies the commitment to the highest-discount-rate usage first, which maximizes the value extracted from the committed hourly spend. This ordering is precisely why layering both instruments (rather than choosing one) works mathematically: reservations claim the deepest available discount on your genuinely stable, predictable usage, and the Savings Plan's flexible commitment then covers everything else without requiring you to predict exactly which resources will be running when.

Why should I right-size my Azure resources before purchasing Reserved Instances or Savings Plans?

Because both instruments generally cannot be cancelled or modified once purchased for the remainder of their 1-year or 3-year term, purchasing a commitment discount against your current, potentially oversized resource configuration locks in a discounted rate on waste for the full commitment period rather than eliminating that waste. Current FinOps guidance consistently recommends the opposite sequence: analyze 30-90 days of actual usage in Azure Cost Management to establish a genuine baseline, act on Azure Advisor's right-sizing recommendations to correct oversized or underutilized resources first, and only then purchase Reserved Instances or Savings Plans sized against the corrected baseline. Buying a 3-year reservation for an oversized VM, then right-sizing it afterward, doesn't undo the original commitment — it typically means the reservation capacity goes partially unused for the remainder of its term, forfeiting value rather than realizing it.

What is Azure Hybrid Benefit, and does it work alongside Reserved Instances or Savings Plans?

Azure Hybrid Benefit lets organizations with existing Windows Server or SQL Server licenses covered by Software Assurance apply those licenses to Azure VMs instead of paying Azure's separate Windows Server or SQL Server licensing surcharge. It works alongside — and stacks additively with — both Reserved Instances and Savings Plans, because it discounts a genuinely separate cost component: Reservations and Savings Plans discount the underlying compute/hardware cost, while Hybrid Benefit eliminates the OS or database licensing charge layered on top of that compute cost. Applied together on eligible Windows or SQL workloads, the combined discount from a compute commitment plus Hybrid Benefit can reach 80% or more off the full pay-as-you-go rate. Because Hybrid Benefit requires deliberate configuration per eligible resource rather than activating automatically, it's one of the most commonly under-claimed discounts — worth checking explicitly across your Windows/SQL estate rather than assuming it's already applied.

Related FAVRITE Articles

• The PTU Math Trap: When to Pivot from Pay-As-You-Go to Provisioned Throughput
• How to Design Azure Landing Zones: The Enterprise Architecture Blueprint
• The Runaway Vector Index Bill: Tuning Vector Dimensions in Azure Cosmos DB
• Azure Availability Set vs Availability Zone: The Complete Guide