[アップデート] キャパシティ予約リソースグループが Amazon EC2 Capacity Blocks for ML と中断可能なキャパシティ予約に対応しました

[アップデート] キャパシティ予約リソースグループが Amazon EC2 Capacity Blocks for ML と中断可能なキャパシティ予約に対応しました

キャパシティ予約リソースグループが2026年8月のアップデートで進化し、オンデマンド、中断可能、Capacity Blocks for MLの3種類の予約を1つのグループに混在させられるようになりました。実際に試しながら、その使い方と活用メリットを紹介します。
2026.08.29

はじめに

キャパシティ予約リソースグループは複数のキャパシティ予約を 1 つにまとめられる仕組みです。2026 年 8 月 25 日のアップデートで、Amazon EC2 Capacity Blocks for ML と中断可能なキャパシティ予約もグループへ追加できるようになりました。 従来から対応していたオンデマンドキャパシティ予約と合わせて、3 種類の予約を 1 つのグループに混在させられるようになりました。

intro-a-before-after.png

https://aws.amazon.com/about-aws/whats-new/2026/08/capacity-reservation-resource-groups-ec2/

確認結果

確認したのは、オンデマンドキャパシティ予約と中断可能なキャパシティ予約の 2 種類です。Capacity Blocks for ML はあまりも高額なので今回の確認に含めていません。

  • 種類の違うキャパシティ予約を 1 つのグループに同居させられました
  • 同じグループ ARN を指定したまま、購入オプションを変えるだけで使われるキャパシティ予約が変わりました

なにが嬉しいのか

予約のタイプを問わず 1 つのグループにまとめられる

グループを指定してインスタンスを起動するとグループ内の予約が消費されます。アップデート前にグループへ追加できたのは、オンデマンドキャパシティ予約だけでした。Capacity Blocks for ML を買っていても、中断可能なキャパシティ予約を共有されていてもグループには入れられませんでした。

アップデート後は、どのタイプの予約でも同じグループに入れられます。インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン、テナンシー、プレイスメントグループが異なる予約も混在できます。自分のアカウントの予約と、AWS Resource Access Manager で共有された他アカウントの予約も同居できます。手元の予約はグループ ARN 1 つで指定できるようになりました。

benefit-c-shared.png

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-groups.html

予約タイプの消費順とオンデマンドへのフォールバックを指定できる

EC2 Fleet と Amazon EC2 Auto Scaling では、グループ内の予約をどのタイプから使うかを順序付きで指定できます。予約を使い切ったときにオンデマンドへ自動でフォールバックする設定もできます。たとえばオンデマンドキャパシティ予約から先に消費させ、次に中断可能なキャパシティ予約を使う。それでも足りなければ通常のオンデマンドインスタンスを使う指定か可能です。

When using EC2 Fleet and EC2 Auto Scaling groups, you can also specify your prioritization preferences across reservation types, and configure automatic fall back to EC2 On-Demand capacity when there is no capacity remaining across your reservations.

出典: Capacity Reservation Resource Groups now support Amazon EC2 Capacity Blocks and interruptible Capacity Reservations

中断可能なキャパシティ予約とは

中断可能なキャパシティ予約は、オンデマンドキャパシティ予約の未使用分を一時的に他のワークロードへ回せるようにする仕組みです。手持ちのオンデマンドキャパシティ予約から共有したいインスタンス数を指定すると、その分が新しい中断可能なキャパシティ予約へ移ります。切り出す前のこの予約を、以降は割り当て元と呼びます。割り当て元にできるのは active かつ終了日が設定されていない予約だけです。

作成した予約は AWS Resource Access Manager で組織内へ共有できます。借りる側はその予約にインスタンスを起動し、予約を保有する側(オーナー)はいつでも容量を回収できます。回収すると割り当て元へ容量が戻ります。

回収は 2 分前の通知があり、借りている側の起動中のインスタンスは終了します。終了されたインスタンスの代わりに、オンデマンドやスポットへ自動でフォールバックする仕組みはありません。 文字通り中断可能なワークロードではないと採用が難しいです。リトライ処理、冪等性の確保、すでにスポットインスタンスで運用できている環境であれば問題ありません。ただし中断の通知は EventBridge のイベントとして届きます。インスタンスメタデータでスポットの中断を検知している実装ではそのまま移行はできません。

コンソールでの作成や回収の動作は次の記事を参照ください。

