Azure Reservations and Savings Plans: Coverage Is a Moving Target

The renewal meeting is on the calendar. Finance has one question: "Should we buy more reservations?" It sounds like a purchasing decision, but it is really a data question, and the honest answer in most rooms is "we don't actually know our current utilization."

That answer is expensive in both directions. Commit to too little and your steady-state compute runs at pay-as-you-go rates it never needed to pay. Commit to too much and you have prepaid for capacity that no workload consumes; a reservation at 60% utilization is not a discount, it is a bill for the missing 40%. Either mistake compounds monthly for a one- or three-year term.

And unlike most cost problems, this one has a deadline. Commitments expire, and an expired reservation silently reverts its workloads to full price while everyone assumes the discount is still working.

The Problem: A Commitment Is Static, Your Fleet Is Not

You size a reservation against the environment you have on purchase day. Then the environment does what environments do: workloads migrate to different VM families, a project moves to AKS on different SKUs, a datacenter consolidation shifts regions, a team right-sizes the exact instances the reservation was scoped to. The commitment stays put while the usage it was matched against drifts away.

That drift is invisible day to day because:

• Utilization decays quietly. Nothing alerts you when a reservation slides from 98% to 71% because a workload moved. The wastage just accrues.
• Nobody owns expiry. Renewal decisions need lead time, but expiration dates live in a portal blade nobody visits until after the lapse.
• Shared scope obscures accountability. A shared-scope reservation is consumed by whichever subscriptions match. Good for utilization, bad for answering "whose budget does this belong to?"

Checking Utilization the Manual Way

The data exists natively. In the portal, Cost Management > Reservations lists each reservation with its utilization percentage, and clicking into one shows the trend over time. Savings plan utilization lives in its own blade under Cost Management. Between them you can audit every commitment you own, one at a time.

Two things to understand while you are in there:

Reservations versus savings plans is a flexibility trade. A reserved instance commits to a specific instance family and region, and pays you back with a deeper discount. A savings plan commits to an hourly dollar amount of compute spend and flexes across regions and instance families, at a shallower discount in exchange for that flexibility. (Exact discount percentages vary by term, SKU, and region; verify current numbers against the Azure pricing pages rather than trusting any blog post, this one included.) The practical rule: reservations for the compute you are certain about, savings plans for the compute that moves.

Use the amortized view, not the actual view. In cost analysis, the actual-cost view books a reservation purchase as a lump sum on purchase day and then shows the covered usage as free, which makes trends unreadable. The amortized view spreads the purchase across the term, so you can see what your commitments effectively cost per day and compare it fairly against pay-as-you-go.

This works, and before any purchase decision you should spend an hour in those blades. But notice the shape of what you get:

1. Per-reservation numbers, no fleet picture. The portal tells you reservation #14 is at 82%. It does not tell you what share of your total eligible compute spend is covered, which is the number the renewal meeting actually needs.
2. Backward-looking only. Utilization history shows drift after the waste has accrued. Nothing projects forward when usage starts sliding.
3. Expiry tracking is a calendar problem. The dates are listed, but turning them into timely renewal decisions means someone maintains reminders by hand, forever.
4. Chargeback math is on you. Attributing a shared-scope commitment back to the subscriptions that consumed it means exporting data and building the join yourself.

How StratoLens Keeps Score for You

StratoLens pulls every Reserved Instance and Savings Plan in the tenant into one dashboard and watches the numbers so nobody has to remember to:

• One tenant-wide inventory instead of forty subscription-scoped portal visits, with utilization for every commitment in one place.
• Multi-window utilization trends. Azure-reported 1-day, 7-day, and 30-day figures, sourced from Azure's own hours-based data, so the numbers match what the portal says and drift shows up in days.
• Three kinds of alerts: purchase recommendations where coverage is thin, underutilization warnings when a commitment drops below a configurable threshold (85% by default), and expiring-soon warnings on a configurable lead time (90 days by default), which turns renewals from an emergency into a calendar entry.
• Shared-scope attribution. Consumption is mapped back to the subscriptions using each shared commitment, so chargeback stops being a spreadsheet project.
• Realized savings tracking. When an underutilized commitment gets fixed, StratoLens records the savings delivered, which is how the FinOps team proves the work paid off.

Because StratoLens is deployed into your own Azure tenant, the commitment and billing data behind all of this stays in your subscription, under your controls.

Treat Commitments Like a Portfolio

Reservations and savings plans are financial instruments sitting on top of infrastructure, and they deserve the same periodic review a portfolio gets: utilization this month, expirations this quarter, coverage gaps worth buying against. The portal blades above are a fine quarterly ritual. If you would rather have the watching, the alerting, and the chargeback math handled continuously, that is what Commitment Coverage in StratoLens is built for.