Multi-Cloud Commitment Management: A Practical Guide

Key Takeaways

• What it is: Multi-cloud commitment management treats the commitment-based discounts you buy separately on each cloud as one portfolio.
• Why it's harder now: Commitments can't move between clouds, and exit options differ, with Azure ending exchanges for many new reservations in 2027.
• The central decision: Size each commitment against a right-sized baseline, then match its exit option to how confident you are in the forecast.
• Where to start: Build one normalized view of coverage, utilization, and expirations, then allocate cost and savings to owners.

If your company runs on more than one cloud, you probably buy discounts on each one separately, on different calendars, under different rules. That works until someone asks for one answer across all of them. This guide explains multi-cloud commitment management: how commitments differ by provider, how to buy and track them as one portfolio, and what to report.

What Is Multi-Cloud Commitment Management, and Why Does It Matter?

Multi-cloud commitment management is the practice of running every commitment-based discount you hold across AWS, Azure, and Google Cloud as one portfolio. That means deciding what to buy, tracking how well it's used, assigning its cost and savings to owners, and choosing what to renew.

A commitment-based discount trades a promise for a price. You agree to a set amount of usage or spend, usually for one or three years. In return, the provider bills that usage below the on-demand rate, which is the standard pay-as-you-go price.

This is narrower than multi-cloud management, which covers running workloads across providers. It also differs from single-cloud commitment management, where one console shows the whole picture and one set of rules applies.

Get it wrong and the failure is quiet. You can pay for an idle commitment on one cloud while eligible spend on another runs at full on-demand rates. Neither provider's console shows you both.

The work usually starts with a question from finance: how much of next year's budget can we lock in, and what if we're wrong? Cloud commitment management answers with a portfolio view, a sizing method, and a named owner for savings and waste.

Spend-Based vs. Resource-Based Commitments: What Each Cloud Offers

Every provider sells commitments in two families, and the FinOps Foundation names both. FinOps Framework's Rate Optimization capability lists both: "by purchasing commercially-available, resource-based commitment discounts (Reserved Instances, Committed Use Discounts), by purchasing spend-based commitment discounts (Savings Plans)."

A resource-based commitment locks in a discount on specific resources, such as an instance family in one region. A spend-based commitment locks in an hourly dollar amount. The discount then applies to any eligible usage up to that amount.

Both are billing agreements. You don't deploy anything when you buy one, which is why engineering can move a workload without noticing that a commitment just went idle.

The table compares each provider's spend-based option, resource-based option, and main exit options.

One rule applies to every row: a commitment only discounts usage on the cloud where you bought it. You can't pool an AWS Savings Plan with Azure usage. Each provider needs its own sizing, even when you plan the portfolio together.

Why Exit Options Now Decide Your Commitment Strategy

The discount rate gets the attention at purchase time. The exit option decides how expensive a wrong forecast becomes.

An exit option is any way out of a commitment: a cancellation, a refund, a resale, or an exchange. Each cloud handles mistakes differently, and as providers keep narrowing reservation flexibility, a bad guess costs more to undo.

Azure: Exchanges End for New Reservations on Savings-Plan-Covered Services

An exchange swaps one reservation for another, such as a different VM size or region. Microsoft's reservation exchange policy change states: "Starting February 1, 2027, reservations purchased after this date aren't eligible for exchange if the corresponding service is supported by savings plans."

Older reservations keep some room. Microsoft's page says, "Reservations purchased before February 1, 2027, keep the right to one final exchange." The trade-in path, which converts a reservation into a savings plan, stays unchanged.

Cancellation has a ceiling too: "The total canceled commitment can't exceed $50,000 USD in a 12-month rolling window for a billing profile or single enrollment." In practice, an Azure reservation you buy next year is a firmer bet than one you buy today. Size it that way.

Google Cloud: Spend-Based CUDs Can't Be Cancelled or Shared Across Billing Accounts

Committed use discounts (CUDs) are Google Cloud's commitments, and spend-based CUDs commit you to an hourly spend amount. Google Cloud's spend-based CUD documentation states, "You cannot share the discount across different billing accounts, even if they belong to the same organization."

The same page says, "You cannot cancel the commitments you have purchased." It adds that "Unused commitment does not carry over to the next hour." An idle hour is gone for good.

Your billing-account structure matters as much as the purchase. If teams run on separate billing accounts, a spend-based CUD bought in one can't absorb usage in another.

Google is also moving many, but not all, spend-based CUDs to a model that "leverages discounts rather than credits." Google says the migration date appears as a notification on the Billing Overview page in the console. Savings will look different in reports after the switch, which means year-over-year comparisons across that date need care.

AWS: A Short Return Window, Then You Own It

AWS keeps the Savings Plans rules simple, and the exits few. The FinOps Foundation's AWS purchasing playbook states it flatly: "AWS's official policy is Savings Plans cannot be canceled."

