Fargate

Fargate とは

AWS Fargate は、ECS および EKS のコンテナをサーバーレスで実行するコンピューティングエンジンである。EC2 インスタンスのプロビジョニング、パッチ適用、スケーリングが不要で、コンテナの CPU とメモリを指定するだけでタスクが実行される。

サーバーレスの実体は、タスク 1 つごとに独立した実行環境が割り当てられる点にある。AWS のドキュメントでは、各 Fargate タスクは独自の分離境界を持ち、カーネル・CPU・メモリ・ENI を他のタスクと共有しないと明記されている。EC2 起動タイプのように 1 台のインスタンスへ複数のタスクを詰め込む構造ではないため、詰め込み効率を自分で最適化する余地は無い代わりに、テナント分離をインフラ側が担保する。

以下は ECS on Fargate を前提に書く。EKS on Fargate では単位がタスクではなく Pod になり、DaemonSet が動かない、EBS をマウントできないといった Kubernetes 固有の制約が別に加わる。

EC2 起動タイプとの比較

判断の軸は「EC2 インスタンスという単位を自分で持つかどうか」である。持たないと決めた時点で、OS のカスタマイズと詰め込み効率を手放す代わりに、キャパシティ管理から降りられる。

観点	Fargate	EC2 起動タイプ
インフラ管理	不要	EC2 の管理が必要
スケーリング	タスク単位で自動	Auto Scaling Group の設定
コスト	要求した vCPU 秒 + GB 秒	インスタンスの稼働時間 (タスクが載っていない空きも課金)
GPU	非対応	対応
カスタマイズ	制限あり	OS レベルで自由
起動速度	数十秒	インスタンス起動 + タスク配置

Fargate は運用負荷が低い代わりに、同等スペックの EC2 より単価が高い。常時稼働で高負荷なワークロードは EC2 起動タイプ + Savings Plans の方がコスト効率が良い場合がある。

Lambda との使い分け

分岐点は実行時間の上限とコールドスタートの許容度である。どちらも使った分だけの課金という点は似ているが、Lambda の 15 分は引き上げ申請のできない硬い天井であり、ここを越える処理は設計を分割するか Fargate へ移すかの二択になる。

観点	Lambda	Fargate
実行時間	最大 15 分	無制限
メモリ	最大 10,240 MB	最大 244 GB (32 vCPU 構成・Linux・2026 年 8 月時点)
コンテナイメージ	10 GB まで	エフェメラルストレージの範囲内 (既定 20 GiB)
同時実行	1,000 (リージョン既定・引き上げ申請可)	タスク数で制御
コールドスタート	あり (100ms〜数秒)	タスク起動 (数十秒)
課金	リクエスト数 + 実行時間 × メモリ	vCPU 秒 + GB 秒 (1 分未満は 1 分として計算)
適用場面	短時間の API、イベント処理	長時間バッチ、常駐サービス

15 分以内で完了するイベント駆動の処理は Lambda、それ以上の長時間処理や常駐サービスは Fargate が適する。

Fargate Spot

Fargate Spot は、AWS の余剰キャパシティを使って通常価格より最大 70 % 割引でタスクを実行する (AWS 公表値・2026 年 8 月時点)。中断される可能性があるため、バッチ処理やキューワーカーなど中断耐性のあるワークロードに適する。

中断の手順は決まっている。キャパシティが回収される 2 分前に、EventBridge へタスク状態変更イベントが送られ、同時に実行中のタスクへ SIGTERM が届く。この 2 分で処理を切り上げて終了するのがアプリケーション側の責務であり、SIGTERM を無視すれば強制終了される。コンテナ定義の stopTimeout は既定 30 秒しかないので、後片付けに時間がかかる処理では 120 秒以下の範囲で延ばしておく。

Spot 特有の失敗の形も押さえておきたい。需要が高い時期は Fargate Spot のキャパシティ自体が枯れ、タスクの起動が遅れる。このとき Fargate は通常のキャパシティで代替せず、サービススケジューラーが空きが出るまで起動を再試行し続ける。タスクを 1 つしか持たないサービスは、その間まるごと停止したままになる。

ECS on Fargate の構成

構成の見た目は EC2 起動タイプとほとんど変わらない。違いはタスクが載るインスタンスが図に現れないことで、キャパシティの過不足をどこにも描かなくて済む。

[ALB] → [ECS Service (Fargate)]
              ├── Task A (vCPU: 0.5, Memory: 1GB)
              ├── Task B (vCPU: 0.5, Memory: 1GB)
              └── Task C (vCPU: 0.5, Memory: 1GB)

ECS Service がタスクの数を維持し、ALB がトラフィックを分散する。タスク定義で CPU、メモリ、コンテナイメージ、環境変数を指定する。

よくある落とし穴

• ENI の制限: Fargate タスクは 1 つの ENI を使用する。VPC のサブネットに十分な IP アドレスが必要
• イメージプルの時間: 大きなコンテナイメージはタスク起動が遅くなる。ECR にイメージを置き、マルチステージビルドでイメージを軽量化する
• ログの設定漏れ: awslogs ログドライバーを設定しないと、コンテナのログが消失する
• エフェメラルストレージの既定値: プラットフォームバージョン 1.4.0 以降のタスクには既定で 20 GiB が付き、タスク定義の ephemeralStorage で最大 200 GiB まで拡張できる。この領域にはコンテナイメージの圧縮形と展開形の両方が置かれるため、アプリケーションが使える実容量は 20 GiB からイメージ分を引いた残りになる。既定を超えた分だけが課金対象で、20 GiB までは追加料金が発生しない
• 短命タスクの課金: 秒単位の課金だが 1 分未満は 1 分として計算される (Windows コンテナは 5 分)。数秒で終わるタスクを大量に起動する設計は、処理時間あたりの単価が跳ね上がる

Fargate を選ぶかどうかは「EC2 インスタンスの面倒を見る人員をそこに置けるか」でほぼ決まる。置けない、あるいは他に回したいなら Fargate が既定の選択になる。常時フル稼働に近いワークロードだけは、EC2 起動タイプ + Savings Plans と単価を並べて比べる価値がある。