はじめに
2026 年 4 月 22 日、AWS は Amazon ECS の Managed Instances に対して NVIDIA GPU ヘルスモニタリングおよび自動修復機能（GPU Auto Repair）の一般提供を発表しました。
この機能は、NVIDIA DCGM（Data Center GPU Manager）を使って GPU ハードウェアの健全性を継続的に監視し、重大な障害を検知した際にインスタンスを自動的に置き換えるものです。追加料金なし、設定不要でデフォルト有効、全 AWS コマーシャルリージョンで利用できます。
本記事では「これまで何が課題だったのか」「自動修復がどういう仕組みで動くのか」「ワークロードの種類によって設定をどう使い分けるべきか」「導入前に押さえておきたい注意点は何か」を中心に解説します。ECS 上で GenAI 推論やモデルサービングなどの GPU ワークロードを本番運用しているエンジニアや SRE の方はぜひ読んでみてください。
何が変わったのか
ECS 上で GPU ワークロードを本番運用したことがある方なら、GPU 障害への対応がいかに厄介かをご存知かと思います。
| 項目 | Before | After |
|---|---|---|
| GPU 障害の検知 | 自前で監視ロジックを実装する必要あり | NVIDIA DCGM によるプラットフォームレベルの自動監視 |
| 障害インスタンスの対応 | 手動またはカスタム自動化でインスタンスを置き換え | 自動で DRAINING → 新インスタンス起動 → 旧インスタンス終了 |
| 状態の可視化 | 独自の監視基盤が必要 | DescribeContainerInstances API で GPU 健全性を確認可能 |
| 障害通知 | 自前で実装 | Amazon EventBridge のイベントで受信可能 |
| 追加コスト | — | なし |
従来の課題
GPU ハードウェアの障害は、CPU インスタンスの障害とは性質が大きく異なります。CPU インスタンスであれば EC2 のヘルスチェックや Auto Scaling が自動的に検知・置き換えを行ってくれますが、GPU は XID エラーと呼ばれる独自のエラーコードで障害を報告するため、OS や EC2 レイヤーのヘルスチェックをすり抜けてしまいます。「インスタンスは正常だが GPU は壊れている」という状態が発生し、推論リクエストはエラーを返し続けるにもかかわらずプラットフォームは異常を検知できない、というダウンタイムの長期化につながります。
ECS Managed Instances では、こうした GPU ハードウェア障害の検知と対応をユーザーが独自に実装する必要がありました。NVIDIA DCGM を自前でインストールして XID エラーを監視するスクリプトを書き、障害を検知したらインスタンスをカスタムの自動化で置き換えるという一連のフローを、チームごとに構築・運用してきた方も多いはずです。深夜・休日の障害対応が発生するリスクも常につきまとい、SRE やインフラチームの運用負荷は決して小さくありませんでした。
GPU Auto Repair による解決
これらの課題をプラットフォームが引き受けるのが GPU Auto Repair です。DCGM による XID エラーの監視は ECS が担うため、自前の監視スクリプトは不要になります。重大な障害が検知されると DRAINING → 新インスタンス起動 → 旧インスタンス終了という流れで自動的に置き換えが完了し、深夜・休日を問わず人手を介さずに復旧できます。DescribeContainerInstances API での健全性確認や EventBridge を通じた通知連携も標準で備わっており、障害状況の把握や既存のアラートパイプラインへの組み込みも容易です。
GPU Auto Repair の仕組み
NVIDIA DCGM とは
GPU Auto Repair の核となるのが、NVIDIA DCGM（Data Center GPU Manager）です。DCGM は NVIDIA が提供するデータセンター向けの GPU 管理・監視フレームワークで、GPU 固有の XID エラーコードを継続的に監視します。ECS はこの DCGM を Managed Instances に組み込み、GPU ヘルスモニタリングをプラットフォームの標準機能として提供しています。
自動修復フロー
DCGM が重大な GPU 障害を検知すると、ECS は対象インスタンスを障害状態（Impaired）としてマークし、以下の start-before-stop ワークフローで自動修復を実行します。
重要なのは、先に新インスタンスを起動してから既存タスクを停止する という順序です。これにより、ワークロードの空白時間を最小化した状態で置き換えが完了します。
レート制限
大規模なクラスターで複数の GPU 障害が同時発生した場合、一斉に置き換えが走るとクラスター全体に影響が及ぶリスクがあります。ECS はこうした連鎖的な置き換えを防ぐため、以下のレート制限を設けています。
| 条件 | 同時に DRAINING にできる上限 |
|---|---|
| Capacity Provider 内のインスタンスが 9 台以上 | 全体の最大 20% |
| Capacity Provider 内のインスタンスが 9 台未満 | 最大 1 台 |
監視対象の XID エラーコード
ECS が監視する XID エラーコードは以下の 18 種類です。これらのいずれかが検知されると、インスタンスが Impaired としてマークされ、自動修復がトリガーされます。
| XID | 説明 |
|---|---|
| 46 | GPU stopped processing |
| 48 | Double Bit ECC Error |
| 54 | Auxiliary power connector not connected |
| 62 | Internal micro-controller halt |
| 64 | GPU memory remapping failure |
| 74 | NVLink Error |
| 79 | GPU has fallen off the bus |
| 95 | Uncontained memory error |
| 109 | Context switch timeout |
| 110 | GPU disappeared from the bus |
| 136 | GPU memory page retirement limit exceeded |
| 140 | Unrecoverable ECC Error |
| 142 | GPU memory page retired due to uncorrectable error |
| 143 | GPU memory page retired due to correctable error threshold |
| 151 | GPU to CPU interconnect error |
| 155 | GPU NVLink flit CRC error |
| 156 | GPU NVLink lane error |
| 158 | GPU InfoROM corrupted |
各 XID エラーコードの詳細については NVIDIA 公式ドキュメント（XID Errors） を参照してください。
監視と設定
追加のインストールや設定は不要ですが、GPU 健全性の確認方法や障害通知の受け取り方、自動修復を無効化したい場合の手順は把握しておくと運用の幅が広がります。
GPU 健全性の確認
DescribeContainerInstances API を使うことで、インスタンスごとの GPU 健全性状態を確認できます。healthStatus フィールドはデフォルトではレスポンスに含まれないため、--include CONTAINER_INSTANCE_HEALTH オプションを明示的に指定する必要があります。
aws ecs describe-container-instances \
--cluster <cluster-name> \
--container-instances <container-instance-id> \
--include CONTAINER_INSTANCE_HEALTH
レスポンスの healthStatus フィールドに GPU の健全性情報が含まれます。overallStatus が IMPAIRED になっている場合、そのインスタンスで GPU 障害が検知されています。詳細は details 内の type: ACCELERATED_COMPUTE の項目を確認してください。
EventBridge による障害通知
GPU 障害が発生すると、Amazon ECS はコンテナインスタンスのヘルス変化イベントを Amazon EventBridge に発火します。これを利用することで、Slack や PagerDuty など既存のアラートパイプラインと連携した通知を受け取れます。イベントの詳細な設定については、Amazon ECS コンテナインスタンスのヘルス変化イベント を参照してください。
自動修復の無効化・有効化
自動修復を無効にしたい場合は、Capacity Provider の autoRepairConfiguration で actionsStatus を DISABLED に設定します。
無効化
aws ecs update-capacity-provider \
--name <capacity-provider-name> \
--managed-instances-provider '{
"infrastructureRoleArn": "arn:aws:iam::<account-id>:role/ecsInfrastructureRole",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::<account-id>:instance-profile/ecsInstanceRole",
"networkConfiguration": {
"subnets": ["<subnet-id>"],
"securityGroups": ["<security-group-id>"]
}
},
"autoRepairConfiguration": {
"actionsStatus": "DISABLED"
}
}'
有効化
aws ecs update-capacity-provider \
--name <capacity-provider-name> \
--managed-instances-provider '{
"infrastructureRoleArn": "arn:aws:iam::<account-id>:role/ecsInfrastructureRole",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::<account-id>:instance-profile/ecsInstanceRole",
"networkConfiguration": {
"subnets": ["<subnet-id>"],
"securityGroups": ["<security-group-id>"]
}
},
"autoRepairConfiguration": {
"actionsStatus": "ENABLED"
}
}'
設定の確認
aws ecs describe-capacity-providers \
--capacity-providers <capacity-provider-name>
注意： 自動修復を無効化すると、GPU ヘルスモニタリング自体は継続されますが、障害インスタンスの自動置き換えは行われなくなります。また、Amazon ECS Managed Daemons の自動修復も同時に無効化される点に注意が必要です。
ワークロード別の活用方針
ワークロードの種類によって推奨設定が異なります。
| ワークロード | 推奨設定 | 理由 |
|---|---|---|
| GenAI 推論・モデルサービング | 自動修復 ON（デフォルトのまま） | ステートレスなため、インスタンスが置き換わっても影響が最小限 |
| 長時間モデルトレーニング | 自動修復 OFF ＋ チェックポイント管理と併用 | DRAINING によるタスク停止でジョブが中断されるリスクがある |
GenAI 推論・モデルサービング（自動修復 ON 推奨）
vLLM や TGI などを使った推論 API は、基本的にステートレスなワークロードです。リクエストを処理するたびに状態が完結するため、GPU 障害が発生してインスタンスが置き換わっても、影響はその障害インスタンスで処理中だったリクエストに限定されます。自動修復によって迅速にインスタンスが置き換えられることで、サービス全体のダウンタイムを最小化できます。
追加の設定変更は不要です。デフォルトのまま運用しつつ、EventBridge を使った障害通知を整備しておくことで、GPU 障害の発生状況を継続的に把握できます。
長時間モデルトレーニング（自動修復 OFF 推奨）
数時間・数日単位で実行されるモデルトレーニングジョブは、ステートフルなワークロードです。自動修復が有効な状態で GPU 障害が発生すると、ECS はインスタンスを DRAINING 状態に移行してタスクをグレースフルに停止します。チェックポイントが設定されていない場合、それまでのトレーニングの進捗がすべて失われることになります。
このケースでは自動修復を無効化した上で、チェックポイントを定期的に Amazon S3 などに保存しておき、障害発生時にそこから再開できるようにしておくことをお勧めします。あわせて EventBridge で GPU 障害イベントを受け取り、チェックポイントからジョブを自動再起動する仕組みを実装することで、人手を介さない復旧が可能です。なお、自動修復を無効化しても GPU ヘルスモニタリング自体は継続されるため、EventBridge 経由で障害イベントは引き続き受け取れます。
まとめ
個人的には、GPU 障害の検知から復旧までをプラットフォームが自動で完結させてくれる点がこの機能の一番の価値だと感じています。GPU ワークロードの本番運用では、XID エラーへの対応は CPU インスタンスの障害対応とは別の専門知識が必要であり、これまでチームごとに監視ロジックを構築してきた負担は決して小さくありませんでした。そこへの直接的な回答がこの機能です。
ただし、すべてのワークロードで自動修復を有効にすれば良いわけではありません。長時間のトレーニングジョブではチェックポイント管理との組み合わせが前提になりますし、--include CONTAINER_INSTANCE_HEALTH オプションを使った GPU 健全性の定期的な確認や EventBridge による通知整備も、安定した運用のために押さえておきたいポイントです。
追加料金はなく、既存の ECS Managed Instances 環境であれば設定変更なしで今日から使えます。ECS 上で GPU ワークロードを運用しているチームは、まず DescribeContainerInstances --include CONTAINER_INSTANCE_HEALTH で現在の GPU 健全性を確認するところから始めてみてください。