ECS Fargate vs EC2 — スペックの組み合わせと料金比較

インフラ AWS コスト
読了 6分

ECS のタスクをどこで動かすかは、Fargate と EC2 ベースのどちらかの選択です。よくある通念は「Fargate は楽な代わりに高い」ですが、単価を実際に計算してみると差は通念より小さく、比較を覆す変数は単価ではなく使用率です。結論を先に書くと、基本は Fargate で、EC2 ベースは GPU・特殊ハードウェア・常時高使用率の大型フリートのように条件が明確なときの選択です。 ECS と Fargate の概念そのものは AWS 上級 #1 で、デプロイの実務は AWS 実践 #1 で扱いました。料金は us-east-1 基準です。

課金の単位が違います — タスク vs インスタンス #

Fargate はタスクに宣言した vCPU・メモリのサイズの分だけ秒単位で課金します(vCPU あたり 1 時間約 $0.04048、GB あたり約 $0.004445)。タスクが止まれば課金も終わり、請求書のどこにもホストという概念がありません。

EC2 ベースはインスタンスが起動している時間の分だけ課金します。タスクが 1 個でも 10 個でも、インスタンスの空きが遊んでいても料金は同じです。その代わりインスタンスの選択権(ファミリー比較 参照)とホストへのアクセス権が得られ、AMI のパッチ適用、キャパシティ管理、エージェント運用という仕事が付いてきます。

この構造の違いが、後に出てくるすべての比較の土台です。Fargate の単価には「空きスペースがない」が含まれ、EC2 の単価には「空きスペースも買う」が含まれています。

Fargate のスペック — 決まった組み合わせから選びます #

Fargate は任意のスペックを受け付けず、vCPU の段階ごとに許容されるメモリ範囲が決まっています。

vCPUメモリ範囲
0.250.5・1・2GB
0.51〜4GB
12〜8GB
24〜16GB
48〜30GB
816〜60GB
1632〜120GB

読み方は二つです。第一に、vCPU 対メモリの比率が 1:2 から 1:8 の間で、EC2 の c・m・r のスペクトルをタスク単位で選ぶことになります。第二に、上限が 16vCPU・120GB なので、それを超える単一タスクは EC2 ベースに行くしかありません。一時ストレージは 20GiB が基本で含まれ、最大 200GiB まで拡張でき、GPU はサポートされません。 0.25vCPU のような小数のサイズは EC2 にはない選択肢なので、小さなサイドカーや軽量 API を細かく分けるには Fargate の組み合わせのほうがむしろ有利です。

単価の比較 — プレミアムは思ったより小さいです #

同じ 2vCPU・8GB で計算します。

  • Fargate(x86): 2×$0.04048 + 8×$0.004445 = 1 時間あたり約 $0.117
  • EC2 m7i.large(x86、2vCPU・8GiB): 約 $0.101 — Fargate が約 16% 高くなります。
  • Fargate(ARM): 2×$0.03238 + 8×$0.003556 = 約 $0.093
  • EC2 m8g.large(Graviton、2vCPU・8GiB): 約 $0.090 — 差が約 4% まで縮まります。

つまりオンデマンドの単価だけを見れば、「2 倍高い」という通念は成立しません。比較を実際に分けるのは EC2 側の使用率です。EC2 ベースではタスクがインスタンスに隙間なく詰まらない限り、空きスペースも料金に含まれます。スケールイン後に半分空いたインスタンスが残るビンパッキングの損失、デプロイの余裕分、デーモンやエージェントの取り分まで考えると、フリート使用率 70% は良く管理されている部類ですが、その時点で EC2 の実効単価はすでに Fargate を超えています。逆に使用率を 90% 以上に保てる大型の固定フリートなら、EC2 ベースの単価優位が実際に残ります。

EC2 ベースが勝つ条件 #

  • GPU・アクセラレータ: Fargate は GPU タスクを受け付けません。推論・学習コンテナは EC2 ベース(g・p 系)で確定です。
  • 特殊ハードウェア: ローカル NVMe(i・d 系)、超大型メモリ、特定の CPU 世代の固定が必要な場合です。単一タスクが 16vCPU・120GB を超える場合もここに入ります。
  • ホストへのアクセス: カーネルパラメータの調整、特権コンテナ、ホストネットワークモード、ノードごとに一つずつ動くエージェント類が必要な場合です。
  • 常時高使用率の大型フリート: 負荷が平坦でビンパッキングを 90% 以上に保て、リザーブドや Savings Plans のコミットまで掛けてある場合です。この組み合わせなら単価優位が管理コストを上回ります。

このリストに該当しないのに EC2 ベースを使っているなら、支払っているのは単価ではなく、キャパシティ管理という常時の業務です。

料金を下げる軸 — ARM、Spot、Savings Plans #

Fargate の中にも下げる軸が三つあります。

  • ARM(Graviton): 単価が x86 より約 20% 低くなります。コンテナイメージの ARM ビルド(マルチアーキテクチャ)さえあれば、タスク定義でアーキテクチャを 1 行変えるだけです。
  • Fargate Spot: 中断を許容できるワークロード(バッチ、キューのコンシューマ)なら最大 70% 割引です。x86 と ARM の両方でサポートされ、2 分前の中断通知を処理できる必要があります。
  • Compute Savings Plans: 時間あたりのコミット金額を掛ければ Fargate にも適用されます。EC2 ベースのようにインスタンスを固定しなくてもコミット割引を受けられるということです。

三つは重ねて使えます。ARM に Spot まで重ねると x86 オンデマンド比で 4 分の 1 程度まで下がるので、「Fargate は高くて使えない」と結論を出す前に、まずこの軸を適用してみます。遊んでいるタスクやサービスの整理は 常時点検リスト と重なる作業です。

選択の手順 #

  1. 強制条件からふるいにかけます: GPU、ホストアクセス、16vCPU・120GB 超え、特殊ハードウェアのどれかに該当すれば EC2 ベースです。
  2. 該当しなければ Fargate で始めます: タスクサイズはコンテナの実測使用量(CloudWatch Container Insights)に合わせて組み合わせから選び、小さく始めて上げます。
  3. アーキテクチャは ARM を先に検討します: マルチアーキテクチャのビルドさえ整えれば 20% がそのまま削減されます。
  4. ワークロードの性格に合わせて Spot とコミットを重ねます: 中断を許容できるなら Spot、ベースの負荷が安定しているなら Compute Savings Plans です。
  5. フリートが大きくなったら再計算します: 負荷が平坦になり使用率 90% 台の運用が可能になった時点で、EC2 ベース移行の単価優位が管理コストを上回るかを計算し、上回るときだけ移ります。

まとめ #

  • Fargate は宣言したタスクサイズの分だけ、EC2 ベースはインスタンスの起動時間の分だけ課金します。すべての比較はこの構造の違いから始まります。
  • Fargate のスペックは 0.25〜16vCPU、最大 120GB メモリの組み合わせから選びます。GPU はなく、一時ストレージは基本 20GiB です。
  • 同じスペックのオンデマンド単価の差は x86 で約 16%、ARM で約 4% と、通念より小さいです。比較を分けるのは EC2 フリートの実際の使用率です。
  • EC2 ベースは GPU、特殊ハードウェア、ホストアクセス、常時高使用率の大型フリートという明確な条件で選びます。
  • Fargate の料金は ARM 20%、Spot 最大 70%、Compute Savings Plans のコミットを重ねて下げます。「高い」という結論は、この軸を適用した後に出します。
X