Amazon RDS の新機能「キャパシティ予約」（On-Demand Capacity Reservations）をためしてみた
はじめに
2026年10月21日、Amazon Aurora と Amazon RDS で On-Demand Capacity Reservations（以下、キャパシティ予約）が使えるようになりました。
AZ 単位でコンピュートの容量を確保しておき、DB インスタンスの作成・復元・スケール・起動が容量不足で失敗するのを防ぐ機能として発表されています。確保した容量を、以下では枠と呼びます。
この記事で試した予約は、種類が immediately（コンソールでは「今すぐ」）、台数が 1 台分です。環境は RDS for MySQL 8.4.11、db.t3.micro、東京リージョンの単一 AZ（ap-northeast-1a）です。予約は検証ごとに作成し、終了日時は作成の約 1 分後か 15 分後のどちらかにしました。
予約を作成し、ID を指定して DB インスタンスを作成する
予約は create-db-capacity-reservation で作成します。--end-date は UTC で指定します。例の値は実測時のものなので、実行時刻より後の日時に置き換えてください。
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"
}
}
作成の応答で State が active になっているので、待たずに ID を指定できます。
ドキュメントによると、予約は targeted で、予約を指定したインスタンスだけが枠を使います。応答の DBCapacityReservationIdentifier が予約の ID で、dbcr- で始まります。これを --db-capacity-reservation-identifier に渡して、インスタンス odcr-db1（以下、1 台目）を作成します。DB サブネットグループは自分の環境のものに置き換えてください。
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 <自分の DB サブネットグループ> \
--no-publicly-accessible \
--db-capacity-reservation-identifier dbcr-abc123example
リクエストは受理され、create-db-instance の応答にも DBCapacityReservationIdentifier が入りました。予約の空きを describe-db-capacity-reservations の AvailableCapacity で確認すると、受理の前は 1、直後は 0 でした。同じ予約の ID を指定した 2 台目は、空きがないため拒否されました。
予約の名前を --db-capacity-reservation-identifier に渡すと、作成と起動のどちらも InvalidParameterValue で拒否されました。メッセージは Invalid DB capacity reservation identifier: <予約の名前> です。ドキュメントと各コマンドの help（AWS CLI 2.38.4）には名前でも指定できると書かれていますが、受理されたのは ID を渡した場合だけでした。
作成が拒否されるケース
予約を指定した create-db-instance は、次の状況で拒否されました。
| 状況 | エラーコード | メッセージ（先頭） |
|---|---|---|
| 存在しない ID | InvalidParameterValue | Invalid DB capacity reservation identifier: dbcr-doesnotexist |
| 空きがない（同じ予約の 2 台目） | 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. |
| 終了日時の 13.5 秒後に指定した、失効済みの予約 | InvalidDBCapacityReservationState | DBCapacityReservation end date is already expired. |
| 予約と別の AZ | InvalidParameterCombination | The Availability Zone (AZ) parameter must match the AZ of the DBCapacityReservation. |
| 予約と別のクラス（db.t3.small） | InvalidParameterCombination | The DB instance class must match the instance class of the DBCapacityReservation. |
存在しない ID と空きがない場合は、どちらも InvalidParameterValue なので、メッセージで見分けます。別の AZ と別のクラスは、予約に空きがある状態でも拒否されました。
終了日時を過ぎた予約と作成中のインスタンス
予約は終了日時を過ぎると expired になり、空きが 0 になります。5 秒間隔で状態を確認すると、終了日時の直前は active、直後は expired でした。
予約の ID を指定して作成した 1 台目は、予約の終了日時を過ぎても作成が続き、available になりました。その後、次節の検証で停止するまで、予約の ID を持ったまま稼働しました。
稼働中・停止中のインスタンスを予約に入れる
1 台目が失効した予約の ID を持ったまま稼働している状態で、同じクラス・AZ・エンジンの予約を新しく作成しました。新しい予約の空きは終了日時まで 1 のままで、1 台目の DBCapacityReservationIdentifier も失効した予約の ID のままでした。
ドキュメントによると、稼働中のインスタンスへ予約を指定する modify-db-instance は、インスタンスクラス、Multi-AZ、ライセンスモデルのいずれかの変更と同時でないと失敗します。
構成を変えずに既存のインスタンスを予約に入れる手順として、ドキュメントにはインスタンスを停止し、予約を指定して start-db-instance を実行する方法が示されています。
この手順を、予約の ID を持たない停止中のインスタンス 2 台で試しました。1 台は前節の 1 台目で、停止の途中で失効した予約の ID が外れていました。もう 1 台は、予約を指定せずに作成してから停止したインスタンスです。どちらも起動の直前に予約を新しく作成し、終了日時は 1 台目用を約 1 分後、もう 1 台用を 15 分後にしました。
dbcr- で始まる ID を渡した start-db-instance は受理されて starting になりましたが、予約の空きは 1 のままでした。確認した期間は、15 分の予約では起動が完了するまで、1 分の予約では起動の受理から予約の終了日時までの約 56 秒間です。available になっても、インスタンスに DBCapacityReservationIdentifier は付きませんでした。一方、予約の ID を指定した create-db-instance では、受理の直後に空きが 1 から 0 に減りました。
15 分の予約は、起動を確かめた後、終了日時の前に cancel-db-capacity-reservation でキャンセルしました。リクエストは受理され、応答の State は cancelled、空きは 0 でした。
料金と RI・Savings Plans との関係
この節の内容はドキュメントに基づきます。キャパシティ予約は AZ の容量を確保する仕組みで、割引は付きません。リザーブド DB インスタンス（RI）と Database Savings Plans は割引の仕組みで、容量は確保しません。キャパシティ予約とこれらを併用すると、予約の枠を使うインスタンスに割引が適用されます。
予約の料金は On-Demand と同じ単価で、キャンセルされるか終了日時を迎えるまで、秒単位（最小 60 秒）で課金されます。枠を使っているインスタンスの分はインスタンス料金として、使われていない枠は未使用の予約として請求されます。インスタンスを停止すると、その分の枠も未使用になります。予約の対象はコンピュートで、ストレージや I/O の料金はこれまでどおりです。
キャンセルの条件は予約の種類で異なります。immediately はコミットがなく、active の間はいつでもキャンセルできます。future-dated は 5〜120 日先に開始する予約です。各 AZ で 32 vCPU 以上が必要で、最低 14 日（X ファミリーは 12 週間）のコミットがあり、active になった後もコミット期間中はキャンセルできません。キャンセルした予約の枠を使っていたインスタンスは、On-Demand として動き続けます。
まとめ
RDS と Aurora でも、EC2 と同様のキャパシティ予約を使えるようになりました。
各 AZ で 32 vCPU 以上、最低 14 日のコミットという条件のため、今回は検証を見送っていますが、将来の日付に開始する future-dated の予約（5〜120 日先）も発表されています。
移行やイベントの前に、特定のインスタンスクラスと AZ で DB インスタンスを確実に立ち上げたい場合は、キャパシティ予約を作成し、予約の ID を指定してインスタンスを作成してみてください。
