Unused EC2 On-Demand Capacity Reservation cost is the bill for capacity you asked AWS to hold and then did not run. An On-Demand Capacity Reservation keeps instances available in one Availability Zone. AWS bills that reservation at the equivalent On-Demand rate whether or not an instance is sitting in it. When a matching instance is running, you pay for the instance and nothing extra for the reservation. When the slots are empty, the empty slots are the charge. The line looks like compute. It is idle assurance.
Rutagon finds these in accounts that reserved capacity for a launch, a migration, or a failover drill, and left the reservation in place after the event. The instance count went back down. The reservation did not. Finance sees On-Demand spend that does not match the running fleet. The idle resource cleanup habit covers volumes and addresses. Capacity reservations are the same class of leak, with a sharper rate: the full On-Demand price of the instance type, for every unused slot, for as long as the reservation stays provisioned.
How unused EC2 On-Demand Capacity Reservation cost is billed
The capacity reservation billing page states the unit directly. Capacity Reservations are charged at the equivalent On-Demand rate whether you run instances in reserved capacity or not. If you do not use the reservation, it shows up as unused reservation on the EC2 bill. There is no separate cheaper "held but empty" price. A reservation for twenty of a type, with fifteen running and matched, is fifteen instance charges plus five unused charges at that type's On-Demand rate. The page's worked example uses an assumed rate only to show the split: an unused hour bills the reservation, and an occupied hour bills the instance instead. We do not treat that assumed rate as your price. Your price is the On-Demand rate of the instance type, operating system, and tenancy in that Region, including any regional surcharge the page notes for Dedicated Instances.
Billing starts when the reservation is provisioned in the account, not when you create a request for a future date. A future-dated reservation starts billing when it is actually provisioned on the date you asked for. Billing continues while it remains provisioned. The granularity is per second, with a minimum of 60 seconds. A reservation that lives for a day and a fraction is billed for that fraction. Canceling it is what stops the meter. Hoping the instances will "use it next week" does not.
The Cost and Usage Report distinguishes the rows. An active reservation shows reserved capacity, used capacity as instance usage, and idle capacity as unused. The usage type for that idle capacity is UnusedBox. Used instances appear as BoxUsage. If you only graph running instances, the unused reservation is invisible and the bill still has it. We query UnusedBox before we tell anyone the fleet is efficient.
charge: equivalent On-Demand rate for the instance type
empty_slot: UnusedBox, billed while the reservation stays provisioned
matched_instance: BoxUsage on the instance, nothing extra for the reservation
minimum: 60 seconds, then per-second
stop: cancel the reservation, not the instances you already shut down
Savings Plans and Regional Reserved Instances can discount a Capacity Reservation, and the discount prefers real instance usage before it covers unused reservations. A zonal Reserved Instance does not apply to the Capacity Reservation. Buying a Savings Plan does not make an abandoned reservation free. It may discount it after the running fleet has taken the discount first. We read the unused line after discounts, and we still cancel the reservation that has no owner. A discount on waste is still waste.
Why the reservation outlives the instances
The attributes have to match or the instance does not land in the reservation. Instance type, Availability Zone, platform, and tenancy are the usual reasons a fleet runs "beside" capacity you are paying to hold. People launch a newer generation, or they spread across zones, and the reservation keeps the old shape. Both bills run: On-Demand for the new instances, and the On-Demand rate again for the empty reservation. That double spend is the pattern we flag first.
A launch template that does not target the reservation will not fill it. Capacity Reservations can be opened so that matching instances land automatically, or they can be targeted. An open reservation that nothing matches is the expensive one. A targeted reservation that the template never names is the same expense. We compare the reservation's attributes to the launch template in the same account and zone. A mismatch is a finding even when the reservation was created for a good reason.
Event capacity is the honest use. A sale, a migration window, or a failover test needs instances to exist when you ask. The reservation should have an end. We put the cancel in the same change that creates it, or we put an owner and a date on the record. A reservation with no owner survives the person who created it. Multi-account organizations multiply that. Each account can hold its own unused reservation for the same instance type "just in case," and each one bills the On-Demand rate.
Interruptible Capacity Reservations are a different product: unused capacity can be offered to other workloads and reclaimed. They are not an excuse to keep a normal On-Demand Capacity Reservation forever. If you need the hard guarantee, keep it and name the workload. If you do not, cancel it. Capacity Blocks for machine learning are also a different purchase, with a defined window. Do not mix those charges into this unused On-Demand line when you explain the bill.
What the cleanup does
We list every On-Demand Capacity Reservation, the instance type, the zone, the total count, the used count, and the unused count. The dollar exposure is unused count times the On-Demand rate for that type, for the hours it has been provisioned. We pull the rate from the price list for the Region rather than from memory. The billing doc gives the unit. The price list gives the number for that type. A table of unused counts without the rate is how a twenty-slot reservation hides behind a small instance type, or a two-slot reservation on a large type gets ignored.
Cancel is the fix when nothing will launch into the reservation. Modify is the fix when the fleet moved to a new type or zone and you still need the guarantee: cancel the old shape, create the shape the template actually launches, and keep the count near the peak you measured. Leaving both is the double bill.
We do not cancel a reservation that a runbook names as the failover capacity unless the owner agrees the runbook is dead. The finding is still written down. An unused reservation that is a deliberate standby is a finance decision. An unused reservation nobody can explain is a leak. The difference is the owner, not the usage chart.
Savings Plans versus Reserved Instances is the commitment conversation. A Capacity Reservation is not a commitment discount. It is a capacity hold at On-Demand. Teams buy it because a Savings Plan does not promise the zone has the instances. That is a real reason. It is not a reason to keep the hold after the launch window. AWS cloud infrastructure is where we put the reservation in code, with the count and the cancel path, so the console click is not the system of record.
Rutagon's cost pass returns the unused rows, the On-Demand unit, and the order to cancel or resize. We do not quote a universal hourly price. The type and the Region set the rate. The waste pattern is the empty slot billed as if it were running.
Frequently Asked Questions
Do I pay twice when an instance runs inside the reservation?
No. The billing page says that when an instance matches the reservation, you pay for the instance and nothing for the reservation. The unused cost is the slots with no matching instance. A partial fill is the usual case: some slots as instances, the rest as unused reservation at the same On-Demand rate.
Does shutting down the instance stop the reservation charge?
Shutting down the instance empties the slot. The reservation keeps billing at the On-Demand rate until you cancel it or something matching launches into it. People stop the fleet after a test and leave the reservation. That is the bill we are describing.
Will a Savings Plan wipe out the unused line?
Savings Plans and Regional Reserved Instances can discount Capacity Reservations, and discounts apply to instance usage before unused reservations. A zonal Reserved Instance does not apply. You can still be paying a discounted On-Demand rate for capacity with no owner. The cleanup is to cancel the reservation, not to buy another discount.
What should I look for in the cost report?
Idle capacity on an active reservation uses the UnusedBox usage type. Running instances in the reservation show up as instance usage. If your dashboard only counts running instances, add the unused usage type or you will certify a fleet that is smaller than the bill.
Are future-dated reservations billed from the day I request them?
Billing starts when the reservation is provisioned. For a future-dated reservation, that is the requested date, not the day you submitted the request, and the meter runs whether or not you launched. Canceling a future-dated reservation can carry a cancellation charge, so read that row before you treat cancel as free.
Ask for an AWS cost diagnostic that lists unused capacity reservations at the On-Demand rate. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.