Cloud Commitment Discounts Guide (2026) |

Why Commitment-Based Discounts Are the Biggest Lever in Your Cloud Bill

Here's the uncomfortable truth: if your organization runs workloads on AWS, Azure, or GCP without commitment-based discounts, you're likely overpaying by 30-72% on compute alone. That's not a small rounding error — that's potentially hundreds of thousands of dollars a year walking out the door.

Public cloud spending is projected to hit $1.03 trillion in 2026, and studies consistently show that organizations waste 25-35% of their cloud spend. Commitment discounts — Savings Plans, Reserved Instances, and Committed Use Discounts — remain the single highest-impact optimization available. Yet many teams either skip them entirely or commit incorrectly (and honestly, I've seen both scenarios play out more times than I can count).

This guide walks you through every commitment-based pricing model across all three major cloud providers, with practical CLI commands, calculation methodologies, and automation strategies you can implement today.

How Commitment Discounts Work: The Core Concept

Every cloud provider offers the same fundamental deal: commit to consistent usage over 1 or 3 years, and receive a significant discount versus on-demand pricing. The commitment types differ by provider, but the economics are universal.

The key decision framework comes down to three variables:

Flexibility vs. discount depth — More flexible commitments (Compute Savings Plans, spend-based CUDs) give smaller discounts than rigid ones (Standard RIs, resource-based CUDs).
Term length — 3-year terms provide deeper discounts but higher forecasting risk.
Payment structure — All-upfront gives you the maximum discount; no-upfront preserves cash flow.

Think of it like a gym membership. Monthly is pricey but flexible. An annual plan saves money but you're stuck with it. And the 3-year deal? Great discount, but you'd better really love that gym.

AWS Commitment Discounts: Savings Plans vs. Reserved Instances

AWS Savings Plans

AWS Savings Plans are monetary commitments — you commit to a consistent dollar-per-hour spend, and AWS automatically applies discounts to eligible usage. There are three types:

Compute Savings Plans — Up to 66% off. Apply across EC2, Fargate, and Lambda regardless of region, instance family, OS, or tenancy. Maximum flexibility.
EC2 Instance Savings Plans — Up to 72% off. Locked to a specific instance family within a region, but flexible on size, OS, and tenancy.
SageMaker Savings Plans — Up to 64% off on SageMaker ML instance usage.

AWS Reserved Instances

Reserved Instances (RIs) commit to specific instance configurations rather than a dollar amount:

Standard RIs — Up to 72% off. Locked to instance type, region, OS, and tenancy. Can't be exchanged.
Convertible RIs — Up to 54% off. Can be exchanged for different instance families, OS, or tenancy during the term.

When to Use Each on AWS

For most teams in 2026, here's the recommended strategy:

Compute Savings Plans as the primary commitment vehicle for EC2 and serverless workloads — flexibility makes them the safest default.
EC2 Instance Savings Plans for stable, predictable workloads where you know the instance family and region won't change.
Standard RIs for databases (RDS, ElastiCache, Redshift, OpenSearch) where instance configurations rarely change and capacity reservation is valuable.

If you're unsure where to start, go with Compute Savings Plans. You can always layer on more specific commitments later once you have better data.

Get AWS Savings Plans Recommendations via CLI

Before purchasing anything, pull recommendations based on your actual usage history:

# Get Savings Plans purchase recommendations for Compute type
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER

# Get recommendations for EC2 Instance Savings Plans
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type EC2_INSTANCE_SP \
  --term-in-years THREE_YEARS \
  --payment-option ALL_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER

Check Current Savings Plans Utilization

# View Savings Plans utilization for the last 30 days
aws ce get-savings-plans-utilization \
  --time-period Start=$(date -u -d "30 days ago" +%Y-%m-%d),End=$(date -u +%Y-%m-%d)

# View Savings Plans coverage to find uncovered On-Demand spend
aws ce get-savings-plans-coverage \
  --time-period Start=$(date -u -d "30 days ago" +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE_FAMILY

Purchase a Savings Plan via CLI

# Purchase a 1-year Compute Savings Plan at $5.00/hour, no upfront
aws savingsplans create-savings-plan \
  --savings-plan-offering-id <offering-id> \
  --commitment 5.00 \
  --tags Key=Team,Value=Platform Key=Environment,Value=Production

# First, find available offerings
aws savingsplans describe-savings-plans-offerings \
  --savings-plan-types COMPUTE_SP \
  --payment-options NO_UPFRONT \
  --plan-types "1-year"

Azure Commitment Discounts: Reservations and Savings Plans

Azure Reserved Instances

Azure Reservations provide up to 72% savings on compute, databases, storage, and other services when you commit to 1-year or 3-year terms. Unlike AWS, Azure Reservations can also cover non-compute services like Azure SQL Database, Cosmos DB, Azure Synapse, and Azure Blob Storage reserved capacity.

A unique advantage on Azure is the Hybrid Benefit program. Organizations with existing Windows Server or SQL Server licenses can stack license benefits with Reservations to achieve up to 76% savings — making Azure particularly attractive for Microsoft-heavy enterprises. If your org is already paying for SA licenses, you'd be leaving money on the table by not using this.

Azure Savings Plans for Compute

Launched to mirror AWS Savings Plans, Azure Savings Plans for Compute let you commit to a fixed hourly spend on compute services. They automatically apply to VMs, App Service, Container Instances, and Azure Premium Functions across all regions and VM series.

Azure Reservation Recommendations via CLI

# Get reservation recommendations for VMs (single subscription scope)
az consumption reservation recommendation list \
  --scope "Single" \
  --resource-type VirtualMachines \
  --look-back-period Last60Days \
  --output table

# List existing reservations and their utilization
az reservations reservation-order list \
  --output table

# Check reservation utilization summaries
az consumption reservation summary list \
  --reservation-order-id <order-id> \
  --grain monthly \
  --start-date 2026-01-01 \
  --end-date 2026-03-31

Purchase Azure Reservations via REST API

# Azure Reservation purchase via REST API
curl -X PUT \
  "https://management.azure.com/providers/Microsoft.Capacity/reservationOrders/<order-id>?api-version=2022-11-01" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sku": { "name": "Standard_D4s_v5" },
    "location": "eastus",
    "properties": {
      "reservedResourceType": "VirtualMachines",
      "billingScopeId": "/subscriptions/<sub-id>",
      "term": "P1Y",
      "quantity": 5,
      "displayName": "prod-web-tier-reservation",
      "appliedScopeType": "Shared",
      "renew": true
    }
  }'

Trade-In: Convert Azure Reservations to Savings Plans

Here's something a lot of people don't realize — Azure offers a self-service trade-in that lets you convert existing Reservations into Savings Plans. When you trade in, Microsoft cancels the reservation, issues a pro-rated refund, and applies it as credit toward the new Savings Plan.

One important caveat: this is a one-way conversion. You can't trade a Savings Plan back into a Reservation.

GCP Commitment Discounts: CUDs and Sustained Use Discounts

Resource-Based Committed Use Discounts

Resource-based CUDs commit you to a specific amount of vCPUs and memory in a region. They provide up to 57% off for 1-year terms and 70% off for 3-year terms. These discounts apply automatically to any VM in the same family within the committed region.

Spend-Based Committed Use Discounts

Spend-based CUDs work more like AWS Compute Savings Plans — you commit to a minimum hourly spend on specific services (Cloud Run, Cloud SQL, AlloyDB) in exchange for approximately 28% savings on 1-year terms and 46% on 3-year terms.

Sustained Use Discounts (Automatic)

GCP uniquely offers Sustained Use Discounts (SUDs) that apply automatically with zero commitment. VMs running more than 25% of a billing month receive incremental discounts up to 30% off. So even before purchasing CUDs, GCP provides baseline savings for consistent workloads — which is pretty nice.

2026 Update: GCP CUD Migration to Direct Discount Model

As of January 2026, Google is migrating eligible billing accounts from the legacy credit-based CUD model to a new direct-discount model. Under the new model, you're charged the discounted price directly rather than receiving credits after the fact.

If your organization has existing CUDs, verify that your billing accounts have been migrated and update any cost reporting that relied on the credit-based flow. This caught a few teams off guard, so it's worth checking sooner rather than later.

Purchase GCP CUDs via gcloud CLI

# Create a 3-year resource-based CUD for general-purpose compute
gcloud compute commitments create prod-commitment-3yr \
  --region=us-central1 \
  --resources=vcpu=32,memory=128GB \
  --plan=36-month \
  --type=GENERAL_PURPOSE

# Create a 1-year CUD for compute-optimized workloads
gcloud compute commitments create ml-training-commitment \
  --region=us-east1 \
  --resources=vcpu=64,memory=256GB \
  --plan=12-month \
  --type=COMPUTE_OPTIMIZED

# List existing commitments
gcloud compute commitments list \
  --regions=us-central1,us-east1 \
  --format="table(name,region,status,plan,startTimestamp,endTimestamp)"

# Get CUD purchase recommendations
gcloud recommender recommendations list \
  --recommender=google.compute.commitment.UsageCommitmentRecommender \
  --location=us-central1 \
  --project=my-project \
  --format="table(name,description,primaryImpact.costProjection)"

How to Calculate the Right Commitment Level

Over-committing wastes money on unused commitments. Under-committing leaves savings on the table. Finding the sweet spot isn't magic — it's just math (with a healthy dose of caution).

Step 1: Establish Your Baseline Usage

Pull at least 60 days of usage data to identify your minimum consistent hourly spend — not your average, your floor. This distinction matters more than most people think.

# AWS: Get daily on-demand compute costs for the past 60 days
aws ce get-cost-and-usage \
  --time-period Start=2026-01-30,End=2026-03-31 \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --filter '{
    "Dimensions": {
      "Key": "PURCHASE_TYPE",
      "Values": ["On Demand Instances"]
    }
  }' \
  --group-by Type=DIMENSION,Key=SERVICE