The same playbook notes one narrow exception: "Any Savings Plans that has an hourly commitment of $100 or less, purchased in the past 7 days and in the same calendar month can be returned."

Reserved Instances (RIs) give you more room. Standard RIs can be resold on the RI Marketplace, and Convertible RIs can be exchanged for other RIs. The mechanics are covered in this guide to how AWS Savings Plans and Reserved Instances differ.

On AWS, flexibility lives in the plan's scope. The same Finout guide explains that a Compute Savings Plan applies across instance families and regions, which makes it a safer choice when you expect workloads to change.

How to Manage Commitments Across Clouds: A 6-Step Process

Treat these steps as a loop, because a commitment portfolio changes every time a workload does. Each step produces an input the next one needs, and renewals send you back to step one.

1. Build One Normalized View of Commitments and Eligible Spend

Each cloud reports commitments in its own way. Some show savings as credits and others as discounts. Some reports show amortized cost, while others show what was billed that month.

Amortization spreads an upfront payment across the full term, giving each day its share of the cost. Without one rule for amortization and one rule for "used" and "unused," your numbers won't compare across providers.

FOCUS, the FinOps Open Cost and Usage Specification, defines the same two values, "Used" and "Unused," for any provider that supplies FOCUS-conformant data. The FOCUS commitment discount status column is explicit: "CommitmentDiscountStatus MUST be 'Unused' when the charge represents the unused portion of the given CommitmentDiscountId."

Your normalized view should hold these five things for each provider:

• Inventory: Every active commitment, with its type, term, and purchase date.
• Eligible on-demand spend: Usage a commitment could cover but currently doesn't.
• Coverage: The percentage of eligible usage billed at a commitment rate.
• Utilization: The percentage of each commitment you actually consumed.
• Expirations: End dates by month, with an owner attached to each one.

Finout is an enterprise-grade FinOps platform for cloud and AI spend. The MegaBill brings your cloud providers and AI spend into a "single, unified view, at any level of granularity."

2. Right-Size Before You Commit

A commitment locks in a rate on whatever you're running, waste included. If a fleet is oversized, a three-year commitment keeps paying for the extra capacity until the term ends.

Azure customers choosing between reservations and savings plans get this advice first. Microsoft's guidance on choosing between them puts it plainly: "Right-size first – Remove unused or oversized resources before buying any discounts. Discounts reduce rates, not waste."

The advice holds on every cloud. Before buying, ask engineering to remove idle resources, downsize oversized ones, and confirm which workloads are scheduled to shut down.

3. Size Each Commitment Against a Baseline, Not a Peak

Your baseline is the steady floor of eligible usage that runs every hour on each provider. Use hourly data instead of monthly averages. A monthly average blends peaks and valleys into a number you never actually run at.

Next, check breakeven, the point where the on-demand charges you avoided equal what the commitment cost. Take a hypothetical example: an upfront commitment costs $12,000 and covers usage that would cost $1,500 a month on demand. In this hypothetical, it breaks even in month 8.

The same Rate Optimization capability guidance gives you guardrails. The FinOps Foundation suggests "purchasing commitments with a break-even within 9 months" and a return on investment above 10%. For steady-state usage on resource-based commitments, the Foundation also suggests "maintaining a utilization upper-waterline around 80%."

Then ask engineering what's changing. Planned migrations, launches, and region moves all shift the baseline, and none of them appear in last quarter's usage.

4. Ladder Purchases and Match the Exit Option to Your Confidence

Laddering means spreading purchases across the year instead of buying once, a practice the FinOps Foundation's guidance also recommends. Some commitments then always come up for review, which gives you regular chances to correct course.

Then match the commitment type to how sure you are of the forecast:

• High confidence: Use resource-based commitments, such as reservations or resource-based CUDs, for usage that runs continuously and rarely changes.
• Medium confidence: Use spend-based commitments, such as savings plans or Flex CUDs, for workloads that shift across instance types or services.
• Low confidence: Stay on demand until the pattern settles, and revisit it at the next scheduled purchase.

Microsoft's guidance draws a similar line, favoring reservations for continuous, highly stable workloads and savings plans for dynamic or evolving ones. After February 1, 2027, a new Azure reservation on a savings-plan-covered service has no exchange, which raises the confidence bar for buying one.

5. Allocate Commitment Costs and Savings to the Teams That Use Them

A commitment bought centrally usually covers many teams. If its cost and savings stay in a central account, savings look like a windfall for the FinOps team. Waste looks like no one's problem.

Amortize each commitment's cost, then split two things by actual usage: the discount each team received and the unused portion. Each team then sees its effective rate, meaning the rate it actually paid after discounts, and owns its share of the waste.

