I tried out the new Amazon RDS feature "On-Demand Capacity Reservations"
This page has been translated by machine translation. View original
Introduction
On October 21, 2026, On-Demand Capacity Reservations (hereafter, capacity reservations) became available for Amazon Aurora and Amazon RDS.
This feature was announced as a way to reserve compute capacity in units of AZs, preventing DB instance creation, restoration, scaling, and startup from failing due to insufficient capacity. The reserved capacity is referred to as a "slot" in the following sections.
The reservation tested in this article is of type immediately (displayed as "Now" in the console), for 1 instance. The environment is RDS for MySQL 8.4.11, db.t3.micro, in the Tokyo region, single AZ (ap-northeast-1a). A new reservation was created for each verification, with the end date set to either approximately 1 minute or 15 minutes after creation.
Creating a Reservation and Creating a DB Instance by Specifying the ID
Reservations are created with create-db-capacity-reservation. --end-date is specified in UTC. The values in the examples are from actual measurements, so please replace them with a date and time after your execution time.
aws rds create-db-capacity-reservation \
--db-capacity-reservation-name odcr-r1c \
--db-instance-class db.t3.micro \
--engine mysql \
--capacity-per-availability-zone 1 \
--availability-zones ap-northeast-1a \
--end-date 2026-10-22T00:28:20Z
{
"DBCapacityReservation": {
"DBCapacityReservationName": "odcr-r1c",
"DBInstanceClass": "db.t3.micro",
"Engine": "mysql",
"ReservedCapacityPerAvailabilityZone": 1,
"AvailableCapacityPerAvailabilityZoneList": [
{
"AvailabilityZone": "ap-northeast-1a",
"AvailableCapacity": 1
}
],
"EndDate": "2026-10-22T00:28:20+00:00",
"CreateDate": "2026-10-22T00:27:21.292000+00:00",
"State": "active",
"DBCapacityReservationIdentifier": "dbcr-abc123example"
}
}
Since the State is active in the creation response, you can specify the ID without waiting.
According to the documentation, reservations are targeted, meaning only instances that specify the reservation will use the slot. The DBCapacityReservationIdentifier in the response is the reservation ID, which starts with dbcr-. Pass this to --db-capacity-reservation-identifier to create instance odcr-db1 (hereafter, the 1st instance). Please replace the DB subnet group with one from your own environment.
aws rds create-db-instance \
--db-instance-identifier odcr-db1 \
--db-instance-class db.t3.micro \
--engine mysql \
--engine-version 8.4.11 \
--master-username admin \
--manage-master-user-password \
--availability-zone ap-northeast-1a \
--allocated-storage 20 \
--db-subnet-group-name <your DB subnet group> \
--no-publicly-accessible \
--db-capacity-reservation-identifier dbcr-abc123example
The request was accepted, and DBCapacityReservationIdentifier was also included in the create-db-instance response. When checking the available capacity of the reservation via AvailableCapacity in describe-db-capacity-reservations, it was 1 before acceptance and 0 immediately after. A 2nd instance specifying the same reservation ID was rejected due to no available capacity.
When the reservation name was passed to --db-capacity-reservation-identifier, both creation and startup were rejected with InvalidParameterValue. The message was Invalid DB capacity reservation identifier: <reservation name>. The documentation and the help for each command (AWS CLI 2.38.4) state that the name can also be used, but only passing the ID was accepted.
Cases Where Creation Is Rejected
create-db-instance specifying a reservation was rejected in the following situations.
| Situation | Error Code | Message (beginning) |
|---|---|---|
| Non-existent ID | InvalidParameterValue | Invalid DB capacity reservation identifier: dbcr-doesnotexist |
| No available capacity (2nd instance with the same reservation) | InvalidParameterValue | RDS can't use DBCapacityReservation dbcr-abc123example for this Single-AZ DB instance because the reservation doesn't have enough available capacity in Availability Zones. |
| Expired reservation specified 13.5 seconds after the end date | InvalidDBCapacityReservationState | DBCapacityReservation end date is already expired. |
| Different AZ from the reservation | InvalidParameterCombination | The Availability Zone (AZ) parameter must match the AZ of the DBCapacityReservation. |
| Different class from the reservation (db.t3.small) | InvalidParameterCombination | The DB instance class must match the instance class of the DBCapacityReservation. |
Since a non-existent ID and no available capacity both result in InvalidParameterValue, they are distinguished by the message. A different AZ and a different class were rejected even when the reservation had available capacity.
Expired Reservations and Instances Being Created
When a reservation passes its end date, it becomes expired and its available capacity becomes 0. When checking the state at 5-second intervals, it was active just before the end date and expired just after.
The 1st instance created by specifying the reservation ID continued to be created even after the reservation's end date passed, and became available. It continued to operate with the reservation ID until it was stopped in the verification described in the next section.
Adding Running and Stopped Instances to a Reservation
While the 1st instance was running with the expired reservation ID, a new reservation with the same class, AZ, and engine was created. The available capacity of the new reservation remained at 1 until the end date, and the DBCapacityReservationIdentifier of the 1st instance also remained as the expired reservation's ID.
According to the documentation, modify-db-instance specifying a reservation for a running instance will fail unless it is performed simultaneously with a change to the instance class, Multi-AZ, or license model.
As a procedure for adding an existing instance to a reservation without changing its configuration, the documentation shows the method of stopping the instance and running start-db-instance with the reservation specified.
This procedure was tested with 2 stopped instances that had no reservation ID. One was the 1st instance from the previous section, from which the expired reservation ID had been removed during the stop process. The other was an instance created without specifying a reservation and then stopped. For both, a new reservation was created just before startup, with the end date set to approximately 1 minute later for the 1st instance and 15 minutes later for the other.
start-db-instance with a dbcr--prefixed ID was accepted and the instance entered the starting state, but the reservation's available capacity remained at 1. The period checked was until startup completed for the 15-minute reservation, and approximately 56 seconds from startup acceptance to the reservation's end date for the 1-minute reservation. Even after becoming available, DBCapacityReservationIdentifier was not attached to the instance. In contrast, with create-db-instance specifying the reservation ID, the available capacity decreased from 1 to 0 immediately after acceptance.
The 15-minute reservation was cancelled with cancel-db-capacity-reservation before the end date after confirming startup. The request was accepted, and the State in the response was cancelled with available capacity at 0.
Pricing and Relationship with RIs and Savings Plans
The content of this section is based on documentation. Capacity reservations are a mechanism for reserving AZ capacity and do not come with discounts. Reserved DB Instances (RIs) and Database Savings Plans are discount mechanisms and do not reserve capacity. Using capacity reservations together with these applies discounts to instances that use the reservation slots.
Reservation pricing is the same unit price as On-Demand, and is billed per second (minimum 60 seconds) until cancelled or until the end date is reached. The portion used by instances is billed as instance charges, and unused slots are billed as unused reservations. When an instance is stopped, that slot also becomes unused. The target of the reservation is compute, and storage and I/O charges remain unchanged.
Cancellation conditions differ by reservation type. immediately has no commitment and can be cancelled at any time while active. future-dated is a reservation that starts 5 to 120 days in the future. It requires 32 or more vCPUs per AZ, has a minimum commitment of 14 days (12 weeks for the X family), and cannot be cancelled during the commitment period even after becoming active. Instances that were using the slots of a cancelled reservation continue to run as On-Demand.
Summary
Capacity reservations similar to those in EC2 are now available for RDS and Aurora as well.
Due to the conditions of 32 or more vCPUs per AZ and a minimum 14-day commitment, verification of future-dated reservations (starting 5 to 120 days in the future) was skipped this time, though they have also been announced.
If you want to reliably launch DB instances with a specific instance class and AZ before a migration or event, try creating a capacity reservation and creating the instance by specifying the reservation ID.
