AWS、EC2 Capacity Managerにリアルタイムの対応可否チェックと容量充足率指標を追加、AWS Unified Operationsに含まれる：スコアは目安で容量の確約ではなく、ブログの数字は架空の企業の例

2026年11月4日、AWSは「What's New」で、Amazon EC2 Capacity Managerに2つの機能が加わったと発表しました。リアルタイムの「対応可否チェック」と「容量充足率の指標」です。対応可否チェックは、インスタンスを起動も予約もせずに、インスタンスタイプとアベイラビリティーゾーンの各組み合わせがリクエストにどの程度応えられるかをHigh、Medium、Lowで採点し、全体のスコアも返します。充足率の指標は、実際にどれだけの容量が提供されたかを、AWS組織、アカウント、リージョン、タグ付きワークロード別に示し、インスタンスタイプとアベイラビリティーゾーンまで分解できます。AWSは、どちらも重要なワークロードを運用するグローバル企業向けのAWSサポートプランであるAWS Unified Operationsに含まれ、すべての商用リージョンで使えるとしています。つまり、すべてのEC2ユーザーが標準で使える機能ではありません。

同じ日に公開されたAWSコンピューティングブログは操作の詳細を示していますが、AnyCompanyという架空の企業を例にしているため、その中の具体的な数字はすべて例であり、実在の顧客の測定値ではありません。利用するには、管理アカウントまたは委任管理者で組織レベルで、または単一アカウントでCapacity Managerを有効にし、アカウントがAWS Unified Operationsの対象である必要があります。ワークロード別に見るには、タグを監視対象のタグキーとして有効にできます。容量はvCPUで測られます。

充足の指標はリクエスト単位で4つあります。要求されたvCPU、提供されたvCPU、リクエスト充足率（提供÷要求、vCPUで加重）、そして各リクエストが使えるように設定されている「インスタンスタイプ×ゾーン」の組み合わせの平均数で、1を超えればそのリクエストには柔軟性があります。ブログによれば、同じ設定の5分以内の再試行は1回と数えられ、指標が測るのは実際の起動であって、チェックの正確さではありません。例では、search-indexワークロードは51,712 vCPUを要求し45,632を受け取って充足率は88.2%、利用可能な組み合わせは平均21でした。batch-etlは組み合わせが1つしか使えず72.8%でした。組み合わせ単位の率は、分散による効果を含むリクエスト全体の率より通常低くなります。例では28の組み合わせの単独平均は46.6%ですが、リクエスト全体は88.2%で、その差が柔軟性の効果です。use1-az5の3つの組み合わせは26,880 vCPUを提供して全体の半分超を占めながら、単独では68.6〜82.8%にとどまり、このゾーンが選択肢の追加や容量予約の対象になります。

対応可否チェックは計画段階で使います。市場タイプ（オンデマンドまたはスポット）、容量、ゾーン、候補のインスタンスタイプを指定するか、vCPUとメモリの範囲を指定してタイプを自動で絞り込み、各組み合わせにHigh、Medium、Lowと全体スコアが返ります。1回のチェックには最大10のゾーン（複数リージョンも可）と最大100の組み合わせを含められます。例では、5種類のタイプを3つのゾーンで100インスタンス分チェックしました。全体スコアはHighで、r5.16xlargeは3つのゾーンすべてでHigh、r7a.16xlargeはuse1-az6のみHigh、r6a.16xlargeはすべてMedium、新しい候補r7i.16xlargeは2つのゾーンでMedium、残る6つの組み合わせはr6i.16xlargeのすべてを含めLowでした。Highは要求に十分以上応えられ、Mediumは余裕が少ないが応えられ、Lowは要求より少ないことを意味します。

ブログは2つの制約を述べています。1つ目は、スコアは目安であって確約ではないことで、起動時に容量があることを保証したいなら、キャパシティ予約や将来日付のキャパシティ予約を使います。2つ目は、チェックはワークロードの計画時に行い、起動のたびには呼ばないことです。呼び出し先はCapacity Managerを有効にしたリージョンなので、起動ごとに呼ぶとリージョンをまたぐ依存が増え、1時間あたりのクォータを使い切るためです。例からは見落としやすい違いも分かります。r5.16xlargeはuse1-az5で現時点のチェックではHighですが、過去の実績では82.8%しか提供されていません。チェックは現在についての判断、充足率は過去についての事実で、どちらも他方の代わりにはなりません。

設定面では、チェックを通った組み合わせをAuto Scalingグループの混合インスタンスポリシー、EC2 Fleet、Karpenterに加えれば、柔軟性を一度設定するだけで以後の起動すべてに効くとし、平均の組み合わせ数で変更を確認するよう勧めています。確実さが必要な基準容量にはオンデマンドキャパシティ予約を使い、予約は使っても使わなくても課金されるため基準の大きさに合わせるよう述べています。日常の運用としては、週ごとに充足率を確認し、目標を下回るワークロードの内訳を開き、変更管理に対応可否チェックを加えることを挙げています。

AWS自身の製品発表とチュートリアルである点に注意してください。例の数字は実在の顧客を表さず、チェックのスコアと実際の起動成功率の統計的な関係は示されておらず、使えるかどうかはまずアカウントがAWS Unified Operationsの対象かどうかで決まります。