Fargate一択だと思っていた私がECS on EC2の重要性に気づいた話

AI事業本部/西日本開発チームの片桐です。
私は、 ECS を利用する際に、起動タイプはサーバーレスの Fargate 一択だと、以前は思い込んでました。
今回はそんな私が ECS on EC2 の重要性について気づいたので、まとめて紹介させていただきます。

この記事について

[対象読者]

• ECS をこれから触る方
• ECS の起動タイプについて確認したい方

ECS とは

AWS が提供するコンテナオーケストレーションサービスです。
Docker コンテナのデプロイ、管理、スケーリングを行います。

ECS の起動タイプ

ECS にはコンテナを動かすためのリソースの選択肢(起動タイプ)として2つあります。

ECS の3層構造

ECS の概念についても簡単に触れておきます。

• クラスター
  サービスやタスクをまとめる箱。
  複数の Web アプリケーションやバッチ処理などを一つのクラスターで管理します。

• サービス
  起動するタスク(コンテナ)の維持や、スケーリング、ネットワーク設定や、ロードバランサーとの紐づけを行います。

• タスク定義
  コンテナの設計図。
  どの Docker イメージ( ECR に保存されたコンテナイメージ)をどのスペック( CPU / メモリ)で起動するか、環境変数やポートマッピング、ログ設定などを行います。

ECS の基本概念を押さえたところで、私が Fargate を選び続けていた理由を振り返ります。

Fargate を選び続けていた理由

ここからは ECS 初学者である私が考えていた、 Fargate のメリットです。

設定箇所が少ない

Docker イメージの作成とタスク定義までが私たちユーザーの設定範囲となり、インフラ層(ホストマシン)の設定は Fargate を選択することで、最適化されます。

ECS on EC2 のように、インスタンスタイプの選択やメモリの設定など、設定不要です。

運用管理が不要

ECS on EC2 で起動した場合に必要な以下の作業がすべて不要です。

• OS アップデート
• セキュリティパッチの適用
• Docker ランタイムの更新
• ECS エージェントの更新

実際にハマった体験

当初は ECS on EC2 でセットアップしようとしていました。
その際に、理解が乏しかったため下記のような事象が発生しました。

1. サービス設定時に EC2 のインスタンスを t4g.micro (メモリ 約1GB)で設定
2. タスク定義時に、コンテナ実行に必要なのは 3GB だったため、 3GB でタスクを設定
3. ホストマシンのスペックを超えたタスクを起動させる指示が走るため、いくら待ってもタスクが起動しない

ここで、 Fargate に切り替えたら、すぐに起動できたため、ホストマシンの設定が不要な Fargate が好きになり、一番の最適解だと思いました。

Fargate が適さない場合

しかし、 Fargate にもデメリットがあることに気づいてしまいました。

GPU 利用不可

GPU が利用できないため、下記のようなタスクを実行させる場合は処理が遅くなったり、動作しない場合があります。

• 動画の加工処理
• 画像処理
• 機械学習関連

エフェメラルストレージ 最大200GB

ECS 自体ステートレスなサービスのため、あまりコンテナでデータを保存することは少ないと思いますが、場合によっては影響する可能性が出てきます。

タスクの CPU / メモリ に対しての課金

長期的かつ大規模な運用になってくると Fargate ではコストがEC2よりも高くなる可能性があります。

Fargate は Compute Savings Plans の適用や、 Fargate Spot による割引が可能ですが、リザーブドインスタンス（ RI ）は利用できません。
一方、ECS on EC2 ではリザーブドインスタンスや EC2 Spot など、 EC2 の料金オプションをフル活用できます。

ここで、 ECS on EC2 の利用も検討が必要になります。
しかし、 ECS on EC2 の運用管理は負担が大きいと考えていました。
そこでAWSのドキュメントを確認していたところ、有用な選択肢があることに気づきました。

ECS on EC2 マネージドインスタンス

2025年9月にリリースされた選択肢です。
Amazon ECS マネージドインスタンスの発表
これは EC2 のメリットを活かしつつ、 Fargate に近い運用を実現できます。

Fargate との違いは、 EC2 が存在するかどうかです。
EC2 が存在することにより、 GPU は使えて、ストレージも増やせて、 EC2 の料金体系を利用できます。
そして、インスタンス設定や台数管理、 OS 管理は AWS が行うため、運用負荷も Fargate とほぼ同等です。

ただし、以下の制約があります。

• インスタンスの最大稼働期間は14日間（セキュリティパッチ適用のため自動ドレイン・置換）
• カスタム AMI は利用不可（ AWS が管理する AMI のみ）
• SSH 接続不可（デバッグは ECS Exec で代替）

運用負荷が Fargate に近い反面、こうした制約も存在するため、要件に合わせて選択してください。

ECS on EC2 セルフマネージドの選択肢

ここで疑問が生じるのが、セルフマネージドの使い所です。
運用上 EC2 の設定をすべて自分で行いたい場合の選択肢になりそうです。

• 特定の AMI を使用する
• インスタンスの配置を管理する
• 既存の EC2 運用のまま利用する

おわりに

ECS を触り始めた当初は「 Fargate だけでいいのでは？」と思っていました。
設定は楽、管理はストレスフリー、実際に EC2 起因のトラブルも Fargate で即解決していたので。。。

しかし調べていくうちに、 GPU ・コスト最適化など、 Fargate では対応できないケースがあることに気づきました。

1. まず Fargate で始める
   → ほとんどの Web アプリはこれで十分

2. GPU・大容量ストレージ・コスト最適化が必要になったら
   → マネージドインスタンスを検討

3. 特殊なカスタマイズが必要なら
   → セルフマネージドを検討

何事も一つだけではなく、幅広い選択肢があることで、サービスを活用することができます。
今回みたいに、ハンズオン教材だけでなく、リリースノートをみて機能をおさらいするのも選択肢を増やすきっかけになるので、引き続き幅広くキャッチアップしていきます。

参考リンク

• Amazon ECS 公式ドキュメント
• AWS Fargate 公式ドキュメント
• Amazon ECS マネージドインスタンスの発表
• Amazon ECS 起動タイプ