New See exactly what you're overpaying AWS in under 60 seconds. Try the Calculator for free

How to Verify Cloud Savings Claims Before Signing a Contract

A practical guide to checking the assumptions, pricing, commitment risk, and evidence behind a cloud savings estimate before you approve the deal.
Updated September 14, 2026
23 min read
How to Verify Cloud Savings Claims Before Signing a Contract
In this article
Key takeaways
1
Check the baseline. Know whether savings are measured against list pricing or what you already pay today.
2
Check the assumptions. Look at the workloads, usage history, existing discounts, and expected changes behind the estimate.
3
Check the commercial terms. Understand how fees are calculated, what happens if usage falls, and what protection or exit terms actually apply.
A cloud cost optimization proposal may show a strong savings percentage and attractive projected ROI. But those numbers only matter if you understand how they were calculated.

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.

Those baselines can produce very different answers.

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.

This becomes especially important when comparing different types of FinOps platforms. A commitment-management tool may focus on lowering the rate paid for durable usage, while another platform may include rightsizing, idle-resource removal, Kubernetes efficiency, or storage optimization.
A Practical Tip
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.

A recommendation can be accurate for the period analyzed and still be the wrong commitment for the next 12 months.

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.
Those savings should not be treated as new value created by the vendor you are evaluating.

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.

That distinction becomes even more important when the vendor charges a percentage of savings.

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.

For the detailed gross-to-net calculation, you can go deeper with How to Measure Net Savings from Cloud Cost Optimization Software.

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
But if you rightsize first, the workload may consume less capacity, which reduces the amount worth committing to. So the combined opportunity may be lower than $180,000.

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.

The FOCUS commitment discount model distinguishes between Used and Unused commitment value, which helps make underutilization visible in cost analysis.

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?

Also separate the software contract from the underlying cloud commitment.

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
Comparable customer evidence is useful, but only when the comparison is meaningful. A company with low commitment coverage, stable workloads, and large amounts of On-Demand spend may have a very different savings opportunity from an enterprise that already runs a mature commitment strategy.

Before treating a savings estimate as part of the business case, your team should be able to trace:
provider billing data → current baseline → proposed optimization → projected savings
and understand the assumptions at each step.

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:
1

Baseline: What would we spend without this vendor?

2

Scope: Which workloads and costs are included in the claim?

3

Assumptions: What usage history and future changes does the estimate rely on?

4

Commercials: How are fees, existing commitments, protection, and termination handled?

5

Evidence: Can FinOps or Finance trace the number back to your cloud billing data?

If you cannot answer those five questions clearly, you do not yet have a savings case you can confidently compare or approve.

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
EVALUATE WITH YOUR OWN DATA
Compare your coverage and savings.

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.

Share
Facebook
X
LinkedIn
Reddit
Cut cloud cost with automation
Latest from our blogs