Step 2: Apply the 80% Rule

Once you know your minimum consistent hourly on-demand spend, commit to 80% of that number. This accounts for workload variability, seasonal dips, and future architecture changes.

Example calculation:

Monthly on-demand compute spend: $14,600
Hourly rate: $14,600 / 730 hours = $20.00/hour
Minimum hourly spend (from 60-day analysis): $16.50/hour
Recommended commitment: $16.50 × 0.80 = $13.20/hour

I know it feels conservative. But trust me, you'd rather leave a little savings on the table than lock yourself into a commitment you can't use.

Step 3: Layer Your Commitments

Use a layered approach rather than a single large commitment:

Base layer (60-70%) — Cover with Savings Plans or CUDs at the deepest discount tier (3-year, all-upfront).
Flex layer (10-20%) — Cover with more flexible commitments (1-year Compute Savings Plans or spend-based CUDs).
On-demand buffer (10-20%) — Leave uncovered for variability and burst capacity.
Spot/preemptible (optional) — Use for fault-tolerant and batch workloads.

Cross-Provider Comparison: Side by Side

If you're running multi-cloud (or evaluating providers), this table should save you some time:

Feature	AWS	Azure	GCP
Flexible compute commitment	Compute Savings Plans (up to 66%)	Savings Plans for Compute (up to 65%)	Spend-based CUDs (up to 46%)
Instance-specific commitment	EC2 Instance SP / Standard RI (up to 72%)	Reserved VM Instances (up to 72%)	Resource-based CUDs (up to 70%)
Automatic discounts	None	None	Sustained Use Discounts (up to 30%)
Database commitments	RDS/Redshift RIs, Database SP	Reserved Capacity (SQL, Cosmos DB)	Spend-based CUDs (Cloud SQL, AlloyDB)
License stacking	N/A	Hybrid Benefit (up to 76% total)	N/A
Term options	1 or 3 years	1 or 3 years	1 or 3 years
Cancellation policy	Non-cancellable (7-day exception for SP under $100/hr)	Reservations can be exchanged or refunded (limits apply)	Non-cancellable, non-refundable
Scope control	RISP Group Sharing (new)	Resource group / subscription / shared	Project or billing account