Virtual Tags group spend by team, service, environment, project, business unit, or customer segment across your connected cloud bills. That mapping is what makes consistent showback across teams possible. Anthony Logan, Senior Director of FinOps & Sourcing at SiriusXM, describes it as "mapping shared accounts to the right teams across more than 100 workloads."

6. Monitor Daily, Then Renew, Replace, or Let Expire

Utilization drift shows up hour by hour. A monthly review catches a stranded commitment weeks after the waste started, and those weeks of unused commitment don't come back.

For expirations, a good habit is to start the review 60 to 90 days before the end date. That gives you time to choose one of three paths:

• Renew: The workload is stable, and the baseline still supports the same size.
• Replace: The workload changed, and a more flexible type, such as a spend-based plan, now fits better.
• Let expire: The workload is shrinking or moving, and on-demand rates cost less than an idle commitment.

Time renewals to the budget cycle. As teams move to shorter cloud budgeting cycles, finance needs to know which commitments renew in each period and what they add.

Which KPIs Show Your Commitment Portfolio Is Healthy?

The table compares each KPI by what it measures, how to calculate it, and the warning sign to watch for.

The utilization, waste, and ESR formulas come from the FinOps Foundation's Rate Optimization guidance. Coverage and utilization pull against each other. Push coverage toward 100% and utilization usually drops, since any dip in usage leaves part of a commitment idle.

Track every KPI per provider and in aggregate. A strong blended ESR can hide one cloud with weak utilization, because a large, well-used AWS portfolio can mask a small, struggling Azure one.

Should Commitment Management Be Centralized?

Centralize analysis and purchasing, and keep usage accountability with the teams. The FinOps Foundation's guidance recommends central analysis "using a holistic view of the organization's cloud estate and not at each individual cloud sub-account level."

In multi-cloud commitment management, central buying lets one team see eligible usage across every account and cloud before it commits. The teams that run the workloads still decide whether those commitments get used.

The table compares what each role owns in commitment decisions.

If you manage FinOps Scopes, the FinOps Framework's term for segments of spend grouped around a shared business decision, expect overlap. One Compute Savings Plan can benefit a production Scope and an AI training Scope at the same time.

Write down which Scope gets the savings and which carries the unused portion. Only add a Scope when a distinct business outcome needs one, because each adds rules to maintain.

What Does This Mean in Practice?

How you apply multi-cloud commitment management depends on where your spend sits and who's asking. Start with the condition that matches your situation:

• If most spend is on one cloud: Run the full process there first, because that portfolio carries most of your savings and risk.
• If you're buying Azure reservations in 2027: Buy only for workloads you'd defend for the full term, since new ones lose exchange rights.
• If Google spend sits in multiple billing accounts: Review the account structure before buying spend-based CUDs, because the discount can't cross billing accounts.
• If AI capacity commitments enter the mix: Track provisioned throughput as its own commitment line, because its terms and units differ from compute commitments.
• If finance asks for a single savings number: Report net savings after waste, by provider, because gross savings overstate what the portfolio returned.

Three mistakes undo a lot of this work:

• Buying per cloud on separate calendars: Expirations cluster at random, and no one sees total exposure. Put every provider on one review calendar.
• Committing before rightsizing: You lock in a discount on waste for the full term. Clean up first.
• Reporting only blended ESR: One healthy cloud can mask another's idle commitments. Show each provider's numbers next to the total.

How Finout Helps You Manage Commitments Across Every Cloud

Finout supports multi-cloud commitment management by giving FinOps, engineering, and finance one shared view of commitments, next to your other cloud and AI spend.

My Commitments gives you an in-depth view of your AWS and Azure commitments in one place. For AWS, the view tracks coverage, utilization, net savings, underutilized waste, and discount rate, plus a table of upcoming commitment expirations. For Azure, the view tracks coverage and utilization, plus upcoming expirations.

You can filter those numbers by any MegaBill dimension. Filtering by Virtual Tags shows each team's coverage and utilization.

The My Commitments documentation notes: "AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level." Daily numbers catch utilization drift while you can still act on it.

For Reserved Instances, the RI Explorer in My Commitments compares hourly on-demand and RI usage by purchase group. It shows an "On-Demand Baseline," which is the hourly floor you size against in step 3.

CostGuard is an action hub that aggregates native recommendations from AWS Cost Explorer and Compute Optimizer, Azure Advisor, and the GCP Recommender API. For Google Cloud, Finout's Google Cloud cost coverage includes "Commitment recommendations" in that same hub.

Billy answers plain-English questions such as "Show me savings plan coverage by service over the last quarter" with a chart-backed answer. That helps when finance needs a number before the next meeting.

Financial Plans builds forecasts from historical and seasonal data and supports long-range plans multiple years ahead. You can check a three-year commitment against the budget it will live in.

See how Finout connects your commitments, cost, and savings to the teams that own them. Book a demo