Amazon Web Services ブログ
キャパシティの分割、移動、変更による Amazon EC2 オンデマンドキャパシティ予約の効率的な管理
本稿は、2025 年 3 月 11 日に公開された “Efficiently manage Amazon EC2 On-Demand Capacity Reservations (ODCRs) with split, move, and modify” を翻訳したものです。
はじめに
今日のクラウドファーストの世界では、アプリケーションの可用性を確保しながらコンピューティング能力を効率的に管理することがビジネスにとって非常に重要です。Amazon EC2 オンデマンドキャパシティ予約（ODCR）は、予約を管理したいが、複数のチームやアカウントにまたがる予約を管理するのは難しいと考える組織にとって有用なツールです。2024 年 8 月に、キャパシティ予約の管理に新しい機能（分割、移動、変更）が導入されました。このブログでは、これらの機能がどのように業務を変えることができるかご紹介します。
ODCR に関するよくある課題
ODCR を活用する際、キャパシティ予約の管理についていくつか課題に直面することがあります。これらの課題には以下が含まれますが、これらがすべてではありません。
- 一部のアカウントで予約したキャパシティが十分に活用されていない
- 余剰キャパシティを効率的に再配分できていない
- 複数の AWS アカウントにわたる既存キャパシティの管理が難しい
- キャパシティ予約後の変更が難しい
複数の開発チームと様々なプロジェクトが同時に進行している場合、効率的なキャパシティ割り当てに苦労するかもしれません。また、あるチームではキャパシティが余っている一方で、別のチームではキャパシティが切実に必要になっているという状況に直面することもありえます。
ユースケース 1: チーム間でのキャパシティの再配分
未使用キャパシティのジレンマ
機械学習（ML）チームが c5.2xlarge インスタンス 10 個分の ODCR を所有しているものの、実際に使用しているのは 5 個のみというシナリオを考えてみます。一方、分析チームは新しいプロジェクトのために、同じタイプの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを 3 個を必要としています。これまでであれば、分析チームは新しいキャパシティ予約を作成する必要があり、独自のキャパシティ予約を管理するという不要な作業が発生していました。一方、ML チームが所有する ODCR の未使用のキャパシティ 5 個分は、不要なコストを発生させています。
キャパシティの分割
キャパシティ予約の分割機能を使用すると、EC2 インスタンス 10 個分の ODCR （図 1 の ODCR-1）を分割し、未使用キャパシティ 3 個分を使用して新しい ODCR を作成できるようになります。
図 1: キャパシティ分割前の ODCR-1 のキャパシティ
この機能により、2 つの ODCR が作成されます。
- 元の ODCR（ODCR-1）: ML チーム向けのインスタンス 7 個分のキャパシティ
- 新しい ODCR（ODCR-2）: 分析チーム向けのインスタンス 3 個分のキャパシティ
分割されると次の図のようになります。
図 2: キャパシティ分割により更新された ODCR-1 と新しく作成された ODCR-2
アカウント間の共有
キャパシティ予約の分割機能により、同じ AWS アカウント内に新しい ODCR が作成できます。チームが同じ AWS アカウントで作業している場合は、分割は直接実行され、追加の作業は必要ありません。ただし、チームが異なる AWS アカウントを使用している場合は、分割後に新しく作成された ODCR を共有するために、AWS Resource Access Manager (AWS RAM) を使用する必要があります。これにより、アカウント間で共有されたキャパシティ予約も一元管理できます。
キャパシティを分割する場合の前提条件と考慮事項の詳細については、AWS ドキュメントを参照してください。
また、パラメーターや例外、制限などの詳細については、API および CLI のドキュメントを参照してください。
ユースケース 2: ODCR 間のキャパシティの移動
成長に合わせたスケーリング
数日後、分析チームではプロジェクト拡大のためにさらにインスタンス 1 個分のキャパシティが必要になり、ODCR-2 にキャパシティをさらに追加する必要が出てきました。
キャパシティの移動
この目的のために新しい ODCR を作成するのではなく、未使用キャパシティの 1 つを ODCR-1 から ODCR-2 に移動することができます。この柔軟性により、新しくキャパシティ予約を作成する手間が省かれ、既存のワークロードの実行も中断されず、ODCR の管理をシンプルにできます。キャパシティの移動により、追加の調達を行うことなく、最適なリソース使用率を確保できます。
図 3: キャパシティ移動前の ODCR-1 と ODCR-2
図 4: キャパシティ移動によりキャパシティを減らした ODCR-1 とキャパシティが追加された ODCR-2
キャパシティを移動する場合の前提条件と考慮事項の詳細については、AWS ドキュメントを参照してください。
また、パラメーターや例外、制限などの詳細については、API および CLI のドキュメントを参照してください。
ユースケース 3: 変化するワークロードのパターンに合わせたキャパシティ予約属性の調整
動的なワークロード要件
データ処理のワークロードパターンが大きく変化する場合は、それに適応する必要があります。最初は、ODCR を特定のインスタンスに限定する基準で作成し、予測可能なワークロードを対象としていました。ですが、より動的で即興的な分析プロジェクトを導入するにつれて、予約に対してインスタンスを起動する方法をより柔軟にする必要が出てきました。
キャパシティ予約の変更
キャパシティ予約の変更により、新しい予約を作成したり、実行中のワークロードを中断したりすることなく、予約の属性を変更できるようになりました。ODCR は以下の変更が可能です。
- インスタンス数の変更
- インスタンスの適格性の変更（ターゲットからオープンへ）
- プロジェクトのタイムラインに合わせたキャパシティ予約の終了日の変更
キャパシティ予約の変更により、以下のことができるようになります。
- 厳密なインスタンスの適格性がなくても、新しいインスタンスをより柔軟に起動可能
- さまざまなプロジェクトにおけるキャパシティ予約の使用率向上
- 変化するビジネスニーズに適応しながら、コストの最適化
この機能は、既存のワークロードが中断されることなく継続的に実行されることを保証しながら、柔軟性を確保できるため、動的なワークロードにとって非常に貴重なツールとなります。ODCR-2 のキャパシティを 4 から 6 に変更する例については、次の図をご覧ください。
図 5: キャパシティ予約変更前の ODCR-2（全体キャパシティは 4 でインスタンスの適格性はターゲット）
図 6: キャパシティ予約変更後の ODCR-2（全体キャパシティは 6 でインスタンスの適格性はオープン）
ODCR の規模を拡大したり、新規に作成したりするには、Amazon EC2 オンデマンドインスタンスのキャパシティに空きがあることが条件となります。したがって、既存の ODCR に未使用のキャパシティがある場合は、ODCR を変更するよりも、その ODCR を移動または分割する方が適切な選択肢となる場合があります。
キャパシティ予約を変更する場合の前提条件と考慮事項の詳細については、AWS ドキュメントを参照してください。
また、パラメーターや例外、制限などの詳細については、API および CLI のドキュメントを参照してください。
キャパシティ分割に関する特別な考慮事項
前のセクションでは、キャパシティ分割機能を使用して未使用の余剰キャパシティを切り離し、別のチームの ODCR を作成する方法について説明しました。また、この機能を使用して、使用済みキャパシティを分割して新しい ODCR を作成することもできます。この機能は、部分的に使用されている ODCR を分割して新しい ODCR を作成し、追跡と管理を容易にしたい場合に特に役立ちます。未使用や余剰キャパシティの分割に関する考慮事項に加えて、使用済みキャパシティの分割には以下の考慮事項があります。
- 使用済みキャパシティは、どのアカウントとも共有されておらず、インスタンスの適格性がオープンである ODCR に対してのみ分割できる
- キャパシティ予約内で実行されているインスタンスの適格性はオープンである
- 使用済みキャパシティを分割すると、適格性のあるインスタンスがランダムに選択される。分割対象のインスタンスを指定することはできず、数量を満たすのに十分な数の適格性のあるインスタンスが見つからない場合、キャパシティ分割は失敗する。分割するインスタンス数を指定すると、デフォルトでは未使用のキャパシティが最初に移動され、次に適格性のある実行中のインスタンス（予約内の使用済みキャパシティ）が移動される
次のセクションでは、キャパシティ分割を使用できるシナリオと使用できないシナリオについて説明します。
シナリオ 1: 社内における ODCR の管理（他の AWS アカウントと共有されないキャパシティ予約）
社内プロジェクトで利用する ODCR が、他の AWS アカウントを持つ外部パートナーと共有せず、インスタンスの適格性がオープンであるシナリオとして、以下の条件を満たす ODCR-1 を考えてみます。
- 全体キャパシティが 10 個の c5.2xlarge インスタンス（インスタンスの適格性はすべてオープン）
- 現在 ML チームが使用しているインスタンスは 8 個
- 未使用のインスタンスは 2 個
図 7: キャパシティ分割前の ODCR-1（全体キャパシティは 10 で未使用キャパシティは 2）
この ODCR は他の AWS アカウントと共有されないため、キャパシティ予約を分割する際の柔軟性を最大限に高めることができます。現在使用中のインスタンス数に関わらず、最大 9 個のインスタンスを新しいキャパシティ予約（全体キャパシティから 1 を引いた数）として分割できます。このシナリオでは、使用済みキャパシティと未使用キャパシティの両方を共有できます。これにより、社内チームのキャパシティ割り当てを柔軟に再編成できます。
図 8: キャパシティ分割により更新された ODCR-1 と新しく作成された ODCR-2
シナリオ 2: 外部パートナーと共有する ODCR の管理（他の AWS アカウントと共有されるキャパシティ予約）
ODCR を外部パートナーの AWS アカウントと共有する必要があるシナリオとして、以下の条件を満たす ODCR-1 を考えてみます。
- 全体キャパシティが 10 個の c5.2xlarge インスタンス
- 現在チームとパートナーが使用しているインスタンスは 8 個
- 未使用のインスタンスは 2 個
図 9: 他の AWS アカウントと共有するキャパシティ分割前の ODCR-1
この場合、選択肢は限定されます。ODCR-1 はパートナーの AWS アカウントと共有されるため、未使用のキャパシティ（最大 2 つのインスタンス）のみを分割できます。キャパシティ分割後、新しく作成された ODCR-2 は社内の AWS アカウントに残り、他の AWS アカウントと共有されることはありません。これにより、パートナーが実行中のワークロードへの中断を防ぎながら、キャパシティ管理の柔軟性を確保できます。
図 10: キャパシティ分割により他の AWS アカウントと共有される ODCR-1 と共有されない ODCR-2
これらのシナリオは、社内環境および外部パートナーとの共有環境の両方におけるキャパシティ管理に関して重要なものです。キャパシティの分割や変更を計画する前に、ODCR の共有状況を慎重に検討し、社内チームと外部パートナーの両方にとって円滑な運用を確保する必要があります。
キャパシティ移動に関する特別な考慮事項
キャパシティ移動を行うと、利用可能な（または余剰の）キャパシティを ODCR 間で再配分できます。ただし、場合によっては、この機能を使用して使用済みインスタンスを ODCR 間で移動することもできます。この機能は、部分的に使用されている ODCR を 1 つに統合して追跡と管理を容易にしたい場合に特に役立ちます。未使用キャパシティの移動に関する考慮事項に加えて、使用済みキャパシティの移動には以下の考慮事項があります。
- 移動元の ODCR と移動先の ODCR はどちらもインスタンスの適格性をオープンとして利用可能でアクティブ状態である
- キャパシティ予約内で実行されているインスタンスはインスタンスの適格性をオープンとして利用可能である
- 移動元の ODCR と移動先の ODCR はどちらも同じ AWS アカウントが所有する
- 移動元の ODCR と移動先の ODCR は共有可能だが、使用済みインスタンスを移動する際に同じアカウントリストを使用する必要がある。また、同じアカウントへ共有するための条件は、ODCR の未使用部分には適用されない
移動するインスタンス数を指定すると、デフォルトでは未使用キャパシティが最初に移動され、次に対象となる実行中のインスタンス（予約で使用されているキャパシティ）が移動されます。
次のセクションでは、この機能が使用できる場面と使用できない場面を説明します。
シナリオ 1: 移動元と移動先の ODCR を他のアカウントと共有していない（チーム内でのキャパシティ移動）
同じ AWS アカウント（アカウント A）を使用して社内チーム間でキャパシティを管理する場合、プロセスは明確です。例えば、ML チームのリソースを統合するシナリオとして、以下の条件を満たす ODCR-1 と ODCR-2 を考えてみます。
- ODCR-1（ML チーム A）：合計キャパシティ 10 個のうち、8 個は使用中で 2 個は未使用（インスタンスの適格性はすべてオープン）
- ODCR-2（ML チーム B）：合計キャパシティ 5 個のすべてが使用中（インスタンスの適格性はすべてオープン）
図 11: キャパシティ移動前の ODCR-1 と ODCR-2（どちらも同じ AWS アカウントで共有なし）
両方の ODCR は同じアカウントに属しており、外部と共有されておらず、インスタンスの適格性はオープンです。そのため、ODCR-1 から ODCR-2 にすべてのキャパシティを自由に移動でき、統合 DevOps チーム向けに 15 個のインスタンスからなる統合プールを作成できます。
図 12: ODCR-1 からキャパシティが移動され、合計キャパシティが 15 になった ODCR-2（2 個は未使用）
シナリオ 2: 移動元と移動先の ODCR が同じアカウントで共有される（外部パートナーとのコラボレーション）
ML チーム（ODCR-1）が外部の AI 研究パートナー（アカウント B）と連携するシナリオとして、以下の条件を満たす ODCR-1 と ODCR-2 を考えてみます。
- ODCR-1: 合計キャパシティ 10 個（8 個が使用済み、2 個が未使用）のインスタンスの適格性はすべてオープンであり、AWS RAM を通じて研究パートナーと共有
- ODCR-2: 社内分析チーム用の合計キャパシティ 5 個（すべて使用済み）のインスタンスの適格性はすべてオープン
図 13: キャパシティ移動前の ODCR-1 と ODCR-2（ODCR-1 は他の AWS アカウントと共有）
分析チームにさらに多くのキャパシティが必要になった場合、他の 8 個は外部パートナーとのコラボレーションで使用されているため、未使用のインスタンス 2 個だけを ODCR-1 から ODCR-2 に移動できます。
図 14: ODCR-1 の未使用キャパシティのみが移動されて拡張された ODCR-2
シナリオ 3: 異なるアカウントで共有される移動元 ODCR と移動先 ODCR（複数の外部パートナーが参加するプロジェクト）
さまざまなパートナー契約にわたるキャパシティの管理を伴うこのシナリオでは、次のようになります。
- ODCR-1: データベースパートナー（アカウント B）と共有される全体キャパシティ 10 個のインスタンス（使用済み 8 個、未使用 2 個）
- ODCR-2: セキュリティパートナー（アカウント C）と共有される全体キャパシティ 5 個のインスタンス（すべて使用済み）
図 15: 異なる AWS アカウントで共有される ODCR-1 と ODCR-2
パートナー契約が異なる、つまり ODCR が他のアカウントと共有されているため、未使用の 2 つのキャパシティを ODCR-1 から ODCR-2 にのみ移動できます。これにより、データベースパートナーのワークロードに影響が出ることはありません。
図 16: 共有されたキャパシティ予約により、ODCR-1 の未使用キャパシティが移動された ODCR-2
これらのシナリオから、マルチアカウント環境におけるキャパシティ管理に関する貴重な教訓を得ることができます。柔軟性とパートナーのコミットメントのバランスを取った包括的な共有戦略を策定することで、強固なパートナー関係を維持しながらリソース使用率を最適化できます。
まとめ
AWS の新しい ODCR 機能（分割、移動、変更）は、クラウドキャパシティ管理において大きな進歩となりました。これらの機能は、組織におけるコンピューティングリソースの運用方法を変革し、より効率的な運用とコスト管理を実現します。キャパシティ予約を動的に調整・共有できる機能により、重要なワークロードに必要な安定性を維持しながら、必要な柔軟性が得られます。
クラウドインフラストラクチャが進化を続ける中、これらの機能により、複雑なクラウド環境の管理で直面する現実的な課題へ対応できるようになりました。AWS インフラストラクチャの最適化に向けて、新しい ODCR 機能はキャパシティ管理とリソース利用を向上させる強力なツールとなります。
これらの機能への理解を深めていただくために、実装用の API を含む GitHub リポジトリを作成しました。詳細については、キャパシティ予約のドキュメントをご覧ください。ご質問やご意見がございましたら、コメント欄にご記入いただくか、AWS サポートまでお気軽にお問い合わせください。
翻訳はソリューションアーキテクトの 阿部 純一郎 が担当しました。