Monitor Commitment Utilization with Terraform

Buying commitments is only half the battle — you need to monitor them too. Set up automated alerts when your commitment utilization drops below thresholds, indicating waste:

AWS: Savings Plans Utilization Budget

resource "aws_budgets_budget" "savings_plans_utilization" {
  name         = "savings-plans-utilization-alert"
  budget_type  = "SAVINGS_PLANS_UTILIZATION"
  limit_amount = "100"  # Target 100% utilization
  limit_unit   = "PERCENTAGE"
  time_unit    = "MONTHLY"

  cost_types {
    include_credit             = false
    include_discount           = false
    include_other_subscription = false
    include_recurring          = false
    include_refund             = false
    include_subscription       = true
    include_support            = false
    include_tax                = false
    include_upfront            = false
    use_blended                = false
  }

  notification {
    comparison_operator       = "LESS_THAN"
    threshold                 = 80
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_email_addresses = ["[email protected]"]
  }
}

# RI Coverage alert
resource "aws_budgets_budget" "ri_coverage" {
  name         = "ri-coverage-alert"
  budget_type  = "RI_COVERAGE"
  limit_amount = "80"
  limit_unit   = "PERCENTAGE"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator       = "LESS_THAN"
    threshold                 = 70
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_email_addresses = ["[email protected]"]
  }
}

