EC2 Capacity Reservations: unused cost (2026)

A Capacity Reservation bills whether you use it or not, at full On-Demand rate, from the moment it exists. The unused half arrives in your bill under a usage type most people have never grepped for, and it looks exactly like instance spend.

What does an EC2 Capacity Reservation cost?

The same as running the instances, used or not. From the Capacity Reservation pricing and billing documentation:

Capacity Reservations are charged at the equivalent On-Demand rate whether you run instances in reserved capacity or not, including any applicable regional surcharge for Dedicated Instances. If you do not use the reservation, this shows up as unused reservation on your Amazon EC2 bill. When you run an instance that matches the attributes of a reservation, you just pay for the instance and nothing for the reservation. There are no upfront or additional charges.

AWS's own example: "if you create a Capacity Reservation for 20 m4.large Linux instances and run 15 m4.large Linux instances in the same Availability Zone, you will be charged for 15 active instances and for 5 unused instances in the reservation."

So a reservation is not a discount instrument. It is a guarantee of capacity, priced at list, and the only thing it protects you from is an insufficient capacity error. That distinction matters because Capacity Reservations sit in the same console area as Reserved Instances and Savings Plans, which are discount instruments, and the naming invites the wrong mental model. The Capacity Reservations overview is explicit that what you buy is capacity assurance, and Capacity Blocks for ML is a separate instrument with its own billing rules.

When does billing start?

On provisioning, not on use. "Billing starts as soon as the Capacity Reservation is provisioned in your account, and it continues while the Capacity Reservation remains provisioned in your account. For future-dated Capacity Reservations, this means that billing starts only after the Capacity Reservation is provisioned in your account at the requested future date."

Granularity is finer than hourly: "Capacity Reservations are billed at per-second granularity. This means that you are charged for partial hours. For example, if a Capacity Reservation remains provisioned in your account for 24 hours and 15 minutes, you are billed for 24.25 reservation hours."

The practical consequence is that a reservation created for a launch window and never cancelled is a permanent charge with no running instance attached to it, and nothing in the EC2 console dashboard surfaces it as waste. It is the exact shape of an idle NAT Gateway or an unattached Elastic IP, at a much larger unit price.

Do Savings Plans cover unused reserved capacity?

Partly, and the ordering is the interesting part. "Billing discounts for Savings Plans and Regional Reserved Instances apply to Capacity Reservations. AWS automatically applies these discounts to Capacity Reservations that have matching attributes. When a Capacity Reservation is used by an instance, the discount is applied to the instance. Discounts are preferentially applied to instance usage before covering unused Capacity Reservations."

Read that as a queue. Your commitment covers real instance usage first, and only leftover commitment reaches unused reservations. So an account with tight Savings Plans coverage pays close to full On-Demand for idle reserved capacity, which is the worst case of both instruments at once. Whether you are in that position is a question about coverage and utilization, not about the reservation.

One exclusion to note: "Billing discounts for zonal Reserved Instances do not apply to Capacity Reservations." Zonal RIs already carry a capacity reservation of their own, so pairing them with a Capacity Reservation buys the same guarantee twice and gets no discount on the second one.

Who pays when a reservation is shared?

The owner, unless they hand it over. Per the billing assignment documentation, "when a Capacity Reservation is shared, the owner is billed for the instances they run in the Capacity Reservation and for any available capacity, also called unused capacity, in the Capacity Reservation; while consumers are billed only for the instances they run in the shared Capacity Reservation."

That default is the source of a recurring chargeback argument: a platform team reserves capacity for the organisation and absorbs 100% of the idle cost while application teams pay only for what they launch. AWS provides an explicit transfer for exactly this, letting the owner "assign the billing of any available capacity in the Capacity Reservation to any one of the accounts with which the Capacity Reservation is shared."

With a boundary worth knowing before you use it: "The Capacity Reservation owner remains the resource owner and they remain responsible for managing the Capacity Reservation. The account to which billing is assigned does not get any additional privileges; they can't cancel, modify, or share the Capacity Reservation in any way." So you can move the bill without moving the ability to stop it, which is a governance trap rather than a solution if the two accounts do not talk.

How do you find unused reservation cost in the CUR?

By usage type, and the string is UnusedBox. AWS publishes the mapping between reservation state and CUR 2.0 values, which is the piece that makes this findable at all:

UnusedBox is the whole story in one string. It is money spent on capacity nobody launched into, and it is the first thing to query on any account that uses reservations:

SELECT line_item_usage_type,
       line_item_usage_account_id,
       product_instance_type,
       SUM(line_item_unblended_cost) AS cost
FROM   cur
WHERE  billing_period = '2026-07'
  AND  line_item_usage_type LIKE '%UnusedBox%'
GROUP  BY 1, 2, 3
ORDER  BY cost DESC;

The three capacity reservation columns are a table configuration rather than a default. The CUR 2.0 table dictionary describes INCLUDE_CAPACITY_RESERVATION_DATA as adding resource-level granularity "when an instance usage is split across multiple capacity reservations or used partially in a capacity reservation in an hour", and carries an important caveat: "This configuration only adds data in the new columns starting November 1, 2025." Enabling it does not backfill, so turn it on before you need the history, the same trap as the IAM principal columns for Bedrock.

What happens if you cancel one?

For a standard reservation, billing stops when it is no longer provisioned. For a future-dated reservation there can be a cancellation charge, and it arrives disguised as unused capacity:

Note that a cancellation charge and idle capacity share the same usage type and are distinguished only by the status column. A query that groups on usage type alone will report a cancellation fee as ongoing waste and send somebody hunting for a reservation that no longer exists. Include capacity_reservation_capacity_reservation_status in the group-by if you cancel future-dated reservations at all.

This is the same class of problem as reading the wrong cost column: the data is complete and correct, and a reasonable-looking query over it returns a confidently wrong answer.