A team needs certainty that twenty EC2 instances of a specific type will be available in one Availability Zone for a launch next month. Which EC2 purchase mechanism actually holds that capacity, and which ones only change the bill?

## Two independent axes The question that trips people up is always some version of "I bought Reserved Instances, why can't I launch?" The answer is that AWS separates two things that the word *reserved* suggests are one: - **Do I have a claim on physical capacity in an Availability Zone?** - **What rate am I billed at for the instances I do run?** Most commitment products answer only the second question. Exactly one product answers the first as its whole purpose. ## On-Demand Capacity Reservations — the capacity instrument An On-Demand Capacity Reservation (ODCR) reserves a stated number of instances of a stated instance type, platform and tenancy, **in one specific Availability Zone** — never Region-wide, because capacity is a physical, zonal thing. Once created, that capacity is yours until you cancel it. The cost model follows directly from what it is: **you pay the On-Demand rate for the reserved capacity whether or not anything is running in it.** You are renting the space in the rack. This surprises people who expect a reservation to be free until used — but if it were free, everyone would reserve everything. An ODCR has an `InstanceMatchCriteria` setting that decides who consumes it: - `open` — any instance you launch matching the attributes (type, platform, AZ, tenancy) automatically runs in the reservation. - `targeted` — only instances that explicitly reference the reservation ID use it, which is how you stop unrelated workloads from silently eating capacity you set aside for a launch. ## What Savings Plans and Reserved Instances actually do A Savings Plan is a spend commitment: you promise a dollars-per-hour figure for a term, and matching usage bills at a reduced rate. It reserves no capacity anywhere. A **regional** Reserved Instance likewise discounts matching usage across the Region and gives no capacity guarantee — though it does give the flexibility of applying across Availability Zones. The one that behaves differently is the **zonal** Reserved Instance: scoped to a single Availability Zone, it carries a capacity reservation *in addition* to the discount. It is the older way to get both at once, and it is why the blanket statement "RIs don't reserve capacity" is not quite right — regional ones don't; zonal ones do. The two axes compose cleanly. A Capacity Reservation you have created can be covered by a Savings Plan or a matching Reserved Instance, so the hours billed against it get the committed rate rather than the full On-Demand rate. You get the guarantee from one instrument and the discount from the other. ## The failure this prevents The scenario that makes this real: a product launch, a seasonal peak, a regional failover, or a disaster-recovery exercise where you plan to bring up a large block of instances at a specific moment. All of those assume capacity will simply be there. During a large-scale event — an Availability Zone impairment shifting an entire Region's demand, or a popular new instance generation being supply-constrained — an `InsufficientInstanceCapacity` error is exactly what you get, and no amount of committed spend fixes it. If your DR plan depends on launching a hundred instances in the surviving zone, either you have reserved that capacity or you have a plan that has never been tested against the day it matters. ## Choosing, in practice - **Predictable steady-state usage, no launch-timing risk** — take the discount instrument alone and skip the reservation; you are paying only for the flexibility you need. - **A known moment where capacity must exist** — create a `targeted` ODCR ahead of time, sized to the block you must launch, and release it after. - **DR capacity in a second Availability Zone** — a reservation is often the honest cost of the guarantee you are claiming in the runbook, and it is a decision to make explicitly rather than discover during an incident. - **Interruptible, elastic work** — Spot, which promises the opposite of all of this and is priced accordingly. ## Where this often gets misstated Watch three claims. First, "a Savings Plan guarantees capacity" — it does not, in any form. Second, "a Capacity Reservation is free until used" — it is not; that is the whole trade. Third, "reservations are Region-wide" — capacity reservations are zonal by nature, because the servers are in a building, and a promise that ignores which building is not a promise about capacity at all.