Summary

  • AWS Savings Plans exchange a one- or three-year hourly monetary commitment for lower prices on eligible compute usage. AWS explicitly says they do not provide capacity reservations and cannot be cancelled during the term.
  • An EC2 On-Demand Capacity Reservation holds matched capacity in a specified Availability Zone. It is charged at the equivalent On-Demand rate whether a matching instance occupies it or the slot remains idle.
  • The two products can be layered: a Savings Plan or regional Reserved Instance discount may apply to a Capacity Reservation. That buys price and placement separately; it still does not buy application health, data recovery or cross-zone continuity.
  • Utilisation, coverage, reservation occupancy, launch success and service availability are five different receipts. A high value in one cannot certify the other four.

The first contract buys a price

AWS describes Savings Plans as a commitment to a consistent amount of compute usage per hour for one or three years. The buyer chooses an hourly monetary commitment and one of three payment patterns: all upfront, partial upfront or no upfront. In return, eligible use receives a lower rate through the term.

That is a financial shape, not a machine booking.

A Compute Savings Plan is deliberately broad. It can apply across EC2 instance families, sizes, operating systems, tenancy and Regions, and also to eligible Fargate and Lambda use. An EC2 Instance Savings Plan narrows the commitment to an instance family in a Region and can offer a deeper maximum discount. AWS advertises up to 66% off On-Demand for the broader product and up to 72% for the narrower one. “Up to” is a product ceiling, not the saving every buyer will realise.

The commitment persists even when the workload changes. AWS states that Savings Plans cannot be cancelled during the term. A no-upfront label changes the payment schedule; it does not create an exit right. If eligible usage falls below the hourly commitment, the unused portion does not become a store of capacity waiting for a later launch.

The useful economic receipt is utilisation. AWS defines it as the percentage of the Savings Plans commitment consumed by eligible On-Demand usage. Its own utilisation example treats US$9.80 of Savings Plans-rate usage against a US$10 hourly commitment as 98% utilisation. That proves almost all of a pricing commitment found eligible usage in that hour. It says nothing about whether a particular instance could launch in a congested zone.

The second contract holds a place

An EC2 On-Demand Capacity Reservation addresses a different problem. It holds capacity for specified instance attributes in one Availability Zone. The right is bounded by instance type, platform, zone and tenancy. Active unused reservations also count toward the account's On-Demand Instance limits.

The billing rule exposes the difference. AWS charges the equivalent On-Demand rate while the reservation is provisioned, whether matching instances occupy it or not. If twenty matching slots are held and fifteen instances run, the customer pays for fifteen running instances and five unused reserved slots. There is no second charge on top of an occupied slot, but idleness remains billable.

Capacity is therefore an option whose cost becomes visible when it is not exercised. For an event, recovery environment or tightly constrained instance type, paying for a quiet slot may be rational. The error is calling the idle charge waste without asking what failure the buyer paid to avoid. The opposite error is calling every reservation prudent without measuring how often the protected launch path mattered.

The right can be paired with the price contract. AWS says applicable Savings Plans and regional Reserved Instance discounts can reduce the bill for Capacity Reservations. This is the cleanest proof that the products are not substitutes in name only. One layer controls the rate. Another layer controls access to matched capacity. The customer may need both.

A running workload is a third state

Reserved capacity is not automatically consumed. AWS's launch rules require the instance type, platform, Availability Zone and tenancy to match; the reservation must be active and have an available count.

An open reservation can accept matching launches. If no suitable open reservation exists, an ordinary launch may use On-Demand capacity. A targeted launch behaves differently: if the selected reservation lacks a matching available slot, the launch can fail. A configuration can therefore own the right economic products and still miss the intended capacity because its launch settings point at the wrong zone, platform, tenancy or reservation target.

Even an occupied reservation certifies only that an instance is running against the reserved count. It does not certify that the application passed health checks, that its dependencies are reachable, that data is current or that another zone can assume service. The purchasing layer cannot replace deployment and recovery evidence.

The converse is also important. A workload with a Savings Plan discount may launch normally for months and then encounter an InsufficientInstanceCapacity error when AWS lacks enough available ordinary capacity for a new request. AWS documents that launch condition. The discount was applied correctly; it was never a promise that every later configuration would have a place.

Reserved Instances reveal the naming problem

The phrase Reserved Instance sounds like a single contract, yet AWS gives regional and zonal RIs different capacity effects.

A regional RI supplies a billing discount across Availability Zones in the selected Region and may provide instance-size flexibility. It does not reserve capacity. A zonal RI reserves capacity in one Availability Zone but gives up zone flexibility and, for the relevant scope, size flexibility. AWS says the scope does not change the RI price.

The name alone therefore cannot answer the operating question. The receipt must include scope. A regional “reservation” can be only a price benefit. A zonal one can carry a capacity right. Neither identifies physical hardware owned by the customer.

This matters for procurement comparison. A team that compares Savings Plans, RIs and Capacity Reservations only by discount percentage mixes three dimensions: the duration of monetary commitment, the flexibility of eligible use and the specificity of the capacity claim. The cheapest rate can be the wrong product when launch continuity matters. The strongest capacity claim can be an expensive idle position when the workload can move freely.

How the discount moves

Savings Plans are not labelled envelopes attached permanently to the application that inspired the purchase. AWS applies billing benefits automatically.

Reserved Instance discounts are applied first. EC2 Instance Savings Plans precede broader Compute Savings Plans. Within eligible use, AWS applies the commitment to the usage producing the highest savings percentage, and continues until the hourly commitment is exhausted. Remaining eligible use is billed at On-Demand rates. In a consolidated billing family, the owner's usage is considered first and other accounts can receive benefits when sharing is enabled.

This creates a governance consequence. A platform team may buy a plan because one service has a stable baseline, while the realized discount migrates across other eligible services or accounts. The organisation can achieve high aggregate utilisation while the original workload shrinks. That is successful portfolio consumption, but it is not proof that the original business case survived unchanged.

Coverage measures the other side. AWS's coverage report shows the share of applicable usage cost covered by Savings Plans. High utilisation with low coverage means the commitment is fully consumed but much eligible use still pays On-Demand. High coverage with weak utilisation can emerge only through a differently shaped usage base and time window; the two percentages must be read from their defined denominators rather than treated as one efficiency score.

Sources