.png)
Most people understand that a Compute Savings Plan saves money on cloud compute. Far fewer understand the precise mechanism — which matters, because getting the commitment amount wrong in either direction costs real money.
Too high: you pay for committed hours you do not use. Too low: you miss savings on usage that could have been covered. The difference between a well-sized Savings Plan and a poorly-sized one can easily be tens of thousands of dollars per year on a mid-size fleet.
This guide walks through the exact mechanics, hour by hour, with worked examples on both AWS and Azure. By the end, you will know not just what a Savings Plan does, but how it does it — and that understanding is what makes the difference between guessing at a commitment amount and calculating it confidently.
Step 1: You Choose a Commitment Amount
Before anything else, you decide how much per hour you want to commit. This is the single most important decision in the entire process. Everything else is automatic — the discount application, the coverage calculation, the billing. This one choice is yours.
The commitment amount is a dollar figure: $X per hour. It does not represent a specific number of instances or a specific service. It represents a minimum spend level. You are telling the cloud provider: every hour for the next 1 year (or 3 years), I guarantee I will use at least this much compute.
The right commitment amount is your stable baseline — not your average and not your peak. Pull your last 30 days of hourly compute spend. Sort the values. Find the P70 or P75: the spend level you are at or above for 70-75% of hours. That is roughly where your commitment should sit.
Why P70-P75 and not the average? Because the average includes your peak hours and your quietest hours equally. If you commit to the average, you generate wasted commitment in the bottom 50% of hours. At P70, you are paying for unused commitment in only 30% of hours — and those 30% of hours only waste the difference between actual usage and committed amount, not the full committed amount.
Also read: What Are Commitment-Based Discounts in Multi-Cloud Services?
Step 2: The Cloud Provider Applies Discounted Rates
Once you have an active Savings Plan, the cloud provider applies discounted rates to your eligible compute usage every hour. You do not configure this. There is no matching step, no rule to write, no instance to tag. The discount applies automatically.
On AWS, the discount applies to EC2 instance hours, Fargate compute, and Lambda duration charges. On Azure, it applies to Virtual Machine compute, AKS node pool VMs, Azure Functions Premium, Container Instances, and App Service Premium v3.
The provider starts by applying the discount to usage with the highest savings rate first. If you are running an m5.xlarge (60% savings rate) and a c5.xlarge (58% savings rate) simultaneously, the m5 gets the Savings Plan rate applied first, then the c5, until you hit your committed hourly amount.
Reserved Instances are applied before Savings Plans. If you have an EC2 RI for a specific instance type, that RI discount applies first. The Savings Plan then covers the remaining eligible usage. This is intentional and complementary — RIs handle the stable, specific-configuration core; Savings Plans handle everything else.
Step 3: Usage Up to Your Commitment is Billed at the Discounted Rate
The discounted rate applies to your eligible usage hour by hour, up to your committed amount. Let us be concrete about what this means with a real example.
You have committed to $5.00 per hour on AWS. In a given hour, you run compute that would cost $8.00 at on-demand rates. Your Savings Plan covers the first $5.00 worth of compute at the discounted rate. At 60% savings, that $5.00 of on-demand compute costs you approximately $2.00-2.50 at the Savings Plan rate. The remaining $3.00 of on-demand usage is billed at standard rates. Your total bill for that hour: approximately $5.00-5.50 instead of $8.00.
Step 4: Usage Above Your Commitment is Charged at On-Demand Rates
The Savings Plan only covers usage up to your committed amount. Any usage above that threshold in a given hour is billed at normal on-demand rates, as if you had no Savings Plan at all.
This is not a penalty or a failure of the Savings Plan. It is the intended design. Your Savings Plan committed to a base level of spend. Additional usage above that base is flexible, on-demand capacity that you have not committed to — and it is priced accordingly.
The practical implication: if your usage regularly exceeds your commitment by a significant margin, you have an under-committed Savings Plan. You are leaving savings uncaptured. You can add an additional Savings Plan commitment on top of an existing one at any time (Savings Plans stack — each new purchase sits on top of the previous ones). You cannot modify an existing commitment upward.
Also read: How to Choose Between 1-Year and 3-Year AWS Commitments
Step 5: Unused Commitment is Charged Regardless
This is the step most people underestimate. If you commit to $5.00 per hour and your actual compute usage in a given hour is only $2.00, you still pay $5.00. The $3.00 of unused commitment is charged and does not carry forward.
There is no rollover. Each hour is independent. An unusually quiet Monday at 3am does not benefit from unused commitment banked during peak Tuesday hours.
This is exactly why sizing the commitment conservatively matters. For every dollar you over-commit during low-usage hours, you pay that dollar with zero return. The waste compounds: if you over-commit by $1.00/hour and run 720 hours in a month, that is $720/month in pure waste even as your Savings Plan discount is working correctly during busy hours.
Step 6: The Discount Renews Every Hour, Automatically
The Savings Plan does not need to be activated, refreshed, or managed after purchase. Every single hour for the duration of your term, the cloud provider checks your eligible compute usage, applies the discounted rates up to your committed amount, and charges the remainder at on-demand rates.
You do not need to update anything when you change instance types, launch in new regions, or migrate workloads. The discount follows automatically — this is the core advantage of Savings Plans over Reserved Instances, which stop applying when the configuration changes.
One scenario that requires attention: if you purchase a new Savings Plan on top of an existing one (stacking), each plan is applied independently and the combined committed amount across all active plans represents your total hourly commitment. Keep track of your total committed amount to avoid unintentional over-commitment from stacking too aggressively.
How AWS and Azure Apply Savings Plan Discounts Differently
The core mechanics are nearly identical between AWS and Azure. But there are two important differences in how each platform handles the discount application.
AWS: Reserved Instances First, Then Savings Plans
AWS applies discounts in a strict order: Reserved Instances first, then Savings Plans. If you have both, the RI discount applies to any usage matching the RI specification. The Savings Plan then covers remaining eligible usage up to the committed hourly amount. This ordering is fixed and cannot be changed.
The practical benefit: RIs and Savings Plans genuinely complement each other on AWS. Purchase RIs for the stable, known-configuration core of your fleet (highest discount). Use a Savings Plan for the flexible remainder (lower discount but follows any usage pattern). The combined strategy captures near-maximum savings across your entire compute footprint.
Azure: Reservations First, 3-Year Plans Before 1-Year Plans
Azure follows the same principle — Reservations are applied before Savings Plans. But Azure adds a second rule: if you have both 3-year and 1-year Savings Plans active simultaneously, the 3-year plan is applied first (because it offers a higher discount). This maximizes the benefit from your most valuable commitments before the less-valuable ones are consumed.
Azure also processes each hour completely independently. As one FinOps practitioner described it: each hour stands alone. If you use $100 of eligible compute in an hour and your commitment is $80, Azure prices $80 worth at the Savings Plan rate and the remaining $20 at pay-as-you-go. If you only use $60 in an hour but committed $80, you lose $20 worth of benefit. It does not roll over.
Also read: Cut Your Azure Bill by 40% in 5 Minutes: Complete Guide
A Worked Example: $10/Hour Commitment Over One Day
Let us trace how a $10/hour Compute Savings Plan (3-year All Upfront, 60% effective discount) plays out across 24 hours of variable usage.
| Hour | On-Demand Usage | Covered at SP Rate | At On-Demand Rate | Unused Commitment Waste | Effective Hourly Bill |
| 2am (quiet) | $4.00 | $4.00 (at $1.60) | $0 | $6.00 wasted | $10.00 |
| 9am (normal) | $10.00 | $10.00 (at $4.00) | $0 | $0 | $4.00 (60% saved) |
| 2pm (peak) | $18.00 | $10.00 (at $4.00) | $8.00 | $0 | $12.00 |
| On-demand would cost | $4 + $10 + $18 = $32 | $32.00 | |||
| With Savings Plan | $10 + $4 + $12 = $26.00 |
3-hour snapshot. Commitment: $10/hr. Discount: 60% on covered usage. The 2am quiet hour generates $6 of waste — this is the cost of having a commitment larger than needed during low-traffic periods. The 2pm peak hour, the Savings Plan saves $6 while the excess $8 bills at on-demand. Net savings vs pure on-demand across 3 hours: $6.00 (19%). Verify all rates at aws.amazon.com/savingsplans/compute-pricing — rates change.
The lesson from this table: the 2am quiet hour is the expensive one from a waste perspective, even though it looks cheap. Every quiet hour costs you the full commitment. If your workload is consistently quiet overnight, size the commitment at your daytime baseline and let overnight usage bill at on-demand — the on-demand cost for a few quiet hours is less than the waste from over-committing.
How to Size Your Commitment Correctly
One number determines whether your Savings Plan generates net savings or net waste: the commitment amount. Here is the process that gets it right.
Pull 30-60 Days of Hourly Compute Spend
In AWS Cost Explorer, navigate to Cost and Usage, filter by service EC2/Lambda/Fargate, and export at hourly granularity. In Azure Cost Management, export VM compute at daily granularity (divide by 24 for an hourly proxy if hourly is not available).
Find the P70 of Your Hourly Spend
Sort all hourly values from lowest to highest. Find the value at the 70th percentile. That is the spend level you are at or above for 70% of hours. Set your initial commitment at or slightly below this number.
Do Not Use the AWS or Azure Recommendation Directly
Both platforms provide Savings Plan recommendations in their cost management consoles. These are useful as a sanity check but they optimize for coverage, not for avoiding over-commitment. The platform recommendation will often suggest a higher commitment than your P70 calculation. Trust your own math.
Start Conservative, Layer Up
First Savings Plan purchase: commit at P65-P70. Review utilization after 30 days. If utilization (coverage consumed vs commitment) is consistently above 95%, add a second commitment on top. Savings Plans stack — you can layer additional commitments without modifying or cancelling the first.
Usage.ai automates this entire sizing process. The platform analyzes your hourly compute spend with a 24-hour refresh (versus Cost Explorer’s 72-hour cycle), calculates the correct commitment level, and purchases automatically within your approved parameters. If a commitment becomes underutilized because your workload drops, Usage.ai provides cashback in real money — not credits. Verified from Usage.ai documentation.
See how Usage.ai automates Savings Plan sizing and purchasing
Is Usage.ai Worth It? How It Simplifies Every Step Above
Every step in this guide is something your team has to do manually today. Pull the data. Calculate the P70. Validate the recommendation. Submit the purchase. Monitor utilization. Respond when usage drops. Renew before expiration. Each step is not complicated in isolation — but together, they add up to 8-16 hours of FinOps work per month. Per cloud. For teams managing AWS and Azure simultaneously, that is a significant recurring time cost.
Here is what that same process looks like with Usage.ai:
| Step | Manual (today) | With Usage.ai |
| 1. Size the commitment | Export 30-60 days of hourly Cost Explorer data. Calculate P70-P80 manually. Validate against the AWS recommendation. Decision takes 2-3 hours. | Done automatically. 24-hour data refresh. Optimal commitment calculated continuously. No spreadsheets. |
| 2. Purchase | Navigate the AWS or Azure console. Submit for finance approval. Wait days or weeks. Purchase when finally approved, on stale data. | Purchased automatically within approved parameters. Within minutes of identifying the opportunity, not weeks later. |
| 3. Handle over-commitment | Waste runs to term expiration. You pay for unused commitment for months. No recourse from AWS or Azure. | Buyback guarantee. If a commitment becomes underutilized, Usage.ai buys it back. Cashback returned in real money, not credits. |
| 4. Monitor and renew | Weekly utilization reviews. Calendar reminders for expiration. Manual renewal process each year. | Continuous monitoring. Automatic renewal recommendation. Adjusts quarterly based on current usage — not last year’s patterns. |
| 5. Multi-cloud (AWS + Azure) | Two separate consoles, two separate processes, two separate approval cycles. Often only one cloud gets optimized in practice. | AWS, Azure, and GCP managed under one platform. Same analysis, same automation, same cashback protection across all three. |
Is it actually worth the fee?
The fee model is a percentage of realized savings only. If Usage.ai saves nothing, you pay nothing. There is no subscription, no seat fee, no minimum.
The ROI math is straightforward. A team spending $500,000/year on AWS compute with 40% coverage today and 85% coverage after Usage.ai: the coverage improvement (45 percentage points x $500K x 50% average discount) is approximately $112,500/year in additional savings.
Usage.ai’s fee is a percentage of that $112,500 — not of your total cloud bill. The net savings after the fee are substantially positive for any team spending $100,000/month or more on eligible compute.
Two things make it worthwhile beyond the math. First, the buyback guarantee changes the risk profile of committing. The reason most teams under-commit is fear of waste. Remove that fear with a guaranteed buyback, and the right coverage level becomes achievable. Second, the 24-hour refresh versus Cost Explorer’s 72-hour cycle means commitments reflect current usage rather than three-day-old usage. At $6,000-12,000 per day in uncovered compute on a $5M/year bill, a 3-day lag is not an abstract inefficiency.
For teams who want to manage Savings Plans manually and have the engineering bandwidth to do it well, the manual process described in this guide works. For teams who want the coverage of an autonomous system and the safety of a buyback guarantee, Usage.ai is the alternative.
Frequently Asked Questions
1. How exactly do Compute Savings Plans apply discounts?
Every hour, the cloud provider applies Savings Plan discounted rates to your eligible compute usage (EC2, Fargate, Lambda on AWS; VMs, AKS, Functions on Azure) up to your committed hourly amount. The highest-discount usage is covered first. Usage above the commitment bills at standard on-demand rates. Unused commitment below the threshold is charged regardless.
2. What happens if I use less than my committed amount?
You pay the full committed amount. If you commit to $5/hour and use $3/hour of compute, you pay $5. The $2 of unused commitment is charged and lost — it does not carry forward to the next hour. This is why over-commitment is expensive: quiet periods compound the waste across every hour of the term.
3. Can I change my commitment amount after purchasing?
No. AWS and Azure Savings Plans cannot be modified or cancelled after purchase. You can add an additional commitment on top of an existing one (stacking), but you cannot reduce an existing commitment. Size conservatively before purchasing and layer up as utilization confirms the commitment is being fully used.
4. What is the difference between on-demand and Savings Plan rates?
On-demand is the default per-hour price for cloud compute with no commitment. Savings Plan rates are a discounted version of the on-demand price, earned by committing to consistent spend. A 60% Savings Plan discount means you pay 40% of the on-demand price for covered usage. The difference compounds significantly at scale: $1M/year of on-demand compute at 60% savings = $600K/year returned to the business.
5. Do Savings Plans work with Reserved Instances at the same time?
Yes, and they are designed to complement each other. Reserved Instances are applied first, covering usage matching their specific configuration. Savings Plans then cover remaining eligible usage up to the committed amount. Using both is the standard strategy for maximizing savings: RIs for stable specific-configuration workloads, Savings Plans for flexible coverage across everything else.
6. Does the Savings Plan discount apply in all regions?
Yes, for Compute Savings Plans (AWS) and Azure Savings Plans for Compute. Both plans apply automatically across all regions, all instance families, and all operating systems. You do not need to specify which region or instance family should receive the discount — it follows your usage wherever it runs.
