Cloud Compute Pricing Primitives
Every major cloud provider offers a spectrum of pricing instruments that trade off flexibility, discount depth, and capacity assurance. Understanding which primitive solves which problem is the foundation of cloud cost optimization.
Key insight
Discount instruments and capacity instruments solve different problems. A Savings Plan does not guarantee you can launch instances. A capacity reservation does not give you a discount by itself. Confusing these is the most common FinOps mistake.
The discount-vs-capacity matrix
| Primitive | Gives discount? | Guarantees capacity? | Flexibility | Primary risk |
|---|---|---|---|---|
| On-Demand | No | No | Highest | Expensive baseline |
| Savings Plan (AWS) / CUD (GCP) | Yes | No | High–Medium | Overcommit if usage falls |
| Reserved Instance (AWS) — Regional | Yes | No | Medium | Commitment mismatch |
| Reserved Instance (AWS) — Zonal | Yes | Yes (one AZ) | Low | Inflexible |
| ODCR (AWS) / Reservation (GCP) / Capacity Reservation (Azure) | Not by itself | Yes (one zone) | Medium | Paying for unused capacity |
| Spot (AWS) / Preemptible (GCP) / Spot (Azure) | Yes | No | High if diversified | Interruptions |
| Capacity Blocks (AWS) | Scheduled | Yes (future window) | Low | Paying for planned block |
On-Demand
Pay by the second/hour, no commitment. Maximum flexibility, no discount, no capacity guarantee. If the provider has no capacity in your zone, you get “Insufficient capacity” errors.
Use for: bursty workloads, new services without usage history, temporary migrations, capacity above committed baseline.
Savings Plans (AWS) and Committed Use Discounts (GCP)
Financial commitments — you promise to spend a certain dollar amount per hour (AWS) or commit to resource quantities (GCP) for 1–3 years. The provider applies discounts automatically to matching usage.
AWS variants
| Type | Scope | Discount |
|---|---|---|
| Compute Savings Plan | EC2 across families, sizes, AZs, Regions + Lambda + Fargate | Up to ~66% |
| EC2 Instance Savings Plan | Specific instance family in one Region | Up to ~72% |
AWS applies Instance Savings Plans first (narrower scope, deeper discount), then Compute Savings Plans to remaining eligible usage.
GCP variants
| Type | Scope | Discount |
|---|---|---|
| Spend-based CUD | Dollar commitment across compute | ~25% |
| Resource-based CUD | Specific vCPU/memory quantities in a Region | Up to ~57% (3yr) |
Azure
Azure Reserved VM Instances function similarly to AWS Regional RIs — commit to a VM size family in a region for 1–3 years.
Decision rule: If the problem is price, use commitment discounts. If the problem is “can I launch at all,” commitments alone are not enough.
Reserved Instances (AWS — legacy)
Older AWS discount instrument with two variants:
- Regional RI — discounted billing for matching usage in a region. No capacity guarantee. Flexible across AZs and sizes within the family.
- Zonal RI — tied to a specific AZ and instance type. Reserves capacity and gives a discount. Less flexible than Savings Plans.
For most EC2 discount use cases, Savings Plans are operationally simpler. Zonal RIs still matter when you need both discount and capacity guarantee in a single instrument.
On-Demand Capacity Reservations (detailed in Cloud Capacity Reservations)
Capacity assurance without a built-in discount. You pay on-demand rate whether instances run or not. Savings Plans / RIs can layer on top to cover the cost.
Spot / Preemptible / Spot VMs
Spare provider capacity at steep discounts (60–90%), but the provider can reclaim it with short notice (2 minutes on AWS, 30 seconds on GCP).
Good candidates: batch jobs, stateless workers, retryable compute, CI/CD, Spark with checkpointing, non-critical async processing.
Bad candidates: single-instance databases, stateful services without graceful shutdown, strict-latency services without fallback.
Best practice: diversify across instance types and AZs to reduce simultaneous interruption risk.
Capacity Blocks (AWS)
Future-dated reservations for scarce accelerator instances (p5, trn1, trn2). You see available GPU capacity windows and schedule a reservation for a specific duration. Useful for large ML training jobs that need guaranteed GPU access at a known future time.
How primitives compose
In practice, organizations layer instruments:
Capacity guarantee: ODCR ensures instances are launchable
+
Rate reduction: Savings Plan covers the ODCR's on-demand cost
+
Utilization: Workloads scheduled to fill the reserved capacity
The layering means different teams may own different layers:
- Capacity engineering owns ODCRs
- Finance/procurement owns Savings Plans
- Service owners own utilization