.png)
Key takeaways
1
A Usage.ai Savings Test evaluates your existing commitments, uncovered eligible usage, and potential additional savings before you change your current purchasing approach.
2
With read-only evaluation access, you can review what we would recommend without allowing us to purchase commitments or modify your workloads.
3
The goal is to compare projected economics, assumptions, and risk against your current strategy so you can decide whether moving into managed commitments makes sense.
Most teams evaluating Usage.ai are not starting from zero. You may already have Savings Plans, Reserved Instances, CUDs, native cloud recommendations, or another FinOps platform managing part of your commitment strategy.
The real question is whether there is additional commitment opportunity in your environment, what we would recommend against it, and whether the economics justify changing your current approach.
A Usage.ai Savings Test lets you evaluate that against your connected cloud environment.
With read-only evaluation access, we can analyze the opportunity without permission to purchase AWS Reserved Instances or Savings Plans. You can inspect the recommendation before deciding whether we should execute it.
You connect the AWS, Azure, or GCP environment you want us to evaluate. We then analyze the relevant billing, usage, and commitment information to understand:
The real question is whether there is additional commitment opportunity in your environment, what we would recommend against it, and whether the economics justify changing your current approach.
A Usage.ai Savings Test lets you evaluate that against your connected cloud environment.
With read-only evaluation access, we can analyze the opportunity without permission to purchase AWS Reserved Instances or Savings Plans. You can inspect the recommendation before deciding whether we should execute it.
What is a Usage.ai Savings Test?
A Usage.ai Savings Test is an account-connected evaluation of your cloud commitment opportunity.You connect the AWS, Azure, or GCP environment you want us to evaluate. We then analyze the relevant billing, usage, and commitment information to understand:
what commitments you already have;
where eligible usage remains uncovered;
where additional commitment coverage may improve the economics;
what commitment approach we would recommend; and
what the potential savings could look like before execution.
The key benefit is that you can evaluate the recommendation before deciding how you want to move forward.
With a read-only Savings Test, we can analyze the opportunity and show you what we would recommend while purchasing authority remains with your team. Read how Usage.ai handles read-only evaluation access.
That gives your team a clearer basis to decide: Does this recommendation improve our current commitment position? And, if so, how do we want to put it into action?
Before we get into the individual steps, it helps to understand what the Savings Test is designed to do.
With a read-only Savings Test, we can analyze the opportunity and show you what we would recommend while purchasing authority remains with your team. Read how Usage.ai handles read-only evaluation access.
That gives your team a clearer basis to decide: Does this recommendation improve our current commitment position? And, if so, how do we want to put it into action?
Before we get into the individual steps, it helps to understand what the Savings Test is designed to do.
1. Start with the cloud environment you want us to evaluate
The Savings Test starts with the part of your cloud environment you want us to review, whether that is AWS, Azure, GCP, or a broader multi-account setup.
Once connected, we use the relevant billing, usage, commitment, and cloud metadata to understand your current position. That includes what commitments are already in place, where eligible usage is still uncovered, and where there may be room to improve coverage.
The connection method varies by cloud and the scope of the environment you want to evaluate.
For AWS, the Savings Test uses a lightweight IAM policy and role to provide the access needed for the analysis. Teams can connect AWS accounts individually using an IAM Role, or use CloudFormation or Terraform when onboarding multiple accounts. See the Usage.ai AWS Integration Guide.
For Azure, the integration process includes configuring the required roles and permissions and syncing the relevant account data for analysis. See the Usage.ai Azure Integration Guide.
For GCP, onboarding includes assigning the required custom roles, configuring Cloud Billing data through BigQuery, and connecting the projects you want included in the evaluation. See the Usage.ai GCP Integration Guide.
At this stage, the focus is evaluation. The Savings Test is designed to give us the information needed to assess the savings opportunity and build a recommendation while your team retains control over purchasing and any changes to the environment.
You can read more about how Usage.ai handles evaluation access and permissions.
Once connected, we use the relevant billing, usage, commitment, and cloud metadata to understand your current position. That includes what commitments are already in place, where eligible usage is still uncovered, and where there may be room to improve coverage.
The connection method varies by cloud and the scope of the environment you want to evaluate.
For AWS, the Savings Test uses a lightweight IAM policy and role to provide the access needed for the analysis. Teams can connect AWS accounts individually using an IAM Role, or use CloudFormation or Terraform when onboarding multiple accounts. See the Usage.ai AWS Integration Guide.
For Azure, the integration process includes configuring the required roles and permissions and syncing the relevant account data for analysis. See the Usage.ai Azure Integration Guide.
For GCP, onboarding includes assigning the required custom roles, configuring Cloud Billing data through BigQuery, and connecting the projects you want included in the evaluation. See the Usage.ai GCP Integration Guide.
At this stage, the focus is evaluation. The Savings Test is designed to give us the information needed to assess the savings opportunity and build a recommendation while your team retains control over purchasing and any changes to the environment.
You can read more about how Usage.ai handles evaluation access and permissions.
2. We establish what commitments you already have
Before we look for new commitment opportunities, we first account for what is already in place. That could include:Savings Plans,
Reserved Instances,
Azure Reservations or Savings Plans,
GCP committed use discounts, or
other provider-specific commitments.
This matters because total cloud spend is not the same as commitmentable spend.
For example, your organization has $300,000 per month of AWS compute spend, but $160,000 is already effectively covered by commitments and another $40,000 is too variable or otherwise unsuitable for additional coverage.
The relevant opportunity is closer to the remaining $100,000, not the full $300,000.
The relevant opportunity is closer to the remaining $100,000, not the full $300,000.
From there, the recommendation depends on:
the services involved,
the commitments you already own,
how your usage behaves, and
what is expected to change.
AWS applies a similar principle in its own Savings Plans recommendations, which take historical usage and existing Savings Plans into account when estimating additional opportunities. You can see more in the AWS documentation on Savings Plans recommendation calculations.
So, the more useful question at this stage is: After accounting for what you already own, where is there still durable usage that could benefit from additional commitment coverage?
Not all of that usage should automatically be committed.
Some may already be covered elsewhere. Some may not be eligible for the commitment being evaluated. And some may be too short-lived or unpredictable to support another commitment comfortably.
So rather than starting with the biggest available discount, we look at the part of your usage where additional coverage could make sense.
In practice, that means narrowing the opportunity from:
So, the more useful question at this stage is: After accounting for what you already own, where is there still durable usage that could benefit from additional commitment coverage?
3. We identify where there is still room to improve coverage
Once we have a clear view of the commitments already in place, the next step is to look at the usage that is still exposed to higher On-Demand rates.Not all of that usage should automatically be committed.
Some may already be covered elsewhere. Some may not be eligible for the commitment being evaluated. And some may be too short-lived or unpredictable to support another commitment comfortably.
So rather than starting with the biggest available discount, we look at the part of your usage where additional coverage could make sense.
In practice, that means narrowing the opportunity from:
Total cloud usage → eligible usage → existing coverage → uncovered usage → potential commitment opportunity
The aim is to find the portion of spend where another commitment can improve your effective rate while still fitting the way your environment actually behaves.
A workload may look steady in historical billing data, but the outlook can change quickly if your team is planning a migration, rightsizing effort, application retirement, major architecture change, or a period of significant growth or contraction.
That is why commitment decisions need both usage history and business context. Our broader commitment-management approach uses actual consumption patterns to inform how commitments are sized and sequenced. While your team brings the forward-looking context that billing data alone cannot provide.
AWS takes a similar historical approach in its native Savings Plans recommendations. It uses a selected 7, 30, or 60-day lookback period and notes that those recommendations do not forecast future usage.
AWS therefore recommends choosing a historical period that reasonably reflects what you expect to use going forward. See how AWS calculates Savings Plans recommendations
The goal is to distinguish usage that is simply present today from usage that is stable enough to support a longer-term commitment decision.
Rather than stopping at a headline savings estimate, we look at what to commit, where that commitment should apply, and how it fits alongside the commitments you already have.
The right answer can vary by cloud, service, and workload. On AWS, for example, that may mean evaluating Compute Savings Plans, EC2 Instance Savings Plans, Database Savings Plans, or service-specific reservations rather than treating every uncovered dollar the same way.
AWS’s own recommendation framework reflects the same level of decision-making. Its Savings Plans recommendation data includes factors such as recommended hourly commitment, estimated monthly savings, estimated utilization, On-Demand spend, and expected ROI.
See the fields AWS provides in Savings Plans recommendations.
For us, the important question is not simply how much more you could commit.
It is which additional commitments make sense given your current coverage, expected usage, savings opportunity, and the flexibility your environment needs.
4. We look at how durable that usage is
Uncovered usage is only part of the picture. Before recommending additional commitment coverage, we also need to understand how likely that usage is to continue.A workload may look steady in historical billing data, but the outlook can change quickly if your team is planning a migration, rightsizing effort, application retirement, major architecture change, or a period of significant growth or contraction.
That is why commitment decisions need both usage history and business context. Our broader commitment-management approach uses actual consumption patterns to inform how commitments are sized and sequenced. While your team brings the forward-looking context that billing data alone cannot provide.
AWS takes a similar historical approach in its native Savings Plans recommendations. It uses a selected 7, 30, or 60-day lookback period and notes that those recommendations do not forecast future usage.
AWS therefore recommends choosing a historical period that reasonably reflects what you expect to use going forward. See how AWS calculates Savings Plans recommendations
The goal is to distinguish usage that is simply present today from usage that is stable enough to support a longer-term commitment decision.
5. We build the commitment approach we would recommend
At this point, the goal is to turn the analysis into a practical commitment recommendation.Rather than stopping at a headline savings estimate, we look at what to commit, where that commitment should apply, and how it fits alongside the commitments you already have.
The right answer can vary by cloud, service, and workload. On AWS, for example, that may mean evaluating Compute Savings Plans, EC2 Instance Savings Plans, Database Savings Plans, or service-specific reservations rather than treating every uncovered dollar the same way.
AWS’s own recommendation framework reflects the same level of decision-making. Its Savings Plans recommendation data includes factors such as recommended hourly commitment, estimated monthly savings, estimated utilization, On-Demand spend, and expected ROI.
See the fields AWS provides in Savings Plans recommendations.
For us, the important question is not simply how much more you could commit.
It is which additional commitments make sense given your current coverage, expected usage, savings opportunity, and the flexibility your environment needs.
6. You evaluate the economics, not just the discount
Once the recommendation is clear, the next step is to understand what it means financially. That includes:where the savings opportunity comes from,
what your existing commitments are already covering,
what additional commitment is being proposed, and
how the recommendation could change if your usage changes.
The important distinction is between estimated savings and realized savings.
A Savings Test gives you a modeled view of the opportunity. Realized savings depend on what actually happens after commitments are purchased and how your usage evolves over time.
Our pricing follows that same principle. Usage.ai fees are based on an agreed percentage of realized savings generated through Flex Insured Commitments, rather than the projected Savings Test estimate. See how Usage.ai pricing is calculated.
AWS, for example, uses historical usage, your existing Savings Plans, and a selected lookback period to estimate an additional commitment designed to improve savings. See how AWS calculates Savings Plans recommendations.
AWS also provides a Purchase Analyzer that lets teams model a proposed Savings Plan purchase and review the projected economics before buying. Explore the AWS Savings Plans Purchase Analyzer.
The Usage.ai Savings Test gives you another view of the commitment opportunity and lets you evaluate how our recommended approach would fit with the Flex Insured Commitment management and protection model if you decide to proceed. See how the Usage.ai Flex Insured Commitment Program works.
For teams that already have commitments or an established FinOps process, that makes the Savings Test useful as a practical second opinion before changing how future commitments are managed.
With our read-only evaluation permissions, we can assess the savings opportunity and show you what we would recommend while purchasing authority stays with your team. See how Usage.ai handles evaluation access and permissions.
That means you can review the recommendation, understand the potential economics, and decide how you want to proceed before any commitment purchases are enabled.
If you choose to move forward, the next step is to approve the appropriate access and operating model for execution.
We evaluate new opportunities alongside your existing Savings Plans, Reserved Instances, Reservations, CUDs, and other commitments so the recommendation reflects the portfolio you already have.
The same applies if another FinOps or commitment-management platform is already in use. A Savings Test can give you an additional point of comparison without requiring you to change your current process first.
A Savings Test gives you a modeled view of the opportunity. Realized savings depend on what actually happens after commitments are purchased and how your usage evolves over time.
Our pricing follows that same principle. Usage.ai fees are based on an agreed percentage of realized savings generated through Flex Insured Commitments, rather than the projected Savings Test estimate. See how Usage.ai pricing is calculated.
How does this compare with native cloud recommendations?
Native cloud recommendations are an important input into a well-run commitment process.AWS, for example, uses historical usage, your existing Savings Plans, and a selected lookback period to estimate an additional commitment designed to improve savings. See how AWS calculates Savings Plans recommendations.
AWS also provides a Purchase Analyzer that lets teams model a proposed Savings Plan purchase and review the projected economics before buying. Explore the AWS Savings Plans Purchase Analyzer.
The Usage.ai Savings Test gives you another view of the commitment opportunity and lets you evaluate how our recommended approach would fit with the Flex Insured Commitment management and protection model if you decide to proceed. See how the Usage.ai Flex Insured Commitment Program works.
For teams that already have commitments or an established FinOps process, that makes the Savings Test useful as a practical second opinion before changing how future commitments are managed.
7. You stay in control during the read-only test
This is where evaluation and execution remain clearly separate.With our read-only evaluation permissions, we can assess the savings opportunity and show you what we would recommend while purchasing authority stays with your team. See how Usage.ai handles evaluation access and permissions.
That means you can review the recommendation, understand the potential economics, and decide how you want to proceed before any commitment purchases are enabled.
If you choose to move forward, the next step is to approve the appropriate access and operating model for execution.
8. Your existing commitments remain part of the picture
The commitments you already own stay in place and remain part of the analysis.We evaluate new opportunities alongside your existing Savings Plans, Reserved Instances, Reservations, CUDs, and other commitments so the recommendation reflects the portfolio you already have.
The same applies if another FinOps or commitment-management platform is already in use. A Savings Test can give you an additional point of comparison without requiring you to change your current process first.
A Practical Tip
Compare in parallel. Keep purchasing authority with one system.
Compare in parallel. Keep purchasing authority with one system.
Comparing recommendations from more than one system can be valuable. If you later move into automated commitment management, purchasing authority should remain clearly defined so multiple systems are not acting on the same uncovered usage.
You should be able to evaluate:
What will you know at the end of the Savings Test?
By the end of the Savings Test, you should have a clearer view of the commitment opportunity in your environment and whether it is worth acting on.You should be able to evaluate:
1
Where is eligible usage still uncovered?
2
How do your existing commitments affect the opportunity?
3
What additional commitment approach would we recommend?
4
What assumptions need to remain true for that recommendation to work?
5
What savings could be incremental to what you already achieve?
6
How would the economics change if usage falls?
7
What would you need to authorize if you decide to proceed?
If the answers do not justify changing your current approach, you should know that before granting purchasing authority.
You might start with a limited scope, review recommendations individually, keep approvals in place, or move toward automated commitment management over time.
Once the required production permissions are enabled and you approve an eligible recommendation, we can purchase the commitment through the cloud provider API and manage it as a Usage.ai Flex Commitment under the applicable program terms.
That is the point where the Savings Test moves from evaluation into active commitment management.
If you decide to move forward after the Savings Test, approved recommendations can become Usage.ai-managed Flex Commitments. Eligible commitments under the Flex Insured Commitment Program include cashback protection as part of the operating model.
Under our current cashback policy, we calculate losses on eligible Flex Commitments when the cost of the commitment exceeds the equivalent On-Demand cost for the same usage. Applicable cashback then accrues and is tracked in the Usage.ai dashboard.
So during the Savings Test, cashback is something to factor into the risk-adjusted economics of the recommendation.
The actual cashback calculation begins only after an eligible Flex Commitment is live and the applicable program conditions are met.
It is worth running if:
What happens if you decide to proceed?
If the Savings Test shows a meaningful opportunity, you can move forward at the level of control that fits your team.You might start with a limited scope, review recommendations individually, keep approvals in place, or move toward automated commitment management over time.
Once the required production permissions are enabled and you approve an eligible recommendation, we can purchase the commitment through the cloud provider API and manage it as a Usage.ai Flex Commitment under the applicable program terms.
That is the point where the Savings Test moves from evaluation into active commitment management.
What about cashback?
Cashback becomes relevant once an eligible Flex Insured Commitment is active.If you decide to move forward after the Savings Test, approved recommendations can become Usage.ai-managed Flex Commitments. Eligible commitments under the Flex Insured Commitment Program include cashback protection as part of the operating model.
Under our current cashback policy, we calculate losses on eligible Flex Commitments when the cost of the commitment exceeds the equivalent On-Demand cost for the same usage. Applicable cashback then accrues and is tracked in the Usage.ai dashboard.
So during the Savings Test, cashback is something to factor into the risk-adjusted economics of the recommendation.
The actual cashback calculation begins only after an eligible Flex Commitment is live and the applicable program conditions are met.
When is a Savings Test worth running?
A Savings Test is especially useful when you already have some commitment coverage in place but want to know whether there is still a meaningful opportunity to improve it.It is worth running if:
you still have material On-Demand spend and want to understand how much of it is actually commit-ready;
Savings Plans or RI coverage has stopped improving;
your usage is changing and you want a commitment approach that reflects what is happening now;
you already rely on native cloud recommendations and want another view of the opportunity;
another platform manages commitments and you want to compare the economics before changing your current process;
Finance, Engineering, or FinOps wants to review the recommendation before moving into active commitment management.
See what the opportunity looks like in your environment
Run a read-only Usage.ai Savings Test to compare our recommendation with the commitments and savings you already have.
Compare your commitment strategy →
Run a read-only Usage.ai Savings Test to compare our recommendation with the commitments and savings you already have.
Compare your commitment strategy →
Frequently asked questions
What access does Usage.ai need for a Savings Test?
It depends on the cloud. For AWS, the Savings Test can use a lightweight IAM policy and role, without granting Usage.ai permission to purchase Reserved Instances or Savings Plans during the evaluation. Azure and GCP use their respective role, permission, and billing-data integrations
What happens to my existing commitments?
They remain your existing cloud-provider commitments. We evaluate additional opportunities around the portfolio you already own.
Is a Savings Test the same as the Usage.ai AWS Savings Calculator?
No. Our AWS Savings Calculator can provide an earlier estimate without a full account-connected evaluation. The Savings Test uses your connected environment to provide a deeper commitment analysis.
Can I run a Savings Test while another FinOps platform is still in place?
Yes. A read-only evaluation can be useful as a second opinion while your current process remains active. If multiple platforms are evaluating the same environment, keep purchasing authority clearly controlled.
Does the Savings Test guarantee the projected savings?
No. It evaluates potential savings based on the available cloud data and assumptions. Actual realized savings depend on future usage and the commitments ultimately purchased.
Share
Facebook
X
LinkedIn
Reddit
