はじめに
2026 年 4 月 30 日、AWS は Amazon ECS Managed Instances に対して NVIDIA GPU メトリクスのサポートを発表しました。Amazon CloudWatch Container Insights の拡張オブザーバビリティを通じて、GPU ワークロードの状態を CloudWatch ネイティブで監視できるようになります。
ECS 上で GPU ワークロードを運用している方は、これまで GPU の使用率やメモリをどうやって監視していたでしょうか。CPU やメモリと違い、GPU 固有のメトリクスはプラットフォームが標準提供してくれるものではなく、外部のツールや監視スタックを自前で組み合わせる必要がありました。今回のアップデートはこの課題に直接応えるものです。
同月に発表された GPU Auto Repair と組み合わせることで、ECS 上の GPU 運用を「可視化と自動修復」の両面からカバーできます。
本記事では「何が変わったのか」「どのメトリクスが取得できるのか」「CloudWatch とどう連携して使うのか」「コストをどう考えるか」を中心に解説します。ECS 上で GenAI 推論やモデルトレーニングを運用しているエンジニアはぜひ読んでみてください。
何が変わったのか
ECS 上で GPU ワークロードを本番運用したことがある方なら、GPU の状態把握がいかに手間だったかをご存知かと思います。
| 項目 | Before | After |
|---|---|---|
| GPU 使用率の把握 | 独自スクリプトや外部ツールで収集 | CloudWatch で直接確認 |
| メモリ・温度・ハードウェア健全性の監視 | 独自の監視基盤を別途構築・運用 | Container Insights に統合 |
| 既存の CloudWatch エコシステムとの連携 | 独自実装が必要 | CloudWatch の標準機能としてそのまま利用可能 |
| 追加コスト | — | あり（Container Insights 拡張オブザーバビリティ料金） |
従来の課題
GPU メトリクスの監視は、CPU やメモリのようにプラットフォームが標準で提供してくれるものではありませんでした。使用率や温度をリアルタイムで把握するには、GPU 固有のツールを活用した監視スクリプトを自前で書くか、外部の監視スタックを別途構築・運用する必要がありました。
こうした独自の監視基盤は、構築コストだけでなく運用コストも無視できません。「GPU が高負荷なのかどうか」「メモリがひっ迫していないか」といった基本的な問いに答えるために、チームごとに異なる実装を抱えてきた方も多いはずです。
GPU メトリクスサポートによる解決
Container Insights の拡張オブザーバビリティを有効化するだけで、GPU デバイスレベルのメトリクスを CloudWatch ネイティブで収集・可視化できるようになりました。独自の監視スタックを構築・維持する必要がなくなり、既存の CloudWatch エコシステムと同じ操作感で GPU の状態を管理できます。
ただし、Auto Repair（追加料金なし）とは異なり、本機能の利用には Container Insights 拡張オブザーバビリティの料金が発生します。 導入にあたってはコストの試算が必要です。詳細は後述のコストの考え方のセクションで解説します。
収集されるメトリクスの詳細
GPU メトリクスはすべて ECS/ContainerInsights 名前空間に収集され、コンテナレベル・タスクレベル・インスタンスレベルの 3 つの粒度で取得できます。
コンテナレベルのメトリクス
| メトリクス名 | 説明 | 単位 |
|---|---|---|
ContainerGPUUtilization |
コンテナに割り当てられた GPU の使用率 | Percent |
ContainerGPUMemoryUtilization |
コンテナに割り当てられた GPU のフレームバッファメモリ使用率 | Percent |
ContainerGPUMemoryTotal |
コンテナに割り当てられた GPU のフレームバッファメモリ総量 | Bytes |
ContainerGPUMemoryUsed |
コンテナに割り当てられた GPU のフレームバッファメモリ使用量 | Bytes |
ContainerGPUTemperature |
コンテナに割り当てられた GPU の温度 | Celsius |
ContainerGPUPowerDraw |
コンテナに割り当てられた GPU の消費電力 | Watts |
ContainerGPURestartAppXidCount |
コンテナに割り当てられた GPU で発生した、対処として RESTART_APP が対応する NVIDIA Xid エラーの件数 |
Count |
タスクレベルのメトリクス
| メトリクス名 | 説明 | 単位 |
|---|---|---|
TaskGPUUtilization |
タスクに割り当てられた GPU の使用率 | Percent |
TaskGPUMemoryUtilization |
タスクに割り当てられた GPU のフレームバッファメモリ使用率 | Percent |
TaskGPUMemoryTotal |
タスクに割り当てられた GPU のフレームバッファメモリ総量 | Bytes |
TaskGPUMemoryUsed |
タスクに割り当てられた GPU のフレームバッファメモリ使用量 | Bytes |
TaskGPUTemperature |
タスクに割り当てられた GPU の温度 | Celsius |
TaskGPUPowerDraw |
タスクに割り当てられた GPU の消費電力 | Watts |
TaskGPURestartAppXidCount |
タスクに割り当てられた GPU で発生した、対処として RESTART_APP が対応する NVIDIA Xid エラーの件数 |
Count |
インスタンスレベルのメトリクス
| メトリクス名 | 説明 | 単位 |
|---|---|---|
InstanceGPULimit |
インスタンス上で利用可能な GPU の総数 | Count |
InstanceGPUUsageTotal |
インスタンス上で実行中のタスクに割り当て済みの GPU 数 | Count |
GPU デバイスレベルの粒度とは
コンテナ・タスクレベルのメトリクスは、ディメンションに AcceleratedDevice を指定することで、GPU デバイス単位での絞り込みが可能です。
1 台の EC2 インスタンスに複数の GPU が搭載されている場合（例：p4d.24xlarge は 8 GPU 搭載）でも、各 GPU デバイスの状態を個別に把握できます。「8 枚中 1 枚の GPU が高温になっている」「特定の GPU だけ使用率が突出している」といった粒度での異常検知が可能になります。
XidCount メトリクスと GPU Auto Repair の関係
ContainerGPURestartAppXidCount および TaskGPURestartAppXidCount は、同月発表の GPU Auto Repair が監視対象とする NVIDIA Xid エラーのうち、RESTART_APP に分類されるものの発生件数を記録します。Auto Repair が障害を検知して自動修復するのに対し、このメトリクスはその発生傾向を時系列で可視化します。「いつ・どの GPU で・どの程度の頻度でエラーが発生しているか」が見えることで、自動修復との組み合わせがより意味を持ちます。
有効化の手順
前提条件
GPU メトリクスを利用するには、以下の 3 つが前提条件となります。
| 条件 | 内容 |
|---|---|
| ① キャパシティプロバイダー | ECS Managed Instances キャパシティプロバイダーを使用していること |
| ② EC2 インスタンスタイプ | NVIDIA GPU 搭載の EC2 インスタンスタイプで起動していること |
| ③ Container Insights | 拡張オブザーバビリティ（enhanced）が有効化されていること |
特に③は、通常の Container Insights（enabled）とは別の設定値である点に注意が必要です。enabled のままでは GPU メトリクスは収集されません。
Step 1：Container Insights 拡張オブザーバビリティを有効化する
新規クラスター向け（アカウント設定）
アカウント設定で有効化すると、以降に作成されるすべての新規クラスターに自動的に適用されます。
# 現在のユーザーにのみ適用する場合
aws ecs put-account-setting \
--name containerInsights \
--value enhanced
# アカウント全体（全ユーザー・ロール）に適用する場合
aws ecs put-account-setting \
--name containerInsights \
--value enhanced \
--principal-arn arn:aws:iam::<account-id>:root
既存クラスター向け
すでに稼働しているクラスターに対しては、update-cluster-settings コマンドで個別に適用します。
aws ecs update-cluster-settings \
--cluster <cluster-name> \
--settings name=containerInsights,value=enhanced
注意： 通常の Container Insights（
value=enabled）から拡張オブザーバビリティ（value=enhanced）へのアップグレードも、同じコマンドで対応できます。
Step 2：GPU 対応 EC2 インスタンスを Managed Instances 経由で起動する
ECS Managed Instances キャパシティプロバイダーを通じて、NVIDIA GPU 搭載の EC2 インスタンスタイプを起動します。
既存の ECS Managed Instances 環境で GPU 対応インスタンスタイプをすでに使用している場合は、Step 1 の設定変更のみで GPU メトリクスの収集が開始されます。
設定の確認
有効化後、CloudWatch コンソールの Container Insights から対象クラスターを選択することで、GPU メトリクスが収集されているかを確認できます。メトリクスは ECS/ContainerInsights 名前空間に格納されており、ContainerGPUUtilization などのメトリクス名で CloudWatch Metrics からも直接参照可能です。
CloudWatch 連携パターン
GPU メトリクスは ECS/ContainerInsights 名前空間の CloudWatch メトリクスとして収集されるため、CloudWatch の標準機能をそのまま活用できます。代表的な 3 つの活用パターンを紹介します。
パターン① CloudWatch Alarms による異常検知
GPU メトリクスに対して CloudWatch Alarms を設定することで、閾値超過を検知して通知やアクションにつなげることができます。
以下は ContainerGPUUtilization に対してアラームを設定する例です。閾値の値はワークロードの特性に応じて調整してください。
aws cloudwatch put-metric-alarm \
--alarm-name "ECS-GPU-HighUtilization" \
--namespace "ECS/ContainerInsights" \
--metric-name "ContainerGPUUtilization" \
--dimensions Name=ClusterName,Value=<cluster-name> \
--statistic Average \
--period 60 \
--evaluation-periods 3 \
--threshold <your-threshold> \
--comparison-operator GreaterThanThreshold \
--alarm-actions <sns-topic-arn>
温度メトリクス（ContainerGPUTemperature）や XID エラー数（ContainerGPURestartAppXidCount）に対しても同様に設定できます。XID エラーのアラームは、GPU Auto Repair が介入する前段階での早期検知として有効です。
パターン② CloudWatch Dashboard による可視化
CloudWatch コンソールからカスタムダッシュボードを作成し、GPU メトリクスをウィジェットとして追加することで、クラスター全体の GPU 状態を一画面で監視できます。
以下は CLI でダッシュボードを作成する際の構成例です（ウィジェットの配置や詳細設定はコンソールから GUI で行うことも可能です）。
aws cloudwatch put-dashboard \
--dashboard-name "ECS-GPU-Overview" \
--dashboard-body '{
"widgets": [
{
"type": "metric",
"x": 0, "y": 0, "width": 8, "height": 6,
"properties": {
"title": "GPU Utilization",
"metrics": [
[ "ECS/ContainerInsights", "ContainerGPUUtilization", "ClusterName", "<cluster-name>" ]
],
"period": 60,
"stat": "Average",
"view": "timeSeries",
"stacked": false,
"region": "<region>"
}
},
{
"type": "metric",
"x": 8, "y": 0, "width": 8, "height": 6,
"properties": {
"title": "GPU Memory Utilization",
"metrics": [
[ "ECS/ContainerInsights", "ContainerGPUMemoryUtilization", "ClusterName", "<cluster-name>" ]
],
"period": 60,
"stat": "Average",
"view": "timeSeries",
"stacked": false,
"region": "<region>"
}
},
{
"type": "metric",
"x": 16, "y": 0, "width": 8, "height": 6,
"properties": {
"title": "GPU Temperature",
"metrics": [
[ "ECS/ContainerInsights", "ContainerGPUTemperature", "ClusterName", "<cluster-name>" ]
],
"period": 60,
"stat": "Average",
"view": "timeSeries",
"stacked": false,
"region": "<region>"
}
}
]
}'
ダッシュボードに InstanceGPULimit と InstanceGPUUsageTotal を並べて表示することで、クラスター全体の GPU キャパシティに対する割り当て状況をひと目で把握することもできます。
パターン③ CloudWatch Logs Insights によるトラブルシューティング
Container Insights のメトリクスデータは CloudWatch Logs の /aws/ecs/containerinsights/<cluster-name>/performance ロググループにも JSON 形式で保存されます。Logs Insights を使うことで、メトリクスの時系列変化とログの内容を組み合わせたトラブルシューティングが可能です。
以下は GPU 使用率の高いコンテナを特定するクエリの例です。
fields @timestamp, ContainerName, ContainerGPUUtilization
| filter Type = "Container"
| filter ispresent(ContainerGPUUtilization)
| sort ContainerGPUUtilization desc
| limit 10
XID エラーが発生したタイミングを絞り込む場合は、以下のクエリが使えます。
fields @timestamp, ContainerName, ContainerGPURestartAppXidCount
| filter Type = "Container"
| filter ContainerGPURestartAppXidCount > 0
| sort @timestamp desc
コストの考え方
GPU メトリクスサポートを利用するには Container Insights の拡張オブザーバビリティを有効化する必要があり、これには追加料金が発生します。同月発表の GPU Auto Repair が追加料金なしで利用できるのとは対照的な点です。導入前にコスト構造を把握しておくことが重要です。
料金体系の仕組み
ECS 向け Container Insights 拡張オブザーバビリティは、メトリクス数ベースで月額・時間単位の日割りで課金されます。メトリクスのストレージとログの取り込みを単一の料金体系に統合しており、ログのストレージは別途課金されます。
課金対象となるメトリクス数は、クラスターの構成（クラスター数・サービス数・タスク数・コンテナ数）によって変動します。構成の参考として、1クラスターあたり 29 メトリクス、1サービスあたり 31 メトリクス、1タスク定義あたり 26 メトリクス、1タスクあたり 26 メトリクス、1コンテナあたり 26 メトリクスが報告されます。GPU メトリクスはこれらに追加される形で収集されるため、GPU ワークロードのタスク・コンテナ数が多いほどコストへの影響が大きくなります。
具体的な単価は変更される可能性があるため、最新の料金は Amazon CloudWatch 料金ページ を必ずご確認ください。
費用対効果の考え方
監視コストだけを見てしまいがちですが、以下の観点で費用対効果を整理すると判断しやすくなります。
| 観点 | 内容 |
|---|---|
| 削減できるコスト | 自前の GPU 監視基盤の構築・運用コスト（ツール・人的工数） |
| 防げるコスト | GPU 障害やリソース過剰プロビジョニングによる無駄なインスタンス稼働費用 |
| 発生するコスト | Container Insights 拡張オブザーバビリティの料金 ＋ ログストレージ料金 |
高価な GPU インスタンスを複数台常時稼働させている環境では、数%の稼働効率改善でも監視コストを上回る節約になるケースがあります。一方、GPU インスタンスの台数が少ない小規模環境では、コストメリットが出にくい場合もあります。
コスト最適化のヒント
コスト管理のため、CloudWatch はログデータからすべての可能なメトリクスを自動的に作成するわけではありません。追加のメトリクスや詳細な粒度は、CloudWatch Logs Insights を使って生のパフォーマンスログイベントを分析することで確認できます。
まず、最初から全クラスターに有効化するのではなく、1クラスターに絞って試し、1ヶ月分のコストと得られるデータを見てから展開範囲を広げるかどうかを判断する方がリスクは低くなります。
実際に CloudWatch Alarms やダッシュボードで使うメトリクスを意識的に絞り込むことも重要です。収集されているメトリクスのうち本当に必要なものだけを把握しておくとコスト管理がしやすくなります。
ログについては /aws/ecs/containerinsights/ 配下のロググループの保持期間を確認しておくと安心です。デフォルトのまま放置するとストレージコストが積み上がります。月次の追跡には、Cost Explorer で ContainerInsights に関連する使用タイプをフィルタリングする方法が手軽です。
まとめ
Container Insights の拡張オブザーバビリティに GPU メトリクスが加わり、ECS Managed Instances 上の AI/ML ワークロード監視の選択肢が一つ増えました。これまで自前で監視基盤を構築・運用していた手間が、設定変更だけで解消できる点は素直に便利です。
特に注目したいのは、収集されるメトリクスの充実度です。使用率・メモリ・温度といった基本的なものに加え、消費電力（PowerDraw）や NVIDIA Xid エラー数（RestartAppXidCount）まで取得できます。温度や Xid エラーは問題の予兆として現れやすく、CloudWatch Alarms と組み合わせれば、障害が顕在化する前に気づける体制が作れます。
一方で、追加コストが発生する点は Auto Repair との大きな違いです。まず 1クラスターに限定して有効化し、1ヶ月コストを計測してから全体展開を考えるのが現実的です。
GPU Auto Repair との組み合わせについて
同月発表の GPU Auto Repair と組み合わせることで、「GPU の異常を可視化しながら、ハードウェア障害は自動修復する」という GPU 運用基盤を構築できます。Auto Repair は追加料金なしで利用できるため、まずそちらを有効化した上で、GPU メトリクス監視の導入コストを検討するという進め方もあります。