AWS
Microsoft Azure
Google Cloud
Most cloud cost optimization guides treat each provider in isolation. That works if you operate on a single cloud. It breaks down completely when your infrastructure is split across AWS, Azure, and GCP — which is the reality for the majority of enterprise engineering organizations in 2026.
The fundamental problem: AWS, Azure, and GCP use different commitment models with different billing units, different flexibility mechanics, and different lock-in risks. Applying the same purchasing strategy across all three clouds leads to systematic over-commitment on some, under-commitment on others, and coverage gaps that only become visible when you compare all three commitment positions simultaneously.
This guide covers the commitment mechanics for each cloud, the key structural differences that determine strategy, the specific mistakes multi-cloud teams make, and how to build a unified savings plan approach that maximizes discount coverage without locking in more than your workloads justify.
See exactly what you’re overpaying across AWS, Azure, and GCP in under 60 seconds. Try the Calculator for free →
Commitment Mechanics: How Each Cloud Structures Discounts
AWS: Spend-Based Commitments, Maximum Flexibility
AWS offers two savings plan types for compute. The Compute Savings Plan commits to a dollar amount per hour and applies the discount automatically across EC2, AWS Fargate, and AWS Lambda — across any region, any instance family, any size, any operating system, and any tenancy. This is the most flexible commitment model of the three major clouds. If you migrate an EC2 workload from c5 to c6g, move it from us-east-1 to eu-west-1, or shift it from EC2 to Fargate, the same Compute Savings Plan continues covering it. Source: AWS official Savings Plans documentation.
The EC2 Instance Savings Plan is narrower: it locks to a specific instance family and region (for example, m6i in us-east-1) but delivers a deeper discount on those instances. Flexible workloads belong on Compute Savings Plans. Stable, family-locked production workloads where the deeper discount is worth the reduced flexibility belong on EC2 Instance Savings Plans. Source: AWS official.
AWS advertises up to 66% for Compute Savings Plans and up to 72% for EC2 Instance Savings Plans. These are plan-family maxima, not a 66% one-year No Upfront quote. Actual rates depend on instance, Region, OS, term and payment option. Source: AWS Savings Plans FAQ.
Azure: Two Parallel Commitment Models
Azure runs two parallel commitment models for compute. Azure Savings Plans for Compute commit to a $/hr spend level across eligible compute (Virtual Machines, Azure Kubernetes Service, App Service Premium v3 and Isolated v2, Azure Container Instances, Azure Functions Premium). Like AWS Compute Savings Plans, the discount applies regardless of VM series, region, or OS. Four scope options: resource group, subscription, management group, and shared (billing account-wide). Source: Microsoft Azure official pricing page.
Azure Reserved VM Instances commit to a specific VM size and region for 1 or 3 years — a model closer to AWS EC2 Instance Savings Plans or EC2 Reserved Instances. Reserved VM Instances can be exchanged or refunded under certain conditions, providing some flexibility if workload requirements change. Up to 72% savings (3-year All Upfront). Source: Microsoft Azure official pricing.
Microsoft advertises up to 65% for Azure savings plan for compute and up to 72% for Reserved VM Instances, based on specific three-year examples. These maxima are not universal one-year discounts, and reservations and savings plans do not both discount the same compute usage. Eligible Azure Hybrid Benefit licensing can provide a separate benefit. Sources: Azure savings plans and Azure reservations.
GCP: Resource-Based CUDs and Automatic SUDs
Google Cloud offers resource-based commitments and spend-based compute flexible CUDs. Flexible CUDs cover eligible Compute Engine, GKE and Cloud Run usage across regions. Resource-based commitments retain resource, region and machine-series constraints; they do not cover every VM series interchangeably.
Discounts depend on the resource and term. For example, current flexible CUD rates for many general-purpose Compute Engine series are 28% for one year and 46% for three years. Other series differ. Source: Google Cloud CUD documentation.
Sustained Use Discounts apply automatically only to eligible resources, not every VM. Maximum monthly discounts vary, commonly 20% or 30%, and depend on utilization. Do not stack SUDs onto usage already receiving a CUD. Source: Google Cloud SUD documentation.
The Three Commitment Models Side by Side
Pricing framework checked October 15, 2026. Compare the exact SKU, term, region and eligibility rather than treating advertised maxima as like-for-like quotes.
| Dimension | AWS | Azure | Google Cloud |
|---|---|---|---|
| Spend-based compute commitment | Compute / EC2 Instance Savings Plans | Savings plan for compute | Compute flexible CUDs |
| Other commitment model | Reserved Instances | Reserved VM Instances | Resource-based CUDs |
| Advertised compute-plan discount | Compute up to 66%; EC2 Instance up to 72% | Savings plan up to 65%; reservations up to 72% | Varies by series and model; no universal 37% / 55% rule |
| Cross-region flexibility | Compute SP across eligible Regions; EC2 Instance SP fixed family/Region | Depends on plan and scope | Flexible CUDs across eligible Regions; resource commitments region-specific |
| Automatic sustained-use benefit | No general EC2 sustained-use discount | No general VM sustained-use discount | Eligible resources only; not all VM series |
| Evaluation | Compare actual hourly usage and plan-rate commitment | Account for licensing benefits and scope | Choose flexible or resource model, then check eligibility |
The Four Multi-Cloud Commitment Mistakes
Mistake 1: Treating each cloud independently with separate FinOps processes
The most common multi-cloud commitment mistake is siloed management: one team owns AWS Cost Explorer recommendations, another handles Azure Advisor, a third watches GCP Cost Recommender. Each team optimizes for their cloud in isolation, using native tools that share no interface and express coverage in incomparable units (AWS in $/hr, GCP in vCPU+GB, Azure in $/hr or VM size). Coverage gaps at the seams between clouds are invisible in this model.
Coverage of 87% on AWS, 72% on Azure and 91% on GCP does not imply 82% combined coverage. With equal eligible On-Demand-equivalent spend, the mean is 83.33%. Otherwise calculate (covered eligible spend across providers) ÷ (total eligible spend across providers). Remaining savings also depend on each workload’s discount and utilization; coverage alone does not determine a dollar opportunity.
Mistake 2: Applying AWS-style $/hr commitment thinking to GCP
First identify the Google Cloud commitment type. Resource-based CUDs require resource quantities and regional constraints; compute flexible CUDs use an hourly spend commitment. Applying the wrong model leads to incorrect sizing.
Overcommitting resource quantities can leave unused commitments. For variable workloads, compare available flexible CUDs, eligible SUDs and On-Demand pricing rather than assuming every workload automatically receives 20–30% off.
Mistake 3: Ignoring Azure Hybrid Benefit when scoping commitments
For organizations running Windows Server or SQL Server workloads with existing Software Assurance licenses, Azure Hybrid Benefit allows those licenses to be applied to Azure compute and database services — potentially cutting the effective VM cost by 40-85% for licensed workloads. Teams that scope Azure Savings Plans without accounting for Azure Hybrid Benefit commit to a higher $/hr than necessary, over-shooting the actual billable compute cost after license credits.
The correct Azure commitment sizing sequence: (1) apply Azure Hybrid Benefit to all eligible Windows/SQL workloads, (2) calculate the remaining on-demand cost after license credits, (3) size Savings Plans and Reserved VM Instances against the post-Hybrid-Benefit cost floor. Source: vendorbenchmark.com enterprise benchmark data (April 2026) and Azure official documentation.
Mistake 4: Buying commitment on workloads before right-sizing
Right-size before buying commitments. Suppose a $5/hour AWS plan is fully consumed at Savings Plans rates and covered usage then falls 30% to $3.50/hour. The unused commitment is $1.50/hour, or 30% of the original commitment. The commitment is 42.86% larger than remaining usage, not 30%, and the unused share is not one-third. This example assumes a constant rate mix and no other eligible usage to consume the balance.
Right-size first, confirm the new stable utilization pattern, then commit. For each cloud: (1) run the native cost optimization recommendations (AWS Compute Optimizer, Azure Advisor right-sizing, GCP VM Recommender), (2) implement the right-sizing, (3) monitor for 30 days to confirm the new utilization floor, (4) purchase commitments sized to that confirmed floor. Source: consistent with AWS, Azure, and GCP official best practices documentation.
The Unified Multi-Cloud Savings Plan Strategy
Step 1: Normalize spend to a common unit
Normalize coverage using eligible On-Demand-equivalent spend, while tracking actual discounted commitment payments separately. Converting everything to dollars does not make these two measures interchangeable. Keep resource quantities and regional restrictions alongside spend for resource-based commitments.
Step 2: Identify the stable floor per cloud separately
The correct commitment level for each cloud is the consistent floor of hourly eligible compute spend — the level that is reliably met in every hour, including overnight, weekends, and seasonal low periods. This floor is calculated separately per cloud because each cloud’s workload patterns differ. AWS may have a steady $8/hr floor from production EC2. Azure may have a variable pattern with a $2/hr floor because dev workloads scale down on weekends. GCP may have stable 80 vCPUs in us-central1 at all times for data pipeline workloads.
Price the intended covered floor at the selected plan’s discounted rates, then size each provider independently. Do not average floors across clouds or transfer unused commitment headroom between providers — savings plans are provider-specific instruments.
Step 3: Match commitment type to workload stability per cloud
AWS: use Compute Savings Plans for workloads with variable instance type and region mix. Use EC2 Instance Savings Plans only for production workloads with a confirmed, stable instance family and region that will not change for 1-3 years.
Azure: use Savings Plans for variable workload environments where VM series or region might change. Use Reserved VM Instances only for production VMs with confirmed stable VM size and region. Apply Azure Hybrid Benefit before sizing either commitment type. Use Shared scope for maximum utilization across a multi-subscription billing account.
GCP: compare resource-based and compute flexible commitments for the actual workload. Check SUD eligibility separately for uncommitted usage.
Step 4: Apply the 60-day confirmation window before committing
After any right-sizing or workload migration, wait 60 days before purchasing or renewing commitments. The first 30 days often show temporary utilization patterns as caches warm, traffic settles, and teams adjust. Day 31-60 provides a cleaner signal of the new stable floor. Source: consistent with AWS official recommendation guidance and Usage.ai internal methodology.
Step 5: Monitor and adjust continuously — not annually
Multi-cloud commitment positions go stale. AWS workloads shift to Fargate or Lambda. Azure VMs scale out. GCP adds a new region. Native interfaces have different data freshness and recommendation schedules; check actual timestamps and available refresh controls for each provider. A commitment position that was correctly sized 6 months ago may be materially wrong today.
A three-day interval at $6,000–$12,000/day represents $18,000–$36,000 of observed spend, not that amount of lost savings. At an illustrative 30% discount, the potential opportunity on fully eligible, consistently used capacity is $5,400–$10,800. Check recommendation timestamps and refresh options; AWS permits up to three recommendation refresh requests per day per consolidated billing family. Source: AWS Savings Plans quotas.
How Usage.ai Handles Multi-Cloud Commitment Optimization
Usage.ai supports AWS, Azure, and GCP under a single platform. The same commitment optimization methodology — 24-hour recommendation refresh, floor-based commitment sizing, Insured Flex Commitments, and cashback on underutilization — applies across all three clouds in a unified dashboard.
For AWS, Usage.ai can execute approved commitment purchases. Actual discounts depend on eligible usage, product, rates and fees. Flex protection is subject to the applicable agreement and should be evaluated separately from the underlying AWS term.
For Azure: Usage.ai analyzes Azure billing export data to identify Savings Plan and Reserved VM Instance opportunities, scopes recommendations at the shared billing account level for maximum pooling, and incorporates Azure Hybrid Benefit eligibility into commitment sizing before recommending a $/hr commitment level.
For GCP: Usage.ai distinguishes between resource-based CUD opportunities (stable vCPU+memory demand in specific regions) and SUD-covered workloads (variable demand where commitment is not justified), avoiding the GCP-specific trap of over-committing vCPUs in variable workloads.
Refresh cadence and lookback windows are different. Inspect each recommendation’s actual timestamp and available refresh controls before assigning a cost to stale data. A claimed platform refresh interval does not by itself prove a savings advantage.
Confirm protection eligibility for each cloud, service and commitment under the applicable agreement. Do not assume every purchase, migration or usage drop qualifies. Published cashback documentation compares eligible commitment cost with equivalent On-Demand cost for the same usage and describes payment 90 days after accrual. Cashback documentation.
See how Usage.ai optimizes commitment coverage across AWS, Azure, and GCP simultaneously
Usage.ai Insured Flex Commitments: Check Protection Across Clouds
Commitments have service-specific term obligations and limited change policies. AWS permits eligible Savings Plans returns within seven days, in the purchase calendar month, for commitments of $100/hour or less; outside that policy the term continues. Azure reservations have conditional exchange/refund rules, while Azure savings plans have different restrictions. Verify current provider terms and any separate Usage.ai contract before treating a commitment as cancellable.
Usage.ai Insured Flex Commitments can reduce specified financial exposure under the agreement. Review eligibility, adjustment and exit rights, exclusions and payout timing. Cashback is not a refund of every unused dollar and does not cancel the underlying provider commitment.
Size commitments from stable post-optimization usage and expected changes. Contractual protection can mitigate defined losses but does not justify assuming risk-free purchases or that every commitment can adjust with demand.
Compare each vendor’s current written protection terms. This article does not substantiate an industry-wide claim that only one platform pays cash or that all competitors offer credits only.
See exactly what you’re overpaying across AWS, Azure, and GCP in under 60 seconds. Try the Calculator for free →
Frequently Asked Questions
1. What is the difference between AWS, Azure, and GCP commitment discounts?
AWS and Azure offer hourly spend commitments and reservation-style products. Google Cloud offers both compute flexible spend commitments and resource-based commitments. Advertised discount ceilings are not comparable price quotes: match the resource, region, term and usage assumptions first.
2. How do you manage savings plans across multiple clouds?
The core steps: (1) normalize all cloud spend to a common $/hr unit for apples-to-apples comparison; (2) calculate each cloud’s stable floor spend independently over 60 days; (3) match the commitment type to workload stability per cloud (Compute SP for variable AWS, resource CUDs only for stable GCP regions, Azure SP for variable Azure); (4) right-size before committing; (5) use a platform with cross-cloud visibility and 24-hour refresh rather than three separate native tools. The biggest risk is managing each cloud in isolation and missing coverage gaps at the seams.
3. Does GCP have a savings plan equivalent?
Yes. Compute flexible CUDs are spend-based and cover eligible Compute Engine, GKE and Cloud Run usage. Google Cloud also offers resource-based CUDs. See the provider documentation linked above for eligibility and current rates.
4. What makes multi-cloud commitment management hard?
Providers use different eligible resources, commitment scopes, rate bases and change policies. Track actual usage, purchased commitment, coverage and utilization separately. A lookback period is not the same thing as a recommendation refresh interval.
5. How does Usage.ai handle multi-cloud savings plans?
Usage.ai supports AWS, Azure, and GCP under a single platform with 24-hour recommendation refresh across all three. For AWS: Insured Flex Commitments with buyback guarantee and cashback on underutilization. For Azure: Savings Plan and RI recommendations scoped to shared billing account level. For GCP: distinguishes CUD opportunities from SUD-covered workloads to avoid over-commitment. Protection depends on cloud, product, commitment eligibility and the applicable agreement; it does not cover every purchase automatically. Fee: percentage of realized savings only. Source: Usage.ai platform documentation.
