For example, a 30% savings claim can change significantly depending on the baseline, workloads included, existing commitments, fees, and future usage.
In this blog, you will learn how to verify those assumptions before signing, compare savings claims on a like-for-like basis, and understand what the numbers could mean for your environment.
1. Define the savings baseline
Before you compare savings percentages, make sure you know what the vendor is comparing them against. Without that baseline, even a precise-looking number can be misleading.A savings estimate might be measured against:
public On-Demand or Pay-As-You-Go pricing;
your negotiated cloud rates;
your current effective cost;
your existing commitment portfolio; or
forecast spend if you make no further changes.
Suppose a workload would cost $1 million at On-Demand rates. Your negotiated pricing and existing commitments already reduce that to $750,000, and a new platform estimates it can bring the cost down to $650,000.
You are now 35% below the public On-Demand baseline, but the new platform is creating $100,000 of incremental savings over what you already achieve.
For a FinOps or Finance team evaluating a new contract, that incremental number is usually the more useful one.
The FOCUS specification supports this distinction by separating List Cost, Contracted Cost, Billed Cost, and Effective Cost.
So before accepting a savings claim, ask: What would we actually spend without this product, after accounting for the pricing and commitments we already have?
That gives you a much more credible basis for judging whether the proposed savings are genuinely new.
2. Check which spend the savings claim actually covers
Once you know what the savings are measured against, the next step is to understand what portion of your cloud spend is included in that calculation.A savings percentage can apply to your entire cloud bill or only to a specific subset of usage.
For example, a $10 million cloud bill may include compute, databases, storage, networking, Marketplace software, Spot usage, and workloads that are not suitable for commitments.
So if a vendor says it can save 30% on eligible compute usage, that does not mean your total cloud bill will fall by 30%.
Before comparing proposals, ask whether the savings percentage applies to:
total cloud spend;
commitment-eligible spend;
uncovered eligible spend;
covered usage; or
On-Demand-equivalent spend.
First confirm the baseline. Then confirm the scope. Only after that does the percentage become comparable.
3. Check whether the time period reflects what comes next
Once you know the baseline and the spend included, look at the period used to generate the recommendation.Cloud commitment recommendations often start with historical usage, but history is not the same as a forecast.
AWS makes this distinction explicit. Its Savings Plans recommendation calculations model how an additional commitment would have performed against historical usage, and AWS states that the recommendations do not forecast future usage.
Microsoft also uses historical Pay-As-You-Go usage for Azure Savings Plan recommendations, while Google Cloud’s CUD recommender evaluates recent usage when identifying commitment opportunities.
The question for your team is whether that history still represents the workload you expect to run.
Before accepting the estimate, account for planned changes such as:
seasonality;
migrations or shutdowns;
product launches;
rightsizing;
architecture changes;
expected growth or contraction.
First verify the baseline and scope. Then verify that the usage behind the estimate is likely to persist.
4. Separate existing savings from new savings
Once you have checked the baseline, scope, and usage period, the next step is to isolate what the new vendor is actually adding.Most enterprise environments already have some combination of:
- AWS Savings Plans or Reserved Instances;
- Azure Savings Plans or Reservations;
- Google Cloud CUDs;
- private or negotiated pricing;
- existing commitment-management tools.
For example, if your current commitment portfolio already saves $500,000 a year and a new platform can add another $200,000, make sure the proposal distinguishes between:
$700,000 of total commitment savings and $200,000 of incremental savings from the new strategy.
ProsperOps, for example, uses a Savings Share model and defines different savings categories in its pricing methodology. Some of those categories can include savings associated with commitments the customer already owns.
So ask: Do our existing commitments contribute to the savings number, the fee calculation, or both?
That tells you much more about the true incremental value of the proposal.
5. Understand what the vendor charges against
Once you have separated existing savings from new savings, look at how the vendor prices its service.Cloud optimization platforms use different commercial models. Some charge a percentage of savings, others price against managed cloud spend, and broader FinOps platforms may use negotiated SaaS subscriptions.
For example, Harness currently prices Commitment Orchestrator using tracked EC2 cloud spend, as outlined in its products and license units documentation.
Usage.ai uses a different model. Our pricing documentation explains that customers pay an agreed percentage of realized savings generated through the Flex Commitment Program after provider billing data is finalized.
That means 20% of savings and 1% of cloud spend are not directly comparable. The better approach is to convert each model into dollars using the same environment and assumptions.
6. Check whether the savings opportunities overlap
Once you understand the fee model, make sure the underlying savings opportunities are not being counted twice.Different recommendations can affect the same workload. For example, a platform might identify:
- $100,000 from rightsizing and
- $80,000 from commitment purchasing
The same issue can appear across shutdown recommendations, rightsizing, Spot, commitments, storage optimization, and architecture changes.
Microsoft explicitly notes that Azure Advisor savings recommendations can overlap, because implementing one recommendation can change the savings available from another.
So ask: If we implement one recommendation, does it change the baseline for the others?
A credible proposal should show the combined economic impact after those interactions are accounted for.
7. Do not treat utilization as proof of savings
After checking that the savings opportunities do not overlap, look at how the vendor measures commitment performance.High utilization is useful, but it does not automatically mean you are maximizing savings. A team can maintain nearly 100% utilization by committing conservatively while still leaving a large amount of predictable usage at On-Demand rates.
The reverse can also happen. Pushing coverage too aggressively may increase commitment waste if usage falls.
That is why the FinOps Foundation’s rate optimization framework looks beyond utilization to the broader financial outcome of the commitment portfolio, including Effective Savings Rate (ESR).
Our guide to ESR vs ICR goes deeper into how these metrics help evaluate whether commitments are actually delivering value.
Remember, the goal is not perfect utilization on paper. It is stronger commitment economics.
8. Stress-test the downside if usage falls
Once you understand how the strategy performs under normal conditions, test what happens if demand does not follow the forecast.This matters most when the recommendation creates a one-year or three-year cloud commitment.
Ask the vendor to model what happens if eligible usage falls by 10%, 25%, and 50%. Then review:
how much commitment could go unused;
how much usage would remain On-Demand;
whether the commitment portfolio can be adjusted;
how the vendor fee changes;
whether any refund, cashback, or protection applies;
what obligations remain if you leave the vendor.
A strong discount can still produce weak economics if too much committed value goes unused.
So ask: What does this recommendation cost us if the usage you expect does not materialize?
9. Verify protection and cancellation claims in the contract
If the downside case depends on words like guaranteed, protected, cashback, risk-free, or no lock-in, make sure those claims are supported by the contract.Ask:
What is actually protected?
Which commitments qualify?
What triggers reimbursement?
What exclusions apply?
How is the amount calculated and paid?
What obligations remain if the vendor relationship ends?
Being able to cancel a platform does not necessarily cancel a Savings Plan, Reservation, or CUD already purchased in your cloud account.
Usage.ai makes the same distinction. Existing customer commitments are separate from eligible Flex Commitments managed through the Flex Insured Commitment Program. Our guide to insured cloud commitments explains how eligibility and protection work.
The same rule applies to us: If protection materially changes the ROI case, verify the contractual mechanism before including it in the economics.
10. Require proof that holds up in your own environment
Once the methodology and contract terms are clear, the final step is to verify the claim against evidence.Case studies and ROI calculators are useful context, but they are still indirect evidence. What matters most is whether the vendor can show how the estimate was derived from your billing data, your existing commitments, and the assumptions used in the model.
A useful way to think about the evidence is:
| Evidence | How much confidence it should give you |
|---|---|
| Headline “up to” discount | Shows the theoretical maximum, not your expected outcome |
| Generic ROI calculator | Gives a directional estimate based on broad assumptions |
| Customer case study | Shows the result has been achieved elsewhere |
| Comparable customer result | More relevant if the environment and starting point resemble yours |
| Analysis of your billing data | Shows where the opportunity exists in your environment |
| Reproducible savings calculation | Lets FinOps or Finance verify how the estimate was derived |
Before treating a savings estimate as part of the business case, your team should be able to trace:
The question to ask is: can our FinOps or Finance team reproduce the logic behind this savings number using our own cloud data?
If the answer is no, you still have a projection. If the answer is yes, you have something much closer to a defensible business case.
Five checks before you sign
Before you approve the contract, make sure your team can answer five questions:Baseline: What would we spend without this vendor?
Scope: Which workloads and costs are included in the claim?
Assumptions: What usage history and future changes does the estimate rely on?
Commercials: How are fees, existing commitments, protection, and termination handled?
Evidence: Can FinOps or Finance trace the number back to your cloud billing data?
How Usage.ai lets you verify the savings estimate before you buy
If you are evaluating Usage.ai, you should be able to apply the same scrutiny in this guide to our own savings estimate.That is why we start with a Usage.ai Savings Test. Using read-only evaluation access, we review your existing commitments, eligible uncovered usage, and potential additional savings before you give us purchasing authority.
This gives your FinOps, Finance, and infrastructure teams a chance to review the recommendation against your own environment. You also understand the assumptions behind it, and see whether the opportunity is genuinely incremental before moving forward.
Review your Usage.ai savings estimate →
Connect in 15 minutes to compare current commitment coverage, risk, and potential savings before choosing a platform.
Frequently asked questions
How can I tell if a cloud savings claim is realistic?
Check the baseline, workloads included, historical period, existing discounts and commitments, vendor fees, and what happens if usage changes. The strongest claims can be traced back to your own cloud billing data.
What is the difference between projected and realized cloud savings?
Projected savings are estimates based on assumptions about future usage and pricing. Realized savings are measured after the optimization has actually been implemented.
Should existing Savings Plans, RIs, or CUDs be included in a vendor’s savings claim?
They should be clearly separated. Existing commitments may already be generating savings, so buyers should understand how much of the proposal is genuinely incremental.
How should I compare vendors that use different pricing models?
Convert each model into dollars using the same environment and assumptions. A percentage of savings and a percentage of cloud spend are not directly comparable.
What should I verify before signing a cloud optimization contract?
Confirm the savings baseline, scope, assumptions, fee model, treatment of existing commitments, downside risk, protection terms, and whether Finance can reproduce the calculation from provider billing data.