https://dev.classmethod.jp/articles/amazon-ec2-interruptible-capacity-reservations/

https://dev.classmethod.jp/articles/amazon-ec2-fleet-interruptible-capacity-reservations/

3 種類のキャパシティ予約を見比べてみる

混在させる前に 3 種類の性質の違いを押さえておきましょう。明らかに毛色が違うのは GPU 予約の EC2 Capacity Blocks for ML です。

観点 オンデマンドキャパシティ予約 中断可能なキャパシティ予約 EC2 Capacity Blocks for ML
主な用途 必要な期間だけ容量を確保したいワークロード 未使用容量を借りて使う中断可能なワークロード GPU インスタンスを期間指定で確保する ML ワークロード
前払い なし なし あり(予約時に全額)
単価 オンデマンド料金と同額 オンデマンド料金と同額 需給に応じて変動(購入時点のレートで固定)
インスタンス未起動時の課金 予約してキャパシティを抑えているので課金される 割り当て元の課金が分割されるだけで合計は変わらない 前払い済みのため追加課金なし
Savings Plans と Reserved Instances の適用 Savings Plans は適用(Reserved Instances は Regional のみ) 割り当て元と同じ扱い(明記はなし) 不可
キャンセル 可能 直接不可(割り当て元で数量を変更して調整) 不可
予約終了時のインスタンス 終了されずオンデマンドとして継続 オーナーの回収時に終了 予約終了の 30 分前から自動終了(UltraServer は 60 分前)
共有範囲 組織外のアカウントにも共有可 同じ AWS Organizations 内のみ 同じ AWS Organizations 内(UltraServer は共有不可)

試してみた

オンデマンドキャパシティ予約を m5.large で 2 台分作り、そのうち 1 台分を中断可能なキャパシティ予約へ割り当てました。

種類の違う予約を 1 つのグループに同居させられた

オンデマンドキャパシティ予約と中断可能なキャパシティ予約の 2 つを作成しました。見分け方は「中断可能」列が「はい」か「いいえ」です。

キャパシティ予約の一覧。予約タイプはどちらも ODCR で、中断可能列が「いいえ」と「はい」に分かれている

オンデマンドキャパシティ予約と中断可能なキャパシティ予約の ARN をグループへ追加したところ 2 つとも登録できました。

グループの詳細画面です。2 本のキャパシティ予約が Active で、どちらもまだ使用率 0% です。

キャパシティ予約リソースグループの詳細画面。2 本の予約が Active で使用率 0%

同じグループに対して購入オプションを変えて起動してみた

グループ ARN は同じまま、起動時の購入オプションだけを変えて 2 台を起動しました。1 台目は購入オプションを指定せず、2 台目には interruptible-capacity-reservation を指定しています。2 台とも実行中になりました。

インスタンス一覧。devio-cr-group-odcr と devio-cr-group-interruptible が実行中、どちらも m5.large

Lifecycle 列に消費した予約の種類が、CrId 列に予約 ID が入ります。1 台目の LifecycleNone で、使われたのはオンデマンドキャパシティ予約でした。2 台目は interruptible-capacity-reservation で、中断可能なキャパシティ予約を消費しました。CrId もそれぞれ別の予約 ID になっています。

実行結果
|         CrId         |         Id           |              Lifecycle               |             Name              |   State   |
+----------------------+----------------------+--------------------------------------+-------------------------------+-----------+
|  cr-038c4a051cf4580ed|  i-02640c90ce9fb1981 |  None                                |  devio-cr-group-odcr          |  running  |
|  cr-0e8fb091e49644381|  i-0e780250695e521dc |  interruptible-capacity-reservation  |  devio-cr-group-interruptible |  running  |

グループの詳細画面でも、2 つの予約がどちらも使用率 100% になりました。

グループ詳細画面。2 本のキャパシティ予約がどちらも使用率 100%

指定するグループ ARN は 1 つのままで、購入オプションを変えるだけで、使われるキャパシティ予約が変わることを確認できました。

まとめ

キャパシティ予約リソースグループに、3 種類のキャパシティ予約を混在させられるようになりました。オンデマンドキャパシティ予約と中断可能なキャパシティ予約で試したところ、同じグループ ARN を指定したまま、起動時の購入オプションを変えるだけで使われるキャパシティ予約が変わりました。

おわりに

Capacity Blocks for ML は普段から追いかけていますが、中断可能なキャパシティ予約は把握できていなかったので勉強がてらまとめてみました。

参考

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事