.png)
There is a line on every cloud bill that represents money you paid for capacity you had but did not commit to. It is the gap between your on-demand rate and what you would have paid with a Savings Plan. For most teams running production workloads, that gap is 40-66% of their total compute cost.
Compute Savings Plans exist to close it. But buying them correctly — right type, right coverage level, right term — requires understanding mechanics that most guides skim past. This guide covers both AWS and Azure in full depth: how each platform’s Savings Plans work, what they cover, what they do not, how the discount application logic differs between the two clouds, and how to calculate a commitment that saves the most without generating waste.
If you have ever bought a Savings Plan and still wondered whether you bought the right one, this guide is for you.
What Is a Compute Savings Plan?
A Compute Savings Plan is a billing commitment you make to a cloud provider: you agree to spend a minimum dollar amount per hour on compute for 1 year or 3 years. The provider responds by discounting your per-unit compute rates — significantly.
The core mechanic is the same on both AWS and Azure. You commit to a dollar-per-hour floor. The provider applies discounts to your actual compute usage up to that floor. Usage above the floor is billed at standard on-demand rates. Usage below the floor is still charged at the committed amount. Every hour, without exception.
Compute Savings Plan (AWS): A flexible spending commitment covering EC2, Fargate, and Lambda. Up to 66% savings for 3-year All Upfront. Applies automatically across all instance families, regions, and operating systems. Source: aws.amazon.com/savingsplans. Verify — rates change.
Azure Savings Plan for Compute: A flexible spending commitment covering Azure VMs, Container Instances, App Service Premium v3 and Isolated v2, AKS workloads, Azure Virtual Desktop, Azure Databricks, and Azure Functions Premium. Up to 65% savings for 3-year term. Applies automatically across all VM series, regions, and operating systems.
What makes both products genuinely useful — and genuinely different from Reserved Instances — is the absence of configuration lock. You are not committing to specific machine types. You are committing to a dollar amount. Your instances can change completely during the term and the discounts continue to flow.
Also read: AWS Savings Plans: A Complete Guide
AWS Compute Savings Plans: The Full Picture
What AWS Compute Savings Plans Cover
Three AWS services receive Compute Savings Plan discounts:
EC2 Instances: All instance families, all regions, all operating systems. If you migrate from c5 to c6g (Graviton), change regions, or switch from Linux to Windows during the term — the discount follows. This is the defining advantage over EC2 Instance Savings Plans, which lock to a single instance family.
AWS Fargate: Compute charges for ECS and EKS tasks. Fargate on-demand pricing is notably higher than equivalent EC2, so the Fargate discount under a Compute Savings Plan is genuinely significant. 3-year Compute Savings Plans save up to approximately 52% on Fargate versus on-demand.
AWS Lambda: Lambda duration charges (measured in GB-seconds) are covered. Lambda request charges are not. The savings rate on Lambda duration is approximately 17% — smaller than EC2/Fargate but meaningful for Lambda-heavy architectures. Lambda has no Reserved Instance equivalent, making the Compute Savings Plan the only available discount mechanism for Lambda compute.
What AWS Compute Savings Plans do NOT cover: RDS, ElastiCache, DynamoDB, OpenSearch, Redshift, and other database and analytics services. Those require their own Reserved Instance products.
AWS Savings Plan Types: Compute vs EC2 Instance vs SageMaker
AWS offers multiple Savings Plan types. The confusion between them is real and worth addressing directly.
| Plan Type | Max Discount | Services Covered | Flexibility | Best For |
| Compute Savings Plan | Up to 66% | EC2 + Fargate + Lambda | All families, regions, OS | Mixed workloads, frequent changes, Fargate/Lambda coverage |
| EC2 Instance Savings Plan | Up to 72% | EC2 only (one instance family) | Any size within one family | Stable EC2 workloads in one instance family |
| SageMaker Savings Plan | Up to 64% | SageMaker instances only | All SageMaker instance types | ML training and inference at scale |
Source: aws.amazon.com/savingsplans. The 6% discount difference between Compute Savings Plans and EC2 Instance Savings Plans (66% vs 72%) is real but modest. For most teams, the flexibility of Compute Savings Plans across all families and services outweighs the 6-point gap.
Also read: What Are EC2 Instances
How AWS Applies Compute Savings Plan Discounts
AWS applies Savings Plan discounts to your hourly usage in a specific order. Understanding this order matters when you have both Savings Plans and Reserved Instances.
First: Reserved Instances are consumed against matching usage. If you have an EC2 RI for a specific instance type and that instance is running, the RI discount applies first. Second: Savings Plan discounts are applied to remaining usage, starting with the usage that generates the highest savings rate. Third: any usage above the committed hourly amount bills at on-demand rates.
This sequencing means Reserved Instances and Compute Savings Plans are genuinely complementary. Use RIs for the most stable, highest-savings-rate components of your fleet. Use a Compute Savings Plan as a flexible foundation that captures the remainder.
Azure Savings Plan for Compute: The Full Picture
Azure’s Savings Plan for Compute was introduced in October 2022 and has expanded significantly in coverage since. It is now the primary flexibility-based discount mechanism on Azure, sitting alongside Azure Reserved VM Instances the same way AWS Compute Savings Plans sit alongside EC2 RIs.
What Azure Savings Plan for Compute Covers
The coverage scope is broader than most guides acknowledge:
Azure Virtual Machines: All series (general-purpose, compute-optimized, memory-optimized, storage-optimized, GPU, high-performance compute) across all Azure regions and all operating systems. Excludes BareMetal Infrastructure and the legacy Av1 series.
Azure Kubernetes Service (AKS): The underlying VM compute used by AKS node pools is eligible for Savings Plan discounts, provided the VM series is on the eligible list. AKS cluster management fees are not covered.
Azure Virtual Desktop (AVD): VM compute charges for AVD session hosts are covered.
Azure Databricks: VM compute used by Databricks clusters is eligible. Databricks unit charges (DBUs) are not covered.
Azure Container Instances: Covered.
Azure Dedicated Host: Covered.
Azure App Service Premium v3 and Isolated v2: Covered. The older Premium v2 plan is not covered — the Savings Plan requires the upgraded plan tiers.
Azure Functions Premium plan: Covered. This is the Azure equivalent of Lambda coverage under AWS Compute Savings Plans.
What Azure Savings Plan for Compute does NOT cover: Azure SQL Database, Cosmos DB, Azure Cache for Redis, Azure Database for PostgreSQL/MySQL, Azure Blob Storage, and standard Azure Kubernetes Service management fees. Database savings on Azure use Azure Reserved Capacity (a separate product, analogous to RDS Reserved Instances on AWS). There is also a separate Azure Savings Plan for Databases, introduced in 2024, which covers SQL Database serverless — but this is not the compute savings plan.
Critical: Azure savings plans cannot be cancelled or modified after purchase. Once you commit to the hourly amount, it runs for the full 1-year or 3-year term. AWS Compute Savings Plans have the same constraint — neither cloud offers a cancellation or modification path for existing commitments. Verify your commitment amount carefully before purchasing on either platform. Source: learn.microsoft.com/azure/cost-management-billing/savings-plan/savings-plan-overview
Also read: Azure Cost Optimization Guide
How Azure Applies Savings Plan Discounts
Azure’s discount application logic has an important detail that differs from what most teams expect:
Reservations are applied before Savings Plans. If you have an Azure Reserved VM Instance for a specific VM size and that VM is running, the reservation discount applies first. The Savings Plan only picks up usage not covered by a reservation. This means having both a reservation and a Savings Plan is explicitly supported and recommended by Microsoft — the reservation captures the deepest discount on stable workloads, the Savings Plan provides flexible coverage for everything else.
Within Savings Plans, the discount is applied to the usage with the highest savings rate first. If you have two VMs running in the same hour — one with a 45% savings rate and one with a 30% rate — Azure applies the Savings Plan discount to the 45% rate VM first. This maximizes the value extracted from your hourly commitment. Source: learn.microsoft.com/azure/cost-management-billing/savings-plan/discount-application.
3-year Savings Plans are applied before 1-year Savings Plans. If you have both active, Azure prioritizes the plan with the better rates — the 3-year — to ensure you extract maximum benefit.
Auto-renewal is off by default. When your Azure Savings Plan term expires, your resources continue running but revert to pay-as-you-go rates. Azure sends email notifications 30 days before expiration and on the expiration date. Set up auto-renewal in the Azure portal if you want the commitment to continue without manual action.
Azure Hybrid Benefit: The Savings Plan Multiplier
This is the most important Azure-specific angle that no AWS equivalent exists for, and it meaningfully changes the savings calculus for many organizations.
Azure Hybrid Benefit allows organizations with existing Windows Server or SQL Server licenses with Software Assurance (or software subscriptions) to use those licenses on Azure VMs instead of paying the Azure Windows license surcharge. The result: the underlying VM hardware is discounted by the Savings Plan, and the Windows license is covered by Hybrid Benefit at no additional charge.
Combined savings: Azure Savings Plan for Compute saves up to 65% on the VM hardware. Azure Hybrid Benefit saves up to 40% more by eliminating the Windows Server licensing surcharge. Azure’s official documentation states that Savings Plans combined with Hybrid Benefit and Extended Security Updates can reduce costs by up to 85% compared to standard pay-as-you-go rates. Source: azure.microsoft.com/pricing.
AWS has no equivalent to Hybrid Benefit. Teams migrating from on-premises Windows Server environments to Azure — bringing their existing licenses — can stack this advantage on top of Savings Plan commitments in a way that is structurally unavailable on AWS.
Azure Hybrid Benefit + Savings Plan stacking: VM hardware covered at savings plan rate (up to 65% off), Windows Server license covered by Hybrid Benefit (up to 40% additional), SQL Server license covered separately (up to 85% combined). This stacking is explicitly supported — Savings Plans cover the hardware and Hybrid Benefit covers the software. Source: azure.microsoft.com/pricing.
Azure Savings Plan vs Azure Reserved VM Instances
The Azure decision between Savings Plans and Reserved Instances follows the same logic as on AWS, with one additional mechanic worth understanding.
| Azure Savings Plan for Compute | Azure Reserved VM Instances | |
| Max savings | Up to 65% | Up to 72% (varies by series/region) |
| Commitment type | Dollar-per-hour | Specific VM size + region |
| Flexibility | All VM series, regions, OS | Fixed size, region, OS |
| Capacity reservation | No capacity guarantee | Optional capacity reservation |
| Trade-in | N/A | Can trade in for a Savings Plan |
| Cancel/modify | Cannot cancel or modify | Exchange possible (with restrictions) |
| AKS/AVD/Databricks | Yes (underlying VMs covered) | Only if VM matches reservation |
Trade-in path: Azure allows you to exchange existing Reserved VM Instances for a Savings Plan (the new commitment value must be >= the prorated remaining value of the reservations). This enables teams with locked reservations to gain flexibility — a path that does not exist on AWS. Source: learn.microsoft.com/azure/cost-management-billing/savings-plan/reservation-trade-in.
AWS vs Azure Savings Plans: Side-by-Side Comparison
For teams running multi-cloud environments or evaluating both platforms, here is the definitive comparison:
| Dimension | AWS Compute Savings Plan | Azure Savings Plan for Compute | Winner | Notes |
| Max savings | Up to 66% | Up to 65% | Tie | Virtually identical ceiling |
| Term options | 1-year, 3-year | 1-year, 3-year | Tie | Same structure |
| Services covered | EC2 + Fargate + Lambda | VMs + AKS + AVD + Databricks + Container Instances + App Service + Functions | Azure (breadth) | Azure covers more managed services |
| Database coverage | No (use RDS RIs / DSP) | No (use Reserved Capacity) | Tie | Both need separate DB commitment products |
| License stacking | No equivalent to Hybrid Benefit | Azure Hybrid Benefit stacks (+up to 85% combined) | Azure | Significant advantage for Windows/SQL Server licensees |
| Capacity guarantee | No | No | Tie | Both Savings Plans lack capacity reservation |
| Discount application order | RIs first, then Savings Plans | Reservations first, then Savings Plans | Tie | Same logic: most restrictive discount applied first |
| Cancel/modify | Cannot cancel or modify | Cannot cancel or modify | Tie | Both lock in the commitment |
| Trade existing RIs for SP | Not available | Yes — trade VM RIs for Savings Plan | Azure | Azure-only flexibility path |
| Payment options | No Upfront, Partial, All Upfront | Monthly (equivalent to No Upfront), All Upfront | AWS (more options) | AWS has 3 payment tiers vs Azure’s 2 |
Sources: aws.amazon.com/savingsplans, azure.microsoft.com/pricing/offers/savings-plan-compute, learn.microsoft.com/azure/cost-management-billing/savings-plan. Verify current rates — these change.
How to Calculate the Right Commitment Amount: AWS and Azure
The biggest financial mistake teams make with Savings Plans is over-committing during a peak period and generating unused commitment waste during normal operations. The second-biggest is under-committing and leaving significant savings uncaptured. Here is the process that avoids both.
Step 1: Pull Your Actual Hourly Compute Spend
On AWS: go to Cost Explorer > Savings Plans > Coverage. Export the last 60 days of on-demand compute spend (EC2, Fargate, Lambda) at hourly granularity. On Azure: go to Cost Management > Cost analysis. Filter by resource type = Virtual Machines, Container Instances, and Functions. Export at daily granularity if hourly is not available, then divide by 24 for an hourly proxy.
Step 2: Find Your Baseline, Not Your Average
Sort your hourly spend values from lowest to highest. Your commitment should be at approximately your P70-P80 value — the spend level you are at or above for 70-80% of hours.
Why P70-P80 and not the average? The average includes your peak hours and your quietest hours equally. Committing to your average means you are generating commitment waste for the bottom 50% of hours. Committing to your P80 means you are covered with zero waste in 80% of hours, and the remaining 20% of higher-usage hours simply bill the excess at on-demand. That on-demand premium during peaks is almost always cheaper than the waste generated by over-committing.
Step 3: Account for Growth Trajectory
If your compute spend has been growing consistently over the last 60 days, factor in a modest growth assumption for the commitment term. For a 1-year commitment: use your current P75 plus 10-15% for anticipated growth. For a 3-year commitment: use your current P75 plus 20-30% growth assumption. Do not over-index on growth — a commitment built on optimistic projections generates real waste if the growth does not materialize.
Step 4: Validate Against Platform Recommendations
Both AWS Cost Explorer and Azure Cost Management provide Savings Plan recommendations based on your recent usage. Use them as a sanity check, not a starting point. AWS and Azure recommendations optimize for coverage, not for avoiding over-commitment. The platform recommendations will often suggest a higher commitment than your P75 calculation. Trust the math over the recommendation.
Step 5: Start Conservative, Expand Quarterly
If you are purchasing a Savings Plan for the first time, consider committing at your P60-P65 rather than P75-P80. Review utilization after 30 days. If your utilization rate (commitment consumed vs committed) is consistently above 95%, add an additional commitment to capture more savings. Savings Plans can be layered — you can purchase a new plan on top of an existing one, and the discounts stack. You cannot reduce an existing commitment, but you can refrain from purchasing more.
Usage.ai sizes commitments at the P70-P80 of hourly compute spend, refreshing the analysis every 24 hours versus Cost Explorer’s 72-hour cycle. If a commitment becomes underutilized because your workload drops, Usage.ai provides cashback in real money — not credits. The commitment adjusts quarterly. Verified from Usage.ai project documentation.
Also read: Azure Database Savings Plans: Pricing, Coverage & Trade-offs
Compute Savings Plans vs Reserved Instances: When to Use Which
Every team with stable cloud workloads should be using both products together. The real question is what proportion of your commitment spend should be in each product.
Use Compute Savings Plans (AWS) or Azure Savings Plans When:
Your compute footprint changes frequently — new instance families, region shifts, Graviton migrations on AWS, VM series upgrades on Azure. Any architectural change that would invalidate a specific RI commitment is a reason to use a Savings Plan for that portion of your fleet.
You run a mix of compute services. On AWS: if you use Fargate for container workloads and Lambda for event-driven processing alongside EC2, a single Compute Savings Plan covers all three. On Azure: if you use AKS alongside VMs and Azure Functions, the Azure Savings Plan covers all three categories under one commitment.
You want to simplify your commitment management. One Savings Plan commitment is operationally simpler than dozens of individual RIs across multiple instance families and regions.
Use Reserved Instances When:
You have a stable, long-running workload on a specific instance family or VM series that you are confident will not change configuration during the commitment term. RIs deliver the highest possible discount (up to 72% on AWS, up to 72% on Azure for certain VM series) precisely because they accept the configuration lock.
You need capacity guarantees. Azure Reserved VM Instances offer an optional capacity reservation that guarantees the reserved capacity is available in the target region. Savings Plans on both AWS and Azure do not offer capacity guarantees. For workloads that require confirmed capacity availability (disaster recovery targets, compliance-mandated minimum capacity), RIs with capacity reservation are the correct product.
Your database tier is significant. RDS Reserved Instances, Azure Reserved Capacity for databases, ElastiCache Reserved Nodes — these services are not covered by either platform’s compute Savings Plans and require their own commitment products.
The Most Effective Strategy: Layered Commitments
The FinOps teams achieving the highest savings rates use a layered approach rather than choosing one product or the other. The stable core of the fleet (specific instance families running predictably) is covered by Reserved Instances at the highest discount rate. The dynamic remainder — workloads that change configuration, services that scale unpredictably, new services launching during the term — is covered by a Savings Plan at a slightly lower rate but with full flexibility. This captures near-maximum savings on the stable portion and maintains flexibility for the rest.
Usage.ai Insured Flex Commitments deliver this layered approach automatically. The platform continuously evaluates your full compute and database footprint, purchases RIs for stable workloads and Savings Plans for flexible ones, and provides buyback guarantees if any commitment underperforms. Fee: percentage of realized savings only. Source: Usage.ai project documentation.
Start your free savings analysis with Usage.ai
Frequently Asked Questions
1. What is a Compute Savings Plan?
A Compute Savings Plan is a 1- or 3-year hourly spend commitment to a cloud provider. AWS Compute Savings Plans cover EC2, Fargate, and Lambda at discounts up to 66%. Azure Savings Plans for Compute cover Virtual Machines, AKS workloads, Container Instances, App Service, and Azure Functions Premium at discounts up to 65%. Discounts apply automatically across all regions, instance families, and operating systems — no specific configuration matching required.
2. How much do Compute Savings Plans save?
Up to 66% on AWS EC2 and Fargate with a 3-year All Upfront plan. Up to 65% on Azure VMs with a 3-year plan. Lambda savings on AWS are approximately 17%. 1-year terms save less — typically 30-45% depending on instance type and payment option. Verify current rates at aws.amazon.com/savingsplans/compute-pricing and azure.microsoft.com/pricing/offers/savings-plan-compute — rates change.
3. What is the difference between AWS Compute Savings Plans and EC2 Instance Savings Plans?
Compute Savings Plans apply across all EC2 instance families, regions, and operating systems, plus Fargate and Lambda. EC2 Instance Savings Plans lock to one EC2 instance family in one region and cover only EC2. EC2 Instance Savings Plans offer slightly higher maximum discounts (up to 72% vs 66%) in exchange for that restriction. Choose Compute Savings Plans for flexibility; EC2 Instance Savings Plans for maximum savings on a stable, family-specific fleet.
4. What does the Azure Savings Plan for Compute cover?
Azure VMs (all series except BareMetal and Av1), AKS node pool VMs, Azure Virtual Desktop VMs, Azure Databricks compute VMs, Container Instances, Dedicated Host, App Service Premium v3 and Isolated v2, and Azure Functions Premium. Does not cover Azure SQL Database, Cosmos DB, Redis Cache, or PostgreSQL/MySQL databases (those use Azure Reserved Capacity). Source: azure.microsoft.com/pricing/offers/savings-plan-compute.
5. Can I stack Azure Hybrid Benefit with a Savings Plan?
Yes. Azure Savings Plan for Compute covers VM hardware costs. Azure Hybrid Benefit covers the Windows Server or SQL Server license running on that hardware. The two stack: your VM hardware is discounted by the Savings Plan rate (up to 65%), and the OS/database license is covered by Hybrid Benefit at effectively no charge if you bring eligible existing licenses. Combined savings can reach up to 85% versus standard pay-as-you-go rates. Source: azure.microsoft.com/pricing.
6. Can I cancel a Compute Savings Plan?
No. AWS Compute Savings Plans and Azure Savings Plans for Compute cannot be cancelled or modified after purchase. The commitment runs for the full 1- or 3-year term. On Azure, you can trade existing Reserved VM Instances for a Savings Plan, but the reverse is not available. On both platforms: verify your commitment amount carefully before purchasing, because there is no exit path.
7. What happens to unused Savings Plan commitment?
Unused committed hours are charged and lost. If your commitment is $5/hour and you only use $3/hour of compute in a given hour, you pay $5 and the $2 difference is gone. This is why sizing the commitment correctly matters: over-committing generates waste that negates the discount advantage. Set commitments at P70-P80 of your hourly compute baseline, not at your peak.
8. Are Reserved Instances better than Savings Plans?
It depends on workload stability. Reserved Instances offer higher maximum discounts (up to 72% vs 66% on AWS; similarly on Azure) but lock to specific configurations. Savings Plans offer lower maximums with full flexibility. For most teams, the best outcome combines both: Reserved Instances for the stable core fleet, Savings Plans for everything else. For teams whose architectures change frequently or who run Fargate and Lambda, Compute Savings Plans alone may be the simpler and financially comparable choice.
