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.
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.
The commitment amount is a dollar figure: $X per hour. 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 hours only waste the difference between actual usage and committed amount, not the full committed amount.
If you want to understand how commitment-based discounts work across AWS, Azure, and GCP, we covered the full landscape here 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. 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. 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.
Example: You have committed to $5.00/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
- The remaining $3.00 of on-demand usage is billed at standard rates
- Your total bill for that hour: ~$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, 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 you have not committed to.
If your usage regularly exceeds your commitment by a significant margin, you have an under-committed Savings Plan. Savings Plans stack each new purchase on top of the previous ones, so you can add a second commitment at any time. You cannot modify an existing commitment upward.
Step 5: Unused Commitment Is Charged Regardless
This is the step most people underestimate. If you commit to $5.00/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. 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.
One scenario requiring attention: if you stack a new Savings Plan on top of an existing one, the combined committed amount across all active plans represents your total hourly commitment. Keep track to avoid unintentional over-commitment.
How AWS and Azure Apply Savings Plan Discounts Differently
The core mechanics are nearly identical. But there are two important differences.
*AWS: Reserved Instances First, Then Savings Plans
*
AWS applies discounts in a strict order: RIs first, then Savings Plans. The practical benefit is that RIs and Savings Plans genuinely complement each other. Purchase RIs for the stable, known-configuration core of your fleet. Use a Savings Plan for the flexible remainder. 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 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 (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. If you use $100 of eligible compute and your commitment is $80, Azure prices $80 at the Savings Plan rate and the remaining $20 at pay-as-you-go. If you only use $60 in an hour but commit $80, you lose $20 worth of benefit if it does not roll over.
If you are weighing term length, the tradeoffs between 1-year and 3-year commitments go deeper than just the discount percentage How to Choose Between 1-Year and 3-Year AWS Commitments
How to Size Your Commitment Correctly
One number determines whether your Savings Plan generates net savings or net waste: the commitment amount.
Pull 30–60 days of hourly compute spend. In AWS Cost Explorer, filter by 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).
Find the P70 of your hourly spend. Sort all hourly values lowest to highest. Find the value at the 70th percentile. 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. These 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, then layer up. First purchase: commit at P65–P70. Review utilization after 30 days. If utilization is consistently above 95%, add a second commitment on top. Savings Plans stack, you can layer additional commitments without modifying or cancelling the first.
Where Usage.ai Fits In
Every step above 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.
Usage.ai automates this entire process. The platform analyzes hourly compute spend with a 24-hour data 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.
The fee model is a percentage of realized savings only. If Usage.ai saves nothing, you pay nothing.
How does your team currently handle Savings Plan sizing manual P70 calculations, native AWS/Azure recommendations, or something else? Curious whether others have found a middle ground that works.
Continue reading the full technical analysis here → How Compute Savings Plans Work (Step-by-Step)
