ひとことで言うと
コンテナオーケストレーションサービスで、起動タイプがFargateかEC2かでGenAIでの適性が真逆になります。 Fargateを選べばGPUは使えず、EC2起動タイプを選べばGPUインスタンス（p3・p4d・p5・g4dn・g5・g6等）にコンテナを配置できます。
要するに、同じ建物に2つの入居プランがある賃貸です。「家具付き（Fargate）」はGPUという名の重い電源工事ができません。「持ち込み可（EC2起動タイプ）」ならGPU搭載インスタンスを自分で借りて、コンテナをそこに正確にピン留めできます。
GenAIで自前のモデルをコンテナ化して動かす話が出たら、まずこの入居プランのどちらかを確認するのが試験の型です。
なぜ生まれたか
Bedrockで済まない場面、つまり自社でファインチューニングした重みをオープンソースの推論サーバ（例: vLLM系のコンテナ）に載せて動かしたいという要求は、GenAI案件でも現実に出てきます。この時に必要なのは「コンテナをGPUインスタンスに確実に配置し、GPUをコンテナへ正しく割り当てる」仕組みです。
ECSのEC2起動タイプは、GPU対応のインスタンスタイプでクラスタを構成し、ECSがGPU数をタスク定義レベルで管理・配置します。SageMaker AIのように学習ジョブやエンドポイントのライフサイクル管理まではしませんが、任意の推論サーバコンテナをそのまま持ち込める自由度が、SageMaker AIやBedrockでは代替できない場面を作っています。
| 起動タイプ | GPU | 向いている場面 |
|---|---|---|
| Fargate | 不可（gpuパラメータ無効） | サーバ管理不要・GPU不要の常駐処理 |
| EC2 | 可（p3/p4d/p5/g4dn/g5/g6等） | 自前モデルのGPU推論・学習コンテナ |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 自前OSSモデルのGPU推論 | p3/p4d/p5/g4dn/g5/g6等のGPUインスタンスでクラスタを構成し、コンテナにGPUを割り当てる | D2 |
| 複雑なMCPサーバのホスティング | 状態を持つツールサーバをタスクとして常駐させる | D2 |
| GPU共有によるコスト最適化 | NVIDIA_VISIBLE_DEVICESを使い、複数コンテナで同一GPUを共有する | D4 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 「自前のモデルをコンテナでGPU推論させたい」 | GPUが要件 → ECS（EC2起動タイプ）。GPU対応インスタンス・ECS GPU最適化AMI・ECS_ENABLE_GPU_SUPPORTが揃って初めて成立 | ECS（Fargate起動タイプ）（gpuパラメータが無効） |
| Windowsコンテナで同じ要件 | GPUはLinuxコンテナのみ対応 | Windowsコンテナ＋GPUの組み合わせ（非対応） |
| 複数コンテナで高価なGPUインスタンスを使い切りたい | 個別のGPU予約を外し、共有ランタイム設定で分け合う → GPU共有構成 | タスクごとに専有GPUを割り当て続ける（コスト効率が悪い） |
| 特定のGPUインスタンスタイプにタスクを固定したい | インスタンス属性を使う → 配置制約（placement constraints） | タスク定義のCPU/メモリだけで暗黙にインスタンスが決まると考える |
GPUインスタンスタイプはECS GPU最適化AMIとセットで機能します。P2インスタンスは新しいAMIバージョンでサポートが切られており、使うには旧バージョンのAMIに固定するか自前でAMIを作る必要があります。「新しいAMIで古いGPUインスタンスタイプを使う」組み合わせは静かに失敗しうる、という実務の落とし穴が試験のシナリオにも反映されえます。
実務でどう使うか
ECS_ENABLE_GPU_SUPPORTをエージェント設定で有効化しないとGPUを認識しません。 ECS GPU最適化AMIを使っていても、この設定を忘れるとタスクが配置されませんNVIDIA_VISIBLE_DEVICES環境変数はECSが自動設定しますが、それ以外のNVIDIA関連の環境変数はコンテナイメージ側で用意する必要があります。 ベースイメージにNVIDIA/CUDA公式イメージを使わない場合はNVIDIA_DRIVER_CAPABILITIESを明示的に設定します- タスク配置制約（
attribute:ecs.instance-type）で特定のGPUインスタンスタイプにタスクを固定できます。 混在クラスタ（GPU・非GPUが同居）でGPUタスクだけを正しいノードに送るのに使います - GPUを共有する場合はタスク定義からGPUリソース要求を外し、インスタンス側のDockerランタイム設定でnvidiaをデフォルトにするという手順を踏みます。素朴にGPUリソースを指定したままだと共有できず専有になります
| 設定漏れ | 起きること |
|---|---|
ECS_ENABLE_GPU_SUPPORT未設定 | GPUインスタンスでもタスクが配置されない |
NVIDIA_DRIVER_CAPABILITIES未設定（非CUDA基盤イメージ） | コンテナがGPUを認識しない |
| 配置制約なしの混在クラスタ | GPUタスクが非GPUノードに送られうる |
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| AWS Fargate（ECSの起動タイプ） | GPUが要件に出た瞬間、選択肢から外れるのはFargate側。ECS自体は同じサービスで、起動タイプの選択が分かれ目 |
| Amazon EKS | どちらもGPUインスタンスでコンテナを動かせる。Kubernetesのエコシステム（Helm・Kubeflow等）が要る／マルチクラウド前提ならEKS、AWSネイティブなオーケストレーションで十分ならECS |
| SageMaker AIエンドポイント | SageMaker AIはモデルのライフサイクル管理（デプロイ・オートスケール・A/Bテスト）まで面倒を見る。ECSはコンテナの配置と実行に徹し、その上のML運用機能は自分で組む |
| Amazon Bedrock | Bedrockはモデルもインフラも借りる。ECSは自前のモデル・自前のコンテナを動かす場所で、両者は競合ではなく「借りるか建てるか」の対比 |
想起チェック
Q1. 自前のOSSモデルをコンテナでGPU推論させたいとき、ECSのどの起動タイプを選ぶべきか？
EC2起動タイプです。Fargate起動タイプはタスク定義パラメータのgpuが無効なため、GPUを割り当てられません。
Q2. GPUインスタンスでタスクを動かしても推論が失敗する。まず確認すべき設定は？
ECS_ENABLE_GPU_SUPPORTがエージェント設定で有効になっているか、そしてECS GPU最適化AMIを使っているかです。GPUインスタンスを使うだけではECSはGPUを認識しません。