Aurora/RDS オンデマンドキャパシティ予約でDR・マイグレーションの「キャパシティ不足」を防ぐ

Amazon Aurora・RDSを本番運用しているエンジニアであれば、一度は耳にしたことがあるのではないでしょうか。フェイルオーバーや復旧手順を実行した直後に表示される InsufficientDBInstanceCapacity エラーの恐ろしさを。2026年10月、そのリスクを根本から断ち切る新機能「オンデマンドキャパシティ予約（On-Demand Capacity Reservations）」が全商用リージョンで利用可能になりました。

本記事では、この機能の仕組みと料金体系から、DR・マイグレーションでの具体的な活用方法、そして既存のリザーブドインスタンス（RI）との違いと使い分けまで、実務目線で徹底解説します。

1. はじめに：フェイルオーバー時に「キャパシティ不足」で止まった経験はありませんか

DRフェイルオーバーで起きる最悪のシナリオ

DR設計は、ドキュメントの上では完璧に見えることがあります。セカンダリリージョンへのフェイルオーバー手順を整備し、RTO・RPO目標を定義し、定期的な訓練も実施している。しかし実際に障害が発生した瞬間、こんな事態が起こりえます。

障害発生 → インシデント対応を開始
スナップショットからのリストア、またはウォームスタンバイの起動を試みる
InsufficientDBInstanceCapacity — 物理的なキャパシティが足りず、インスタンスが起動できない

設計上は「復旧できるはず」の構成が、AWSのリージョン・AZ内における物理ハードウェアの空き状況によって破綻するのは、構造的なリスクです。特に大規模障害時は、同じリージョン内の多くのユーザーが同時にリソースを確保しようとするため、競合が発生しやすくなります。

2026年10月、Aurora/RDSにキャパシティ予約が登場

EC2ではすでに一般的だったオンデマンドキャパシティ予約（EC2 On-Demand Capacity Reservations）が、ついにDB層にも拡張されました。全商用リージョンで利用可能となり、AuroraおよびRDSの両方に対応しています。

この記事では次の4点を中心に解説します。

キャパシティ予約の仕組みと料金体系
DRシナリオでの具体的なユースケース
マイグレーション計画への組み込み方
既存のリザーブドインスタンス（RI）との違いと使い分け

2. オンデマンドキャパシティ予約とは何か（仕組みを3分で理解）

何を予約するのか：3つの指定項目

キャパシティ予約では、以下の3つの属性を指定してAWSのコンピュートキャパシティを確保します。

DBインスタンスクラス（例：db.r7g.large）
エンジン（例：Aurora MySQL、PostgreSQL互換など）
アベイラビリティゾーン（AZ）（例：ap-northeast-1a）

「この構成のキャパシティをこのAZで押さえておく」という予約であり、特定のDBインスタンスとの紐付けは不要です。予約さえアクティブであれば、対象の構成でインスタンスを起動・復元する際にキャパシティ不足が発生しなくなります。

どのタイミングのキャパシティ不足を防げるのか

具体的には以下の操作時にキャパシティが消費されます。

DBインスタンスの新規作成
スナップショットからのリストア
インスタンスクラスの変更（スケールアップ）
スケーリング操作

これらの操作が、予約済みのキャパシティを利用して実行されます。

予約タイプは2種類

即時予約（Immediate）

コミットメント不要で、いつでもキャンセル可能な予約タイプです。作成した瞬間からキャパシティが確保されます。短期間の検証や、突発的な需要への対応に向いています。

スケジュール予約（Future-dated）

開始日を5〜120日後として指定できる予約タイプです。最低コミット期間が設定されており、途中キャンセルにはポリシーが適用されます。計画的なマイグレーションや、長期間のDR確保に向いています。

【重要】予約は「クラスター単位」ではなく「DBインスタンス単位」

ここは多くのエンジニアが誤解しやすいポイントです。Auroraクラスターに対して1つ予約すれば全インスタンスがカバーされる、というわけではありません。プライマリインスタンス・リードレプリカそれぞれに対して、個別に予約が必要です。

Multi-AZやリードレプリカ構成では、インスタンス数分の予約を設計しておかないと「予約したのに足りない」という事態が発生します。設計段階で必ずインスタンスの棚卸しを行いましょう。

3. 料金体系：いくらかかるのか、どこで損をするのか

基本ルール：予約がアクティブな間はオンデマンドレートで課金

キャパシティ予約の料金設計において最も重要な点は、DBインスタンスが稼働していなくても、予約がアクティブである限り課金が発生することです。課金は秒単位（最低60秒）です。

キャパシティ予約自体に割引はない

「予約」という名前から割引が発生すると誤解されることがありますが、オンデマンドキャパシティ予約はコスト削減のための機能ではありません。あくまで物理キャパシティの確保が目的です。

ただしRI・Database Savings Plansの割引は自動適用される

割引と確保は別の機能が担います。既存のReserved DB Instances（RI）やDatabase Savings Plansをお持ちの場合、キャパシティ予約を使用しているインスタンスに対しても従来どおり割引が自動的に適用されます。割引はRI/SP、確保はキャパシティ予約という役割分担で設計されています。