GCP: CUD Utilization Monitoring with Cloud Monitoring

resource "google_monitoring_alert_policy" "cud_utilization" {
  display_name = "CUD Utilization Below Threshold"
  combiner     = "OR"

  conditions {
    display_name = "Low CUD utilization"
    condition_threshold {
      filter          = "resource.type=\"compute.googleapis.com/Commitment\" AND metric.type=\"compute.googleapis.com/instance/cpu/utilization\""
      comparison      = "COMPARISON_LT"
      threshold_value = 0.7
      duration        = "3600s"
      aggregations {
        alignment_period   = "3600s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }

  notification_channels = [google_monitoring_notification_channel.finops_email.name]
}

AWS RISP Group Sharing: Control Commitment Distribution

One of the most significant 2026 developments is AWS RISP (Reserved Instances and Savings Plans) Group Sharing, which became generally available in late 2025. This feature solves a long-standing pain point that has frustrated FinOps teams for years: when one team purchases a commitment, the discount might end up benefiting a completely different team's workloads due to how AWS optimizes discount application.

It's the kind of thing that makes chargeback conversations really awkward.

How RISP Group Sharing Works

You create groups using AWS Cost Categories that reflect your organizational structure — by business unit, project, region, or funding source. Then you choose between two sharing modes:

Prioritized Group Sharing — Commitments apply to accounts within the defined group first, then spill over to the rest of the organization if unused. This maximizes utilization while preserving accountability.
Restricted Group Sharing — Commitments stay exclusively within defined groups. Essential for public sector, regulated industries, or strict chargeback requirements.

Setting Up RISP Group Sharing

# Step 1: Create a Cost Category for your business units
aws ce create-cost-category-definition \
  --name "BusinessUnit" \
  --rule-version "CostCategoryExpression.v1" \
  --rules '[
    {
      "Value": "Engineering",
      "Rule": {
        "Dimensions": {
          "Key": "LINKED_ACCOUNT",
          "Values": ["111111111111", "222222222222"]
        }
      }
    },
    {
      "Value": "Marketing",
      "Rule": {
        "Dimensions": {
          "Key": "LINKED_ACCOUNT",
          "Values": ["333333333333", "444444444444"]
        }
      }
    }
  ]'

# Step 2: Configure sharing preferences via the AWS Billing Console
# Navigate to: Billing > Preferences > RI and Savings Plans sharing
# Select your Cost Category and choose Prioritized or Restricted mode

Building a Multi-Cloud Commitment Strategy

Organizations running workloads across two or more clouds need a unified commitment strategy. Here's a practical framework that actually works:

1. Centralize Visibility First

Before committing to anything, aggregate cost and usage data across all clouds into a single view. Use tools like Vantage, CloudHealth, Apptio, or open-source solutions like OpenCost. You can't optimize what you can't see.

2. Right-Size Before Committing

Never — and I mean never — purchase commitments on top of waste. Run right-sizing analysis on every cloud first using AWS Compute Optimizer, Azure Advisor, and GCP Recommender. Eliminate idle resources and right-size over-provisioned ones. Then calculate your commitment baseline from the optimized spend.

3. Stagger Commitment Terms

Avoid locking 100% of your commitments into the same expiration date. Instead, stagger purchases quarterly so you always have a portion coming up for renewal. This gives you flexibility to adjust as workloads evolve.

4. Start with 1-Year Terms

For your first commitment purchases on any cloud, use 1-year terms. After 12 months, you'll have clear data on workload stability to decide whether a 3-year renewal makes sense.

5. Review Monthly

Track utilization and coverage metrics monthly. Key metrics to watch:

Utilization rate — Percentage of commitment being consumed. Target above 80%.
Coverage rate — Percentage of eligible on-demand spend covered by commitments. Target 60-80%.
Effective savings rate — Actual realized savings versus on-demand pricing.
Amortized cost per unit — True unit economics when commitment cost is spread evenly.

Common Mistakes to Avoid

I've seen teams make all of these, sometimes repeatedly. Don't be that team.

Committing before right-sizing — Purchasing a 3-year RI on an m5.2xlarge that should be an m5.large locks in waste for 3 years.
Ignoring the use-it-or-lose-it model — Savings Plan commitments are hourly. Unused commitment in any hour doesn't carry over.
Over-committing based on averages — Use your minimum consistent usage, not your average. Averages include spikes that inflate the baseline.
Forgetting about capacity reservations — Savings Plans don't guarantee instance availability. If you need capacity guarantees during peak events, pair them with On-Demand Capacity Reservations.
Single large commitment — One massive Savings Plan is harder to manage than multiple smaller, layered commitments.
Not tracking expiration dates — Set calendar reminders 60 days before expiration to analyze whether to renew, adjust, or let expire. Seriously, put it in your calendar right now.

Discount Application Priority Order

Understanding how discounts stack and the order of application is critical for accurate cost modeling. Each provider handles this a bit differently:

AWS

Free Tier (if applicable)
Reserved Instances (matched to specific instance configurations)
EC2 Instance Savings Plans (applied to highest-savings-percentage usage first)
Compute Savings Plans (broadest flexibility, applied last)
Spot pricing (separate pricing model)
On-Demand (everything else)

Azure

Hybrid Benefit (license discount applied first)
Reserved Instances (matched by scope: resource group, subscription, or shared)
Savings Plans for Compute (applied to remaining eligible usage)
On-Demand

GCP

Free Tier (if applicable)
Resource-based CUDs (matched by region and machine family)
Spend-based CUDs (applied to eligible service usage)
Sustained Use Discounts (automatic, applied to remaining eligible usage)
On-Demand

Frequently Asked Questions

Can I cancel a Savings Plan or Reserved Instance after purchasing?

It depends on the provider. On AWS, Savings Plans are generally non-cancellable — the only exception is plans with an hourly commitment of $100 or less, which can be returned within 7 days if purchased in the same calendar month. Azure offers more flexibility: Reservations can be exchanged for different configurations or refunded (subject to a $50,000 rolling 12-month refund limit). You can also trade Azure Reservations into Savings Plans. GCP Committed Use Discounts are non-cancellable and non-refundable — if you need to modify a CUD due to infrastructure changes, contact your Technical Account Manager.

Should I choose Savings Plans or Reserved Instances on AWS?

For most teams in 2026, Compute Savings Plans should be the default for EC2 and serverless workloads because they provide similar discounts with far greater flexibility. Use Reserved Instances for databases (RDS, ElastiCache, Redshift) where configurations are stable, and for scenarios where you need capacity reservations. A blended strategy combining both typically delivers the best results.

How do commitment discounts work in a multi-account AWS organization?

By default, Savings Plans and Reserved Instances are shared across all accounts in a Consolidated Billing Family. Discounts are applied first to the purchasing account, then to other accounts. With the newer RISP Group Sharing feature (GA since late 2025), you can create groups using Cost Categories to control exactly which accounts benefit from specific commitments — either with prioritized sharing (overflow to other groups) or restricted sharing (strict isolation).

Do Savings Plans work with Spot Instances?

Nope. Savings Plans don't apply to Spot Instance usage. Spot Instances have their own pricing model with discounts up to 90% off on-demand. Use Savings Plans for your stable, always-on baseline workloads, and Spot Instances for fault-tolerant batch processing, CI/CD runners, and stateless services that can handle interruptions.

What happens if my workload decreases after purchasing a commitment?

Commitment discounts are use-it-or-lose-it. On AWS, you pay the committed hourly rate whether you use it or not. On Azure, Reserved Instances continue billing for the full term (though you can exchange or refund with limits). On GCP, CUDs are billed for the full term regardless of actual usage.

This is exactly why the 80% rule matters so much — commit only to 80% of your minimum consistent usage to leave room for downward fluctuations. And when in doubt, start with shorter 1-year terms until you have confidence in workload stability.