ECSでコンテナを動かすとき、最初に迫られるのがFargateかEC2起動タイプかの選択です。サーバ管理不要の手軽さと、高密度・特殊要件への対応力。どちらが正しいかは稼働パターンとコンプラ要件で決まります。本記事では現場の判断軸を整理します。
ECSでコンテナを本番運用する際、避けて通れないのが起動タイプの選定です。「とりあえずFargate」で始めた環境が、規模拡大とともにコスト面で疑問符が付くこともあれば、EC2起動タイプで組んだクラスターの運用負荷に情シスが疲弊することもあります。本記事では、EMWが実際の案件で使っている判断軸を、AWS一次情報と突き合わせながら整理します。
012つの起動タイプの本質的な違い
ECSには大きくFargateとEC2の2つの起動タイプがあります(このほかオンプレ向けのExternalもありますが本稿では割愛します)。違いを一言でいえば「サーバというレイヤーを自分で持つかどうか」です。
- Fargate：タスク(コンテナのまとまり)が要求するvCPUとメモリの分だけ課金される、サーバレスの実行環境です。OSのパッチ適用もインスタンスのスケーリングも不要で、AWSが基盤を隠蔽します。
- EC2起動タイプ：自分で用意したEC2インスタンス群(クラスター)の上でタスクを動かします。インスタンスの選定・パッチ・容量管理は利用者の責任ですが、そのぶん高密度な詰め込みやGPU・特殊インスタンスの利用、Savings Plansによる割引が効きます。
AWS公式ドキュメントでは、EC2起動タイプは「環境のカスタマイズをより細かく制御できる一方、パッチ適用・インスタンスタイプ選定・ネットワーク・セキュリティの維持管理は利用者の責任」と明記されています。手軽さと制御性のトレードオフが、選定の出発点になります。
02コストの分岐点はどこにあるか
選定でもっとも問われるのがコストです。AWSのコンテナブログ「Theoretical cost optimization by Amazon ECS launch type」では、EC2インスタンスのリソース予約率(reservation rate)を軸にした比較が示されています。
- 予約率が低い(CPU/メモリの6〜12%程度しか使っていない)状態では、Fargateのほうが約87%安くなる
- 逆に予約率が100%近く、インスタンスを無駄なく詰め込めている状態では、EC2起動タイプが20%以上安くなる
つまり「EC2インスタンスをどれだけ隙間なく使い切れるか」がコスト分岐の本質です。Fargateはタスク単位課金なので、そもそも使った分しか払いません。一方EC2は、タスクが載っていない空きスロットの分も料金が発生します。同ブログも「Fargateはリソースがインスタンスキャパシティに近づくほど優位性が薄れる」と結論づけています。
03Savings PlansとSpotが分岐点を動かす
純粋なオンデマンド料金だけで比較すると話は単純ですが、実務では割引オプションが分岐点を大きく動かします。ここは押さえておくべき論点です。
- Compute Savings Plans：AWS公式ドキュメントによれば、Compute Savings PlansはEC2・Lambda・Fargateの3サービスに横断的に適用されます。EC2起動タイプはもちろん、Fargateも対象です。ただしFargateへの割引はvCPU/メモリの次元にのみ効き、Windowsなどのライセンス料には効きません。EC2 Instance Savings PlansはEC2にのみ適用され、Fargateはカバーしません。
- Fargate Spot：中断耐性のあるワークロード向けに、通常料金から最大70%引きで利用できます(Linux x86/ARMのみ)。EC2側のSpotに相当する選択肢がFargateにもある、という点は見落とされがちです。
重要なのは、「Fargateだから割引が効かない」という誤解を捨てることです。Compute Savings PlansはFargateにも効くため、常時稼働のベースライン分はFargateでもコミットメント割引を取れます。EC2 Instance Savings PlansのようにインスタンスファミリーやリージョンをまたいでもEC2に効く柔軟性まで求めるなら、EC2起動タイプに軍配が上がります。割引の具体的な料率はリージョンや期間で変わるため、必ず公式の料金ページで最新を確認してください。
04常時稼働 vs スパイク — 稼働パターンで見る
コストの議論を稼働パターンに翻訳すると、判断がしやすくなります。
- 常時稼働・予測可能：24時間動き続けるAPIやバッチ基盤で、負荷が読めるなら、EC2起動タイプ+Savings Plansでインスタンスを使い切る設計がコスト面で有利です。前提は「ビンパッキングを効かせて予約率を高く保てること」。
- スパイク・変動が大きい：日中だけ動く、月末だけ跳ねる、イベント時に急増するといったワークロードは、Fargateが向きます。EC2だとピークに合わせてインスタンスを確保するか、Auto Scalingの立ち上がり遅延を許容するかの二択になりますが、Fargateはタスクを増やすだけでよく、空き時間の課金も発生しません。
- ゼロスケール・低頻度：ほとんど動かないジョブは、EC2でクラスターを常時抱えるのは無駄です。Fargate(あるいはより軽量な処理ならLambda)が素直です。
スケーリングの制御についても差があります。EC2起動タイプではインスタンスのAuto Scalingとタスクのスケーリングを二段で設計する必要があり、Auto Scaling設計の勘所が問われます。Fargateはタスクを増減させるだけで基盤が追従するため、設計がシンプルです。
05高密度・GPU・特殊要件はEC2の独壇場
コストと稼働パターンを脇に置いても、EC2起動タイプでなければ実現できない要件があります。ここは選定の「効かない側」を消す作業として重要です。
- GPU / 特殊インスタンス：機械学習の推論・学習でGPUインスタンスを使う、あるいはメモリ最適化・Arm(Graviton)の特定世代を細かく指定したい場合、インスタンスタイプを直接選べるEC2起動タイプが必要です。EC2インスタンスタイプ選定の自由度がそのまま使えます。
- 高密度な詰め込み：多数の小さなタスクを1インスタンスに敷き詰めたい場合、Fargateはタスクごとに最小課金単位があるため割高になりがちです。EC2なら1台に大量のコンテナを載せて単価を下げられます。
- 永続的なローカルストレージ・特殊デバイス：大容量のインスタンスストアや特定のカーネルパラメータ・デーモンが必要なワークロードは、ホストを制御できるEC2でないと成立しません。
06コンプラ要件 — ホストを触れるかどうか
エンタープライズ案件で見落とせないのがコンプライアンス要件です。Fargateはサーバ層が隠蔽されるため、以下のような要件がある場合は注意が必要です。
- ホストへのエージェント常駐：一部のセキュリティ製品やホスト型IDS、特定の監査エージェントは、EC2ホストにインストールして常駐させる前提です。Fargateではホストにアクセスできないため、サイドカーコンテナで代替できるか事前検証が要ります。
- 専有テナンシー(Dedicated)：物理サーバの専有が契約・監査上求められる場合、Dedicated InstancesやDedicated HostsはEC2でなければ選べません。
- ログ・ファイル取得の粒度：フォレンジックでホストのディスクイメージを取得する運用が定められている場合、Fargateでは物理ホストに手が届きません。
逆に言えば、Fargateはホストのパッチ管理をAWSに委ねられるため、パッチ適用のSLA遵守という観点ではむしろコンプラ上有利に働くこともあります。PCI DSSなどの認証範囲を狭めたい場合、管理対象からOS層が外れるFargateが評価されるケースもあります。要件を「ホストを触る必要があるか」で切り分けるのが実務的です。認証範囲の設計はマルチアカウント統制とあわせて検討すると整理しやすくなります。
07キャパシティプロバイダーとECS Managed Instances
ここまで「起動タイプ」の話をしてきましたが、AWSは現在、起動タイプよりもキャパシティプロバイダーでの容量構成を推奨しています。公式ドキュメントでは「キャパシティプロバイダーは、従来の起動タイプと比べて推奨される容量構成の方法」と明記されています。
- 推奨される使い方は、タスク定義の
requiresCompatibilitiesで互換性(どの基盤で動けるか)を宣言し、実際の起動はキャパシティプロバイダー戦略で制御するというものです。 - キャパシティプロバイダーを使うと、1つのクラスター内でFargate・Fargate Spot・EC2 Auto Scalingグループを混在させ、比率を指定して配分できます。「ベースはFargate、コスト最適化のためにSpotも混ぜる」といった設計が可能です。
- さらにECS Managed Instancesという選択肢も加わりました。これは「Fargateの手軽さとEC2の柔軟性を組み合わせた」フルマネージドのコンピュートで、GPUや特定インスタンスが必要だがEC2の運用は避けたい、という中間ニーズに応えます。
実務上重要なのは移行の可否です。公式ドキュメントによれば、起動タイプ同士の直接切り替え(EC2起動タイプ↔Fargate起動タイプ)はサポートされていません。EC2からFargateに移したい場合は、Fargateキャパシティプロバイダーへ移行する形を取ります。将来の柔軟性を考えると、新規構築時から起動タイプ直指定ではなくキャパシティプロバイダーで組んでおくのが得策です。
requiresCompatibilitiesにFargateを追加し、キャパシティプロバイダー戦略へ切り替える段取りが必要です。稼働中サービスはUpdateServiceでキャパシティプロバイダーへ移行し、検証しながら比率を調整するのが安全です。08決定表 — 迷ったらここに戻る
これまでの論点を、実務で使う決定表にまとめます。上から順に「効かない側を消す」形で読んでください。
- GPU・特殊インスタンス・専有テナンシーが必須 → EC2起動タイプ(またはECS Managed Instances)。ここで確定するなら以降は不要。
- ホストにエージェント常駐・ホスト制御が監査要件 → EC2起動タイプ。サイドカーで代替可能か要検証。
- 稼働が変動・スパイク型/低頻度 → Fargate。タスク単位課金の恩恵が最大。
- 常時稼働・予測可能で、複数サービスを1クラスターに相乗りさせて予約率を高く保てる → EC2起動タイプ+Savings Plans。
- 常時稼働だが単一サービス/相乗りが難しい → Fargate+Compute Savings Plans。運用負荷を削れる分が効く。
- 判断がつかない/将来変わりうる → キャパシティプロバイダーで組み、Fargateから始めて実測後に最適化。
コンテナのオーケストレーション自体をECSにするかEKSにするかで迷っている場合は、ECS vs EKS選定を先にお読みください。起動タイプの議論はその後の話です。
—まとめ
Fargateか EC2起動タイプかの選定は、突き詰めると3つの軸に集約されます。(1)EC2インスタンスをどれだけ使い切れるか(予約率)というコスト分岐、(2)常時稼働か変動かという稼働パターン、(3)GPU・専有・ホスト制御といったコンプラ/特殊要件です。特殊要件で先にEC2が確定しないかを消し、次に稼働パターンとコスト分岐で判断するのが実務の順序です。
そして現在のAWSは、起動タイプ直指定よりもキャパシティプロバイダーでの構成を推奨しています。新規構築なら最初からキャパシティプロバイダーで組み、Fargateで身軽に始めて、実測データをもとにEC2やSpotへ最適化していくのが、手戻りの少ない進め方です。数値や割引率はバージョン・リージョンで変わるため、最終判断の前に必ず公式の最新情報を確認してください。EMWでは既存ECS環境の予約率棚卸しからコスト最適化までご支援しています。導入事例もあわせてご覧ください。