はじめに
AWSのGPUインスタンス枯渇対策について解説する連載の第3回（最終回）です。
これまでは、以下の「賢く立ち回る」ための戦略を紹介してきました。
- 第1回：AWS GPUインスタンスが起動しない！InsufficientInstanceCapacityとAPI制限エラーの正しい対処法（Exponential Backoffの活用）
- 第2回：GPUインスタンスの枯渇を回避！複数AZ・代替インスタンスタイプを活用したEC2起動戦略（フォールバック戦略とEC2 Fleet）
これらの対策で「空いているインスタンスを拾う確率」は劇的に上がりますが、それでも「明日の朝9時から、絶対にGPUを5台使ってモデルの学習を回さなければならない（失敗は許されない）」といった、シビアな業務要件には対応しきれません。
今回は、確率論ではなく「コストをかけてでも確実性を買う」ための究極の手段、「オンデマンド容量予約（ODCR）」と「Capacity Blocks for ML」について解説します。
1. 「オンデマンド容量予約（ODCR）」の仕組みと罠
「インスタンスを起動しっぱなしにするのはもったいない。でも、いざ起動しようとしたら在庫がないのは困る…」
そんな時に使えるのが、オンデマンド容量予約（On-Demand Capacity Reservation : ODCR）です。
これは、特定のAZに特定のインスタンスタイプを起動するための「空き箱（予約枠）」だけを確保しておく機能です。
メリット
- 予約枠さえ作れてしまえば、いつでも100%確実にインスタンスを起動できます。
- 起動する時は、この「予約枠の中」を指定してインスタンスを起動するだけです。
デメリット（罠）とコスト
この機能には、利用する上で絶対に知っておくべき2つの大きな罠があります。
- 確保できなければ予約すらできない
ODCRは「未来の予約」ではなく「今の在庫のキープ」です。つまり、作ろうとした瞬間にそのAZでGPUが枯渇していれば、「予約枠を作ること自体」がエラーになります。 - 使っていなくても100%の料金がかかる
予約枠を確保している間は、中にインスタンスを起動していようがいまいが、オンデマンド料金と全く同じ金額が秒単位で課金されます。
「なんだ、起動しっぱなしにするのとコスト同じじゃん」と思うかもしれません。
しかし、ハイブリッドな運用を行うことで真価を発揮します。例えば、「夜間の空いている時間帯にODCRを作成して枠をキープしておき、翌日の日中にその枠を使って処理を行い、終わったらODCRごと破棄する」といった戦略をとることで、24時間365日起動しっぱなしにするよりは大幅にコストを抑えつつ、必要な時間帯の確実性を担保できます。
2. 機械学習特化の救世主「Capacity Blocks for ML」
ODCRの「今空いていないと予約できない」という弱点を克服する、比較的新しい機能が Amazon EC2 Capacity Blocks for ML です。
これは、ホテルの予約のように「未来の特定の日付・期間（例：来週の月曜の朝8時から水曜の夜8時まで）」を指定して、GPUインスタンスを確実に予約できる機能です。
特徴
- 数日後から最大数週間先までの期間で、必要な日数（1日〜14日など）を予約できます。
- 予約した期間が開始されると、確実にそのGPUインスタンス群が利用可能になります。
注意点
非常に強力な機能ですが、現状（記事執筆時点）ではいくつか制限があります。
* ハイエンドインスタンス向け: 主に p4d、p5、trn1 といった、大規模な機械学習クラスタ向けの超高性能（そして超高額）なインスタンスが対象です。日常的な推論でよく使う g4dn や g5 のような安価なGPUインスタンスは、このCapacity Blocksの対象外であることが多いです。
* 需要に応じた価格変動: 予約時の空き状況によって価格が変動（ダイナミックプライシング）するため、常に固定料金というわけではありません。
そのため、日常的なバッチ処理の確保というよりは、「全社のデータサイエンティストが集中的にLLMの学習を回す期間」といった、大規模プロジェクトのスケジュールを確定させるための機能と言えます。
3. コストと要件に応じた最適解の選び方
これまでの全3回を踏まえ、要件に応じたGPU確保のベストプラクティスをまとめます。
パターンA：コスト最優先・待てる処理
- 手法: スポットインスタンス ＋ EC2 Fleet（第2回）
- 向いているケース: 途中で中断されてもやり直せる非同期タスク。数時間遅れても問題ない処理。
パターンB：コスパ良く、なるべく早く処理したい
- 手法: オンデマンド ＋ 複数AZ/代替インスタンスのフォールバック（第2回） ＋ Exponential Backoff（第1回）
- 向いているケース: Webサービスの裏側で動く画像生成・推論APIなど。
パターンC：絶対にこの時間帯に処理を成功させたい
- 手法: オンデマンド容量予約（ODCR）（今回）
- 向いているケース: 締め切りがあるバッチ処理。事前に空いている時間にODCRを確保し、本番に備える。
パターンD：大規模なAI学習プロジェクトのスケジュール確定
- 手法: Capacity Blocks for ML（今回）
- 向いているケース: 数百万円単位のコストをかけて、
p5インスタンスなどを数日間確実に確保したい場合。
まとめ
「GPUインスタンスが確保できない！」という問題は、AWSを利用する多くのエンジニアを悩ませていますが、AWS側もそれに対応するための様々な仕組み（Fleet、ODCR、Capacity Blocksなど）を提供しています。
自社のシステムが「待てる処理」なのか「待てない処理」なのか、そして「どれだけコストをかけられるか」を天秤にかけ、これらの手法を組み合わせて強靭なアーキテクチャを構築してみてください。
全3回にお付き合いいただき、ありがとうございました！
連載記事一覧
1. AWS GPUインスタンスが起動しない！InsufficientInstanceCapacityとAPI制限エラーの正しい対処法
2. GPUインスタンスの枯渇を回避！複数AZ・代替インスタンスタイプを活用したEC2起動戦略
3. どうしてもGPUが必要な処理に！AWS「オンデマンド容量予約」と「Capacity Blocks」入門（本記事）
