FinOps & Cloud Cost Optimization

Commitment Discounts

18 min Lesson 5 of 26

Commitment Discounts

On-demand pricing is the cloud's retail price — it is what you pay when you walk in without a reservation. Every major cloud provider offers a parallel purchasing system that exchanges schedule flexibility for dramatically lower rates: AWS Savings Plans and Reserved Instances, GCP Committed Use Discounts (CUDs), and Azure Reserved VM Instances and Savings Plans. At scale these are not optional features; they are the single highest-leverage lever in FinOps. A mature programme running 70–80% coverage can reduce compute spend by 30–45% with zero architectural change. The discipline is in the strategy: knowing when to commit, how much to commit, and how to layer the instruments correctly.

The Three Instruments

Reserved Instances (RIs) are the original commitment product. On AWS you purchase capacity for a specific instance family, size, region (or zone), and operating system for 1 or 3 years. Standard RIs offer the deepest discounts — up to 72% off on-demand — but are rigid: you cannot change the instance type family. Convertible RIs allow exchanges at the cost of a shallower discount (around 54–66%). RIs are most appropriate for workloads where the instance type is unlikely to change: database servers, long-lived application servers, and baseline Kubernetes node pools.

Savings Plans (AWS, Azure) decouple the discount from a specific resource. Instead of buying a specific instance, you commit to a dollar-per-hour spend floor. AWS Compute Savings Plans apply automatically to any EC2 instance regardless of family, size, region, OS, or tenancy, and also cover Lambda and Fargate. EC2 Instance Savings Plans are narrower (one family, one region) but discount deeper — approaching RI rates. Because they follow the workload rather than the resource, Savings Plans are the right default for almost everything except databases.

GCP Committed Use Discounts come in two flavours: resource-based CUDs commit vCPU and memory amounts for 1 or 3 years at up to 57% off; flexible CUDs (spend-based, available for certain services) commit a dollar amount per hour similar to AWS Savings Plans. GCP also grants automatic Sustained Use Discounts for any instance that runs more than 25% of a month — no action required — which serves as a safety floor before you layer CUDs on top.

Commitment discount layers: stack from bottom up — RIs for stable workloads, Savings Plans for everything else.

Coverage Strategy: Laddering

A naive approach buys RIs for whatever is running today at full commitment. The correct approach is laddering: spreading commitment terms and sizes across time so that you are never all-in on a prediction more than 12 months into the future.

The ladder model works as follows. Look at your trailing 90-day minimum baseline — the lowest hourly compute spend observed in the period, excluding incident-driven spikes. That floor represents the safest 3-year commitment candidate because the workload has never dropped below it. The next tier — trailing 90-day average minus the floor — is a reasonable 1-year commitment. Anything above the average stays on-demand (or Spot, covered in lesson 6). Each quarter you re-run the analysis and layer in new commitments as workloads stabilise.

The 3-year vs 1-year decision: 3-year terms offer ~10–15 percentage points more discount than 1-year terms, but lock you into the commitment for 36 months. At a cloud-native company where instance families change every 18 months and the architecture evolves rapidly, a portfolio of 1-year terms renewed continuously often has better risk-adjusted returns than 3-year commitments. Reserve 3-year terms for genuinely stable, commodity workloads: RDS databases, Elasticsearch clusters, and baseline node pool capacity. Use 1-year for everything else.

In practice, most AWS teams target 70–80% coverage of their stable baseline with Compute Savings Plans (1-year, no-upfront or partial-upfront), and overlay standard or zonal RIs on top of the highest-utilisation node pools where the instance type has not changed in 18+ months. GCP teams follow a similar pattern: resource CUDs for the proven baseline, flexible CUDs for services like Cloud Run or GKE Autopilot where resource shapes change.

Purchasing in Practice — AWS CLI

Before buying, validate the recommendation with Cost Explorer's programmatic recommendation engine. Always review the UpfrontCost, EstimatedMonthlySavings, and EstimatedROI fields before any commitment.

# 1. Pull AWS Compute Savings Plan recommendation (1-year, partial upfront, 7-day lookback)
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option PARTIAL_UPFRONT \
  --lookback-period-in-days SEVEN_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.{
      EstimatedROI:SavingsPlansPurchaseRecommendationSummary.EstimatedROI,
      MonthlySavings:SavingsPlansPurchaseRecommendationSummary.EstimatedMonthlySavingsAmount,
      HourlyCommitment:SavingsPlansPurchaseRecommendationSummary.HourlyCommitmentToPurchase
    }' \
  --output json

# 2. Check current Savings Plan coverage (last 30 days)
aws ce get-savings-plans-coverage \
  --time-period Start=2025-05-12,End=2025-06-11 \
  --granularity MONTHLY \
  --metrics CoverageHours \
  --query 'SavingsPlansCoverages[*].Coverage' \
  --output table

