Cost Optimization
Intermediate 15 min read Cost Optimization

Commitments & Reserved Pricing

Pay for stable demand once, cheaply

The biggest lever on steady workloads: Reserved Instances, Savings Plans, Committed Use Discounts — pay less for agreeing to steady use. Know the models, size commitments on baselines (not spikes), manage coverage/renewal, and handle migration risk with convertible/elastic options.

reserved instanceSavings PlanCUDcommitmenton-demandcoveragerenewal
Prerequisites: Cost Fundamentals & Billing
Before we start

What you will learn

  • Differentiate RI vs Savings Plan vs CUD
  • Size commitments on baseline vs. peak
  • Manage coverage, rollover, and migration risk
In 60 seconds

Commitments discount steady usage: AWS RIs (per instance family/region; Standard 1-3y flexible convertible), Savings Plans (commit $/hr; EC2, Compute or SageMaker plans, flexible across family/region), GCP CUD (per family/region 1-3y), Azure Reserved Instances + Savings Plan. Each cuts cost ~40-70% vs on-demand — but only for usage you actually keep stable.

Introduction

What is this?

Models: AWS RI Standard (locked family/region, big discount, no auto-scaling swap), Convertible (shiftable, slightly less), Savings Plan EC2 Instance (family-locked) vs Compute (any family/region/container), SageMaker; Azure RI (1/3y per VM size family) + Savings Plan; GCP committed-use (per family/region, RM vCPU/mem) + newer elastic/spread. Sizing: on 90-day baseline (the floor of normal), NOT the peak; buy coverage ~70-90% of steady, leave peaks on-demand/spot. Payment: all-upfront (max discount) vs partial/none (lower). Renewal management: RIs/plans auto-renews or expires — expired coverage is a bill spike waiting. Migration risk: Standard RI on a family you migrate away from = wasted; pick Compute SP for flexibility. Unused commitment (paying for idle) — the classic sign of oversizing. Tools: Cost Explorer RI utilization/coverage views, SP recommendations, savings plans AI/copilot for renewal, Azure advisor, committed-use dashboards in GCP.

Motivation

Why do you need it?

  • The #1 line-item saver: stable fleets drop 40-70% overnight via commitments.
  • It converts variable compute into a funded budget floor — finance loves deterministic.
  • Flexible plans (Compute SP/CUD elastic) de-risk migrations and autoscaling trims.
  • Coverage dashboards catch the 'renewal lapsed → bill jumped' footgun before it lands.
Think about it

Mental model

Imagine

A gym membership vs. pay-per-visit

Think of

Savings Plans vs on-demand

If you visit the gym 4× a week, the annual pass is a discount. If you visited once and bought the pass, you waste money. Commitments are passes sized to the workout habit you actually keep.

Mechanics

How it works

  • Analyze the 90-day steady baseline per family/region.
  • Choose model + term (1/3y) + payment + flexibility level.
  • Purchase coverage for the stable floor (not the peak).
  • Monitor utilization + coverage dashboards; renew before expiry.
  • Convert/migrate flexibility for family shuffles (Compute SP/elastic).

Save with commitments.

Baseline usage
Model choice
Coverage sizing
Buy
Manage
Hands-on

Examples

Coverage sizing

Coverage sizing
# Baseline: 30 m5.large steady (24×7 utilization history)
#  → buy Compute Savings Plan covering 26 instances (87%)
#  → 4 on-demand for the autoscale peak + spot for spiky jobs
# Cost: SP discount ~47% on covered hours; overall save ~38%.
# Risk: migration away from m5 → Compute SP keeps covering r6g (elastic).

Optimize the steady floor; float the tail. Flexible plans de-risk the migration that 'Standard RI' would have punished.

Real world

In production

  • Compute Savings Plan for all containerized/EC2 workers (family-agnostic migration-safe).
  • RDS Standard RIs for every prod database (steady by nature).
  • GCP CUD on core Skillets + elastic CUD for the rest via the newer pricing model.
Guidelines

Best practices

  • Size from the 90-day floor — commitment is a promising bet on stability, not a wish on peaks.
  • Buy flexibility (Compute SP/elastic CUD) unless you're 100% on a static family.
  • Set renewal monitoring; auto-renew with a Cost Management alert at 90% term.
  • Reassess coverage quarterly as the floor moves.
  • Benchmark: coverage % and utilization % on a dashboard for the finance review.
Watch out

Common mistakes

  • Buying on a peak → over-commitment paying for idle hours.
  • Standard RI on a family you're migrating from → locked waste (the flexibility lesson).
  • Ignoring renewal: expired coverage spikes the bill with no code change.
  • Committing on workloads about to be re-architected (k8s moves, lift-shifts promised but slack).
When things break

Debugging tips

  • Bill up despite no traffic change → check commitment expiry/renewal log; often the whole spike.
  • High RI utilization but low coverage → you bought family-locked on the wrong family; convert or reinterpret.
  • Unused 'savings' phantom → SP utilisation dashboard distinguishes covered vs wasted; split accordingly.
  • Migration while committed → convert Standard→Convertible (fees aside) or reattribute Compute SP.
Interviews

Interview checkpoint

Practice

Hands-on lab

Size a Commitment From a Fake Baseline
30 min · intermediate
In progress
Objectives
  • Generate a synthetic 90-day usage baseline
  • Pick the coverage vs on-demand/spot mix
  • Present the saving + risk

Size a Commitment From a Fake Baseline

30 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

You should size commitments on:

2

The RI model that protects you during a family migration:

Go deeper

Official documentation

AWS Savings Plans
docs
Azure reserved instances
docs
GCP committed use discounts
docs