課金シミュレーション（db.r7g.large / $0.276/時）

時間	状態	課金内容
1時間目	予約中・未使用	$0.276（未使用予約料）
2〜5時間目	DBインスタンスが利用中	$0.276/時（インスタンス料のみ）
6時間目	予約キャンセル済	$0.276（通常オンデマンド料）

2〜5時間目において「インスタンス料のみ」と記載している点に注目してください。予約を使用している間は未使用予約料が発生せず、通常のインスタンス料金のみが課金されます。つまり二重課金ではなく、使えば使用料に吸収される構造です。

「未使用予約（unused reservation）」をどう捉えるか

DR用途でキャパシティを長期間確保している場合、未使用の状態が続くことがあります。これは損なのでしょうか。

実際の開発現場では、この費用を「可用性の保険料」として予算化することをベストプラクティスとして推奨します。障害発生時にキャパシティ不足でRTOが達成できないリスクと、毎月の予約コストを比較したとき、ビジネスクリティカルなシステムであれば後者のほうが圧倒的に安価です。SLAの違反コストや、障害時の機会損失を試算したうえで経営判断に含めましょう。

4. DRシナリオでの活用：ウォームスタンバイを「確実に」立ち上げる

パターン1：セカンダリリージョンのスタンバイ確保

最もシンプルかつ効果的なユースケースです。マルチリージョン構成でDRを設計している場合、フェイルオーバー先のリージョン・AZに対して事前にキャパシティを予約しておきます。

これによりRTO目標が「キャパシティの運次第」という不確定要素から切り離されます。スナップショットリストアの時間は計算できても、キャパシティが確保できるかどうかは事前に予測できません。キャパシティ予約はその不確定要素を排除する手段です。

パターン2：Multi-AZ構成での複数AZ同時予約

Single-Regionで高可用性を確保しているチームには、複数AZへの同時予約が有効です。プライマリインスタンスが存在するAZと、スタンバイが存在するAZの両方に予約を入れることで、AZ障害時に残存AZで確実に起動できる構成を担保できます。

Auroraクラスターのリードレプリカが複数AZに分散している場合も、各インスタンス・各AZごとに予約が必要です。設計段階でインスタンスマップを整理しておきましょう。

パターン3：季節ピーク・イベント前のスケールアップ保証

DR以外でも実用的なシナリオがあります。年末商戦やサービスローンチ前に、インスタンスクラスをスケールアップする計画がある場合、スケーリング時のキャパシティ不足リスクを事前に排除できます。

スケジュール予約を活用し、スケールアップ予定日の数日〜数週間前からキャパシティを確保しておくのが実務的なアプローチです。

DR設計への組み込みチェックリスト

DR対象インスタンスの棚卸し（クラスター内のインスタンス数・クラス・AZを一覧化）
フェイルオーバー先のAZ分散方針の確認
予約期間とコスト上限の設定（未使用予約コストを保険料として予算化）
定期的なフェイルオーバー訓練と予約状態の連動確認
予約の有効期限切れアラートの設定

5. マイグレーション計画への組み込み方（3ステップ）

段階的に理解を深めていきましょう。マイグレーションプロジェクトへのキャパシティ予約の組み込みは、3つのフェーズで整理できます。

ステップ1：移行先構成を確定し、スケジュール予約を作成

移行先のDBクラス・AZ・エンジンが決まったら、移行日の5〜120日前にスケジュール予約を作成します。長期プロジェクトでも最大120日前から予約できるため、計画段階で早めに確保しておくことが可能です。

重要なのは「移行日」ではなく**「リハーサル日」から逆算する**ことです。本番移行の前に必ずリハーサル（テスト移行）を実施するはずです。そのリハーサル日に間に合うよう予約を作成してください。リハーサルで問題が発生して本番移行が延期になった場合でも、即時予約に切り替えることで対応できます。

ステップ2：移行期間中はRI/Savings Plansと併用する

移行中はインスタンスが並行稼働する期間が生じることがあります（旧環境・新環境の同時稼働）。この期間のコストを最小化するために、RI/Savings Plansの割引とキャパシティ予約を組み合わせます。割引を効かせながらキャパシティを確保するという、両者の役割を最大限に活用しましょう。

ステップ3：移行完了後の後処理

移行が完了したら、スケジュール予約は役目を終えます。以下のいずれかの対応を取りましょう。

即時予約へ切り替える：まだキャパシティ確保が必要な場合（例：しばらく旧環境を残す場合）
RIに切り替えてコスト最適化する：長期稼働が確定した場合
予約を削除する：不要になった場合

「移行が終わったのにキャパシティ予約が残っていて、未使用コストが発生し続けている」というケースは現場でよく見られます。移行完了後の予約削除を移行手順書に明示的に記載しておくことを強く推奨します。

6. リザーブドインスタンス（RI）との違いと使い分け

一覧比較