# 3. Check utilisation of existing Savings Plans (alert if below 90%)
aws ce get-savings-plans-utilization \
  --time-period Start=2025-05-12,End=2025-06-11 \
  --granularity MONTHLY \
  --query 'SavingsPlansUtilizationsByTime[*].Utilization.UtilizationPercentage' \
  --output text

Automate utilisation alerts: Set a CloudWatch alarm or a daily Lambda that calls get-savings-plans-utilization and pages the FinOps channel if utilisation drops below 85%. An underutilised Savings Plan that nobody notices is money thrown away — you are paying the committed rate but not consuming that much compute. This happens after a workload is decommissioned or right-sized mid-term.

Payment Options and Cash Flow

AWS and Azure offer three payment modes for RIs and Savings Plans: All Upfront, Partial Upfront, and No Upfront. All Upfront yields the deepest discount (typically 3–5% more than No Upfront) but ties up working capital. At $1M/year of compute, the all-upfront saving over no-upfront is roughly $30–50k — meaningful, but weigh it against cash flow needs and the company's cost of capital. Most growth-stage companies default to No Upfront or Partial Upfront and accept the slightly shallower discount in exchange for predictable monthly cash flow.

GCP CUDs are always billed monthly over the commitment term — there is no upfront option, simplifying the decision but removing the cash-flow arbitrage.

Handling Architecture Changes Mid-Term

The most common FinOps incident is buying a 3-year RI for an instance type that gets deprecated or replaced by a new generation within 18 months. AWS provides three escape hatches: Convertible RI exchanges (swap to a different instance family at equivalent or greater value), the RI Marketplace (sell unused Standard RIs to other AWS customers), and Savings Plans which simply follow your workload automatically. The GCP equivalent is that resource CUDs are flexible across most instance types within a family; if the workload disappears entirely, GCP offers no secondary market, and you are on the hook for the remaining term.

Never commit beyond your planning horizon. If your 12-month roadmap includes a potential migration from EC2 to Fargate, or from self-managed Kubernetes to GKE Autopilot, do not purchase RIs that cover the workload you plan to retire. Use Compute Savings Plans (which cover Fargate and Lambda automatically) or keep those workloads on-demand until the migration decision is made. A 3-year RI on an instance type you will decommission in 14 months is a liability, not an asset.

Terraform-Managed RI Purchases

At scale, managing hundreds of RIs manually through the console is error-prone. Codify commitments in Terraform so that RI purchases, tagging, and portfolio reviews are version-controlled and auditable.

# terraform/finops/savings_plans.tf
# Compute Savings Plan — 1-year, no upfront, $10/hr commitment baseline
resource "aws_savingsplans_savings_plan" "compute_baseline" {
  savings_plan_type   = "COMPUTE"
  commitment          = "10.00"          # USD per hour
  savings_plan_offer_id = data.aws_savingsplans_savings_plan_offerings.compute_1yr.offerings[0].offering_id
  tags = {
    environment = "production"
    team        = "platform"
    FinOps      = "committed-baseline"
  }
}

data "aws_savingsplans_savings_plan_offerings" "compute_1yr" {
  currency          = "USD"
  payment_option    = "NO_UPFRONT"
  plan_type         = "COMPUTE"
  duration_seconds  = 31536000   # 1 year
}

# RDS Reserved Instance for the primary database cluster (3-year, partial upfront)
resource "aws_db_reserved_instances" "primary_db" {
  reserved_instances_offering_id = data.aws_db_reserved_instances_offerings.mysql_r6g_4xl.id
  instance_count                 = 2
  tags = {
    team   = "data-platform"
    FinOps = "3yr-ri"
  }
}

data "aws_db_reserved_instances_offerings" "mysql_r6g_4xl" {
  db_instance_class       = "db.r6g.4xlarge"
  engine                  = "mysql"
  multi_az                = true
  offering_type           = "Partial Upfront"
  duration                = 94608000   # 3 years
}

The FinOps Review Cadence

Commitment portfolios are not fire-and-forget. A well-run programme runs a monthly FinOps review with three agenda items: coverage rate (target 70–80% of stable baseline), utilisation rate (target above 90%), and upcoming expiry calendar (what RIs expire in the next 90 days and should they be renewed, exchanged, or allowed to lapse). Pair this with quarterly ladder analysis to decide whether new commitments are warranted as workloads mature. Assign a clear DRI (directly responsible individual) — typically a senior platform engineer or a dedicated FinOps analyst — who owns the commitment calendar the way an SRE owns an SLO budget.

Savings Plan vs RI — the practical default: Start with Compute Savings Plans for EC2, Lambda, and Fargate. Add EC2 Instance Savings Plans only when a specific instance family has been stable for 12+ months and you want the deeper discount. Use RIs primarily for RDS, ElastiCache, Redshift, and OpenSearch — services not covered by Savings Plans — where the instance type is genuinely stable over a multi-year horizon.