TL Terralien
Containers

AWS Fargate

サーバーレスのコンテナ実行環境。GenAIの文脈では「状態を持つがGPUは要らない」処理（複雑なMCPサーバ、エージェントのオーケストレーション層）の置き場所であり、GPU推論の受け皿にはなりません。

  • B｜実装まわり
  • D2 実装と統合

最終更新: 2026年8月18日

ひとことで言うと

サーバーもクラスタも管理せずコンテナを動かす実行環境です。GenAIの文脈での役どころは一つで、Lambdaでは収まらない「状態を持つ・長時間動く」処理を、GPUなしで動かす場所です。

要するに、家具付き賃貸です。建物の管理（サーバー・クラスタ）は不要ですが、間取り（CPU・メモリ）は自分で決めます。ただし電源容量（GPU）の増設だけはできません。タスク定義パラメータのgpuはFargateでは無効な項目として明記されています。
GenAIの重い計算（モデル推論そのもの）をここでやろうとすると、この一点で詰まります。

なぜ生まれたか

GenAIアプリのバックエンドには、Lambdaの15分・6MBという枠に収まらない処理が出てきます。複雑なMCPサーバ（複数のツールを持ち、状態やコネクションを長時間保持する）、常時稼働するエージェントのオーケストレーション層、大きめのペイロードを扱うAPIサーバなどです。AIP-C01のスキル文でも「Lambdaでステートレスなツールサーバ、ECSで複雑なMCPサーバ」という対比で名指しされています。

Fargateはこの「サーバは要らないが、Lambdaの制約からは出たい」という要求に対して、ECS/EKSのコンテナオーケストレーションはそのままに、EC2の管理だけを外すという形で応えました。

Lambdaでは収まらない要件Fargateが埋める形
15分を超える常駐処理サーバ管理不要のまま常時起動できるタスク
6MBを超えるペイロード・複雑な状態コンテナとして自由に実装できる
GPUは不要・CPU/メモリだけ増やしたいEC2の管理だけを外した実行環境

何に使うか

用途使い方関連ドメイン
複雑なMCPサーバのホスティング状態や長時間コネクションを持つツールサーバをECS on Fargateで常時稼働させるD2
エージェントオーケストレーション層Bedrock APIを呼び出す常駐アプリ（Web UI・APIサーバ）をコンテナで動かすD2
GenAI APIのラッパー・ゲートウェイ認証・レート制限・ログ整形などをコンテナ側で行い、Bedrockへ中継するD2・D3

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
「サーバ管理を避けつつ自前のOSSモデルをGPUでホストしたい」GPU推論が要件 → ECS/EKS on EC2（GPUインスタンス）Fargate（gpuパラメータが使えず構造的に不成立）
複雑な状態を持つMCPサーバをどこに置くかステートレスで軽いならLambda、状態を持ち常駐が要るなら → ECS/EKS on FargateすべてのMCPサーバを一律Lambdaに寄せる案
サーバ管理を避けつつコンテナでBedrockを呼ぶAPIを常駐させたいGPU不要・サーバ管理を避けたい → FargateEC2インスタンスを自分でプロビジョニングする案（過剰）

Fargateのタスク定義パラメータにはgpuが存在しません。ECSのタスク定義パラメータのうちgpu・privileged・ipcModeなどはFargateで無効なパラメータとして公式に明記されています。GPU推論を要件に含むシナリオでFargateを選ぶ選択肢は、この一点だけで消せます。

実務でどう使うか

  • CPU/メモリはあらかじめ決められた組み合わせからしか選べません。 最大でも32 vCPU・244GBまでで、EC2のように任意のインスタンスタイプを選ぶ自由度はありません
  • awsvpcネットワークモード固定。 各タスクが専用のENIを持つため、VPC設計（サブネット・セキュリティグループ）を最初から詰めておく必要があります
  • Fargate SpotでLLMアプリのバッチ処理・非同期ワーカーをコスト最適化できます。 中断耐性のある処理（再実行できるツール呼び出しのワーカー等）に向きます
  • Bedrock呼び出し自体はFargate側のコンテナがAPI経由で行うだけ。 モデルの計算資源はBedrock側が持つため、FargateにGPUが無いこと自体はBedrock呼び出しのボトルネックにはなりません。GPUが要るのは自前でOSSモデルを動かす場合だけです
Fargateで無効なタスク定義パラメータGenAI設計での意味
gpu自前モデルのGPU推論はここでは組めない
privileged / ipcModeカーネルレベルの細かい制御も対象外
最大32 vCPU・244GBそれを超える大規模並列推論はEC2起動タイプへ

取り違えやすいもの

迷う相手切り分けの一言
AWS Lambda15分・6MBの制約を超える、または常時起動・長時間コネクションが要るならFargate側
ECS/EKS on EC2GPU推論・カーネルレベルの制御が要るならEC2起動タイプ。サーバ管理を避けたいだけならFargate
Amazon BedrockBedrockはFM推論自体を借りる。Fargateはその周りのアプリ（呼び出し元・エージェント基盤）を動かす場所であって推論基盤ではない
SageMaker AIエンドポイント自前モデルの推論エンドポイントとしてGPUが要るならSageMaker AI。Fargateは推論エンドポイントの選択肢に入らない

想起チェック

Q1. 「サーバ管理をせずに自前のOSSモデルをGPUで推論したい」というシナリオでFargateが正解にならない理由は？

Fargateのタスク定義パラメータにgpuが存在せず、GPUリソースを割り当てられないためです。GPUが要る場合はECS/EKSのEC2起動タイプかSageMaker AIを選びます。

Q2. LambdaとFargateでMCPサーバを分ける基準は？

**ステートレスで短時間・軽量ならLambda、状態を持ち常駐・長時間コネクションが要るならFargate（ECS/EKS）**です。AIP-C01のスキル文でも同じ対比で明記されています。

出典（AWS公式）