観点	キャパシティ予約	リザーブドインスタンス（RI）
目的	キャパシティの物理確保	料金割引
コミットメント	即時は不要／スケジュールは最低期間あり	1年または3年の固定コミット
割引	なし（RI/SP併用で適用）	あり（最大69%程度）
キャパシティ保証	あり（AZ指定）	なし
向く場面	マイグレーション・DR・ピーク・ローンチ	常時稼働・長期安定ワークロード

よくある誤解：「RIを買えばキャパシティも確保される」はNo

技術的に正確な表現をするならば、RIは請求上の割引であり、物理的なキャパシティの確保とは無関係です。RIを購入してもAWS側のキャパシティが枯渇していれば、インスタンスの起動に失敗する可能性があります。

「数年前にRIを買っているから大丈夫」という認識は、キャパシティの観点からは誤りです。このことを組織内で共有しておくことが重要です。

ベストプラクティスは「組み合わせ」

実際の開発現場では、RI/Savings Plansとキャパシティ予約を組み合わせて使うのがベストプラクティスです。

RI/Savings Plans：長期稼働インスタンスのコストを最大69%削減
キャパシティ予約：重要なタイミングでの起動失敗リスクをゼロに

この2つは競合する機能ではなく、相補的な機能です。RIの割引はキャパシティ予約で使用中のインスタンスにも自動適用されるため、実コストの増加を抑えながら可用性を向上させることができます。

判断フロー：あなたのワークロードはどちらが必要か

以下のフローで判断してください。

常時稼働していて長期間変わらないか？
  → Yes → RI/Savings Plansを優先
  → No  ↓

起動失敗が致命的（DR・本番移行・ローンチ）か？
  → Yes → キャパシティ予約を追加
  → No  → 必要に応じて即時予約を検討

7. よくある質問（FAQ）

未使用時も課金されるのは損ではないですか？

損かどうかはワークロードによります。DRやマイグレーション用途では、可用性の保険料として捉えるのが正しいアプローチです。一方、常時稼働しているインスタンスに対してキャパシティ予約を使う場合は、インスタンス料と予約料が重複なく課金される設計になっているため、実質的な追加コストはほとんどありません。

EC2のCapacity Reservationと同じものですか？

コンセプトは同じですが、別の機能として実装されています。EC2とRDS/Auroraでは管理コンソールやAPIが異なります。EC2のキャパシティ予約の経験があるエンジニアには直感的に理解しやすい機能ですが、設定インターフェイスはそれぞれ専用のものを使用します。

Multi-AZクラスターやリードレプリカにも使えますか？

使えます。ただし前述のとおり、予約はDBインスタンス単位です。Multi-AZクラスターで3つのインスタンスがある場合、3つ分の予約が必要です。クラスター全体を1つの予約でカバーすることはできません。

スケジュール予約は途中でキャンセルできますか？

スケジュール予約には最低コミット期間が設定されているため、その期間内のキャンセルにはポリシーが適用されます。一方、即時予約はいつでもキャンセル可能です。移行完了後に切り替えを行う際は、スケジュール予約のコミット期間を事前に確認しておきましょう。

Aurora ServerlessやAurora Global Databaseとの関係は？

Aurora Serverless v2はDBインスタンスクラスを固定指定しない設計のため、キャパシティ予約の対象外となる場合があります。Aurora Global Databaseについては、各リージョンのDBインスタンスに対してそれぞれ予約を設定できます。セカンダリリージョンのキャパシティを確保することで、グローバルデータベースのDR設計をより堅牢にできます。最新の対応状況は公式ドキュメントをご確認ください。

8. まとめ：可用性は「設計」だけでなく「確保」が必要になった

この記事の要点3つ

予約はDBインスタンス単位：クラスター全体を1つの予約でカバーできないことを必ず覚えておく
キャパシティ予約は割引機能ではない：コスト削減ではなく可用性確保のための機能
RI/Savings Plansとの併用が前提：割引はRI/SP、確保はキャパシティ予約という役割分担で最適化する

今日から始める最初の一歩

まずはDR対象インスタンスの棚卸しから始めることを推奨します。現在のクラスター構成・インスタンスクラス・AZを一覧化し、フェイルオーバー先として必要なキャパシティを洗い出してください。

次に、本番への適用前に1台の即時予約をテスト環境で作成してみましょう。コンソールやCLIでの操作感を把握し、課金がどのように発生するかを実際に確認することが、本番設計の精度を高めます。

可用性は設計書の中だけで完結するものではありません。物理キャパシティの確保というオペレーション上の一手が、DRやマイグレーションの成否を左右する時代になりました。オンデマンドキャパシティ予約は、その一手を確実に打てるようにするための機能です。

参考リンク

AWS What's New: Amazon Aurora and RDS On-Demand Capacity Reservations
Amazon Aurora 公式ドキュメント（キャパシティ予約）
Amazon RDS 公式ドキュメント（キャパシティ予約）
Amazon RDS 料金ページ（On-Demand Capacity Reservations）