Summary

  • A future RDS Capacity Reservation in the scheduled state has been accepted by AWS, carries no charges yet, and cannot be canceled. Once active, it remains subject to its commitment period. Immediate-use reservations have different exit rules.
  • Future bookings start at 14 days and 32 vCPUs per Availability Zone, with a 12-week minimum for the X family. In a two-zone example using two-vCPU db.r7g.large units, that means 32 reserved database capacity slots before a buyer adds any larger footprint.

The project meeting can move. The booking has another clock.

A launch date is easy to change in a planning document. Reserved database capacity has its own calendar, and the two can separate before the first charge appears. AWS's 21 October announcement introduced On-Demand Capacity Reservations for Aurora and RDS across its commercial Regions. Customers can hold matching compute capacity for events such as migrations, launches and seasonal peaks.

For a business with a fixed opening date, a place in the capacity queue has value. The important buying moment arrives when AWS accepts a future reservation. Its state table calls that state scheduled: the future request is accepted and no charges apply yet. Its cancellation rules close the exit at the same stage.

That makes a zero current charge a poor signal of how much freedom the buyer still has. The organisation has crossed a purchasing boundary while its usage and billing remain in the future. A project manager can revise a launch date; the capacity owner must still answer for the booked one.

A future booking comes with a floor

AWS separates immediate-use reservations, which have no commitment and can be canceled as needed, from future-dated ones. The latter can be requested five to 120 days ahead and carry a minimum 14-day commitment. The X instance family has a 12-week minimum. Future bookings also require at least 32 vCPUs in each selected Availability Zone.

The footprint can be larger than a casual request for “some room for the migration” suggests. The guide gives db.r7g.large as a two-vCPU unit. In a constructed two-zone example at the future-booking minimum, each zone needs 16 units. Across the two zones, the buyer reserves 32 database capacity slots for a minimum 14 days. This constructed footprint counts reserved compute units across two zones, including the places needed by a Multi-AZ standby.

A project that needs a short event must therefore decide whether the longer protected period earns its keep. Reserving two zones also buys two zones' footprint. The commitment belongs in the event's budget when the date is approved, even if the billing dashboard is still quiet.

Three different ways the exit can look

While AWS is assessing a future request, the buyer can cancel it. Once it is scheduled, the request stays in place until its start date; after it becomes active, cancellation has to wait until the commitment ends. The cancellation guide separately allows immediate cancellation in the delayed state when AWS could not deliver the booked capacity on time. That exception follows the supplier's delivery state; a rescheduled customer campaign alone leaves that state unchanged.

The distinction matters to the person signing the purchase. The project date and the service's reservation state answer different questions. A business cancellation needs to be priced against the actual reservation and its commitment end, rather than against the absence of a running database.

Stopping the database leaves the place booked

AWS's billing guide charges active unused reserved capacity at the equivalent On-Demand rate. When a matching instance occupies a reserved unit, the customer pays for the instance and that unit has no separate reservation charge. Stop the instance, and its capacity becomes unused reservation; the reservation cost continues.

Billing starts when capacity is provisioned in the account. Canceling an eligible reservation, or reaching its end date, stops those reservation charges. Storage, I/O and other database resources have their usual separate billing. Discounts can apply through the relevant Reserved DB Instance or Database Savings Plan arrangement.

So an instruction to stop a database can finish an operational task while leaving the booked place intact. The decision that releases that place is a separate one, governed by the reservation's state and commitment.

Buying capacity also means using the right door

The placement instructions require an explicit reservation name or identifier. Engine, instance class, applicable licence model and Availability Zone must match, and capacity must be available. Multi-AZ placement needs room in both the primary and standby zones. An approved budget does its useful work when the deployment actually targets what was bought.

When cancellation becomes available, releasing a reservation has an operating consequence too. The cancellation API leaves an existing database running and unmodified, while releasing its reserved capacity. A later hardware move can encounter insufficient capacity without that protection. The owner must put a value on keeping the place for the next move as well as for the current event.

Customer reservation histories and charges are unavailable; they would establish the actual cost of unused commitments. The published decision is already concrete. AWS offers advance control over matching capacity, and the buyer accepts a period during which its own business timetable can change faster than its exit rights. Approval belongs before the booking reaches scheduled. By the time the meter starts, part of the purchase is already settled.

Sources