ECS FargateとEC2起動タイプの違いと選び方

はじめに

Amazon ECSでコンテナを実行する際、最初に直面する重要な選択が「起動タイプ」の決定です。ECSには主に2つの起動タイプがあります。サーバーレスでインフラ管理が不要なFargateと、EC2インスタンス上でコンテナを実行するEC2起動タイプです。

どちらを選ぶべきかは、プロジェクトの要件、チームのスキルセット、コスト最適化の優先度によって異なります。本記事では、両者の特徴を詳しく比較し、ワークロードに応じた最適な選択ができるよう解説します。

この記事を読むことで、以下のことが理解できるようになります。

• FargateとEC2起動タイプのアーキテクチャの違い
• 管理負荷、セキュリティ、スケーラビリティの観点からの比較
• 料金体系の違いとコスト試算の考え方
• ワークロード別の最適な起動タイプの選び方

ECSの起動タイプとは

ECSの起動タイプは、コンテナを「どこで」実行するかを決定する設定です。起動タイプによって、インフラの管理責任、料金体系、利用可能な機能が異なります。

flowchart TB
    subgraph ECS["Amazon ECS"]
        TaskDef["タスク定義"]
        Service["サービス"]
    end
    
    subgraph LaunchTypes["起動タイプの選択"]
        Fargate["Fargate<br/>サーバーレス"]
        EC2["EC2起動タイプ<br/>仮想サーバー"]
    end
    
    subgraph FargateInfra["Fargate インフラ"]
        FTask1["タスク"]
        FTask2["タスク"]
        FTask3["タスク"]
    end
    
    subgraph EC2Infra["EC2 インフラ"]
        Instance1["EC2インスタンス"]
        Instance2["EC2インスタンス"]
        ETask1["タスク"]
        ETask2["タスク"]
        ETask3["タスク"]
        ETask4["タスク"]
    end
    
    TaskDef --> Service
    Service --> Fargate
    Service --> EC2
    
    Fargate --> FTask1
    Fargate --> FTask2
    Fargate --> FTask3
    
    EC2 --> Instance1
    EC2 --> Instance2
    Instance1 --> ETask1
    Instance1 --> ETask2
    Instance2 --> ETask3
    Instance2 --> ETask4

管理責任の違い

起動タイプによって、AWSとユーザーの管理責任範囲が大きく異なります。

Fargateの特徴とメリット

AWS Fargateは、サーバーレスでコンテナを実行するコンピューティングエンジンです。EC2インスタンスの管理なしに、タスク定義で指定したリソース（vCPU、メモリ）を持つコンテナを起動できます。

Fargateのアーキテクチャ

Fargateでは、各タスクが独自の分離された環境で実行されます。

flowchart TB
    subgraph FargateArch["Fargate アーキテクチャ"]
        subgraph Task1["タスク1"]
            Container1A["コンテナA"]
            Container1B["コンテナB"]
            Kernel1["専用カーネル"]
        end
        
        subgraph Task2["タスク2"]
            Container2A["コンテナA"]
            Kernel2["専用カーネル"]
        end
        
        subgraph Task3["タスク3"]
            Container3A["コンテナA"]
            Container3B["コンテナB"]
            Kernel3["専用カーネル"]
        end
    end
    
    ENI1["ENI"] --- Task1
    ENI2["ENI"] --- Task2
    ENI3["ENI"] --- Task3

Fargateのメリット

インフラ管理からの解放

Fargateを使用する最大のメリットは、EC2インスタンスの管理が完全に不要になることです。OSのパッチ適用、セキュリティアップデート、キャパシティプランニングといった運用タスクから解放され、アプリケーション開発に集中できます。

タスクレベルの分離

各Fargateタスクは、独自のカーネルで実行されるため、マルチテナント環境でのセキュリティが強化されます。他のタスクとカーネルを共有しないため、コンテナエスケープのリスクが軽減されます。

迅速なスケーリング

EC2インスタンスの起動を待つ必要がないため、需要に応じて素早くスケールアウトできます。Auto Scalingの設定も簡単で、CPU使用率やリクエスト数に基づいて自動的にタスク数を調整できます。

細かなリソース指定

タスクごとにvCPUとメモリを細かく指定でき、無駄なリソースを排除できます。

Fargateのデメリット

GPUサポートなし

Fargateでは、GPUを使用するワークロードを実行できません。機械学習の推論やグラフィックス処理にはEC2起動タイプが必要です。

インスタンスタイプの選択不可

特定のCPUアーキテクチャやインスタンスファミリーを指定できません。ただし、Graviton2（ARM）ベースのFargateは選択可能です。

永続的なローカルストレージなし

Fargateのエフェメラルストレージは、タスク終了時に削除されます。永続的なストレージが必要な場合は、EFSをマウントする必要があります。

EC2起動タイプの特徴

EC2起動タイプでは、ECSクラスターにEC2インスタンスを登録し、そのインスタンス上でコンテナを実行します。インフラの管理責任がユーザーにありますが、より細かな制御が可能です。

EC2起動タイプのアーキテクチャ

EC2起動タイプでは、複数のタスクが同じインスタンス上で実行されます。

flowchart TB
    subgraph EC2Arch["EC2起動タイプ アーキテクチャ"]
        subgraph Instance1["EC2インスタンス1"]
            Agent1["ECSエージェント"]
            Docker1["Dockerランタイム"]
            Task1A["タスクA"]
            Task1B["タスクB"]
        end
        
        subgraph Instance2["EC2インスタンス2"]
            Agent2["ECSエージェント"]
            Docker2["Dockerランタイム"]
            Task2A["タスクA"]
            Task2B["タスクC"]
        end
    end
    
    ASG["Auto Scaling Group"] --> Instance1
    ASG --> Instance2

EC2起動タイプのメリット

GPUワークロードのサポート

P3、P4、G4などのGPUインスタンスを使用でき、機械学習の推論や動画処理などのGPUを必要とするワークロードに対応できます。

インスタンスタイプの自由な選択

コンピューティング最適化（C系）、メモリ最適化（R系）、汎用（M系）など、ワークロードに最適なインスタンスタイプを選択できます。

コスト最適化の余地

リザーブドインスタンスやSavings Plansを活用して、長期的なコスト削減が可能です。また、インスタンスの稼働率を高めることで、リソースを効率的に利用できます。

ホストレベルのカスタマイズ

カスタムAMIの使用、カーネルパラメータの調整、追加のモニタリングエージェントのインストールなど、ホストレベルでの細かなカスタマイズが可能です。

EC2起動タイプのデメリット

運用負荷の増加

EC2インスタンスのパッチ適用、セキュリティ更新、ECSエージェントの更新など、継続的な運用タスクが発生します。

キャパシティ管理の複雑さ

タスクの需要に応じてインスタンス数を適切に管理する必要があります。キャパシティプロバイダーを使用することで自動化できますが、設定と理解に時間がかかります。

スケーリングの遅延

新しいインスタンスの起動には数分かかるため、急激な負荷増加への対応がFargateより遅くなる可能性があります。

料金比較と選択基準

Fargateの料金体系

Fargateは、タスクが使用するvCPU、メモリ、ストレージに対して秒単位（最低1分）で課金されます。

Fargate料金計算例：1 vCPU / 2 GB メモリ

vCPU: 0.05056 USD × 1 = 0.05056 USD/時間
メモリ: 0.00553 USD × 2 = 0.01106 USD/時間
合計: 約0.062 USD/時間

月間（720時間）: 約44.64 USD/タスク

EC2起動タイプの料金体系

EC2起動タイプでは、ECS自体の追加料金はなく、EC2インスタンスの料金のみが発生します。

コスト比較シミュレーション

同等のリソースを使用した場合の月額コストを比較します。

シナリオ：2 vCPU / 4 GB メモリのタスクを常時3つ実行

この例では、EC2起動タイプの方がコスト効率が良く見えます。しかし、EC2の場合は以下の隠れたコストも考慮が必要です。

• インスタンス管理の人的コスト
• キャパシティの余剰（バッファ）
• パッチ適用時のダウンタイムまたは追加インスタンス

コスト削減オプション

Fargate Spot

割り込み耐性のあるワークロードでは、Fargate Spotを使用することで最大70%のコスト削減が可能です。

Compute Savings Plans

Fargateの使用量が一定している場合、1年または3年のSavings Plansを購入することで最大50%の割引を受けられます。

EC2 Spot Instances

EC2起動タイプでSpotインスタンスを使用することで、最大90%のコスト削減が可能です。ただし、中断のリスクがあります。

ユースケース別の選択ガイド

Fargateが適しているケース

flowchart LR
    subgraph FargateUseCase["Fargateが適しているユースケース"]
        A["運用負荷を<br/>最小化したい"]
        B["変動する<br/>ワークロード"]
        C["セキュリティ要件が<br/>厳しい"]
        D["小〜中規模の<br/>マイクロサービス"]
    end
    
    A --> Fargate["Fargate"]
    B --> Fargate
    C --> Fargate
    D --> Fargate

Webアプリケーションのバックエンド

トラフィックの変動に応じて自動スケーリングし、運用負荷を最小限に抑えたい場合に最適です。

マイクロサービスアーキテクチャ

各サービスを独立してスケーリングでき、タスクレベルのセキュリティ分離が実現できます。

バッチ処理（短時間）

Fargate Spotと組み合わせることで、コスト効率の良いバッチ処理が実現できます。

開発・テスト環境

迅速な環境構築と破棄が可能で、使用していない時間の課金を最小化できます。

EC2起動タイプが適しているケース

flowchart LR
    subgraph EC2UseCase["EC2起動タイプが適しているユースケース"]
        A["GPUが必要"]
        B["大規模で<br/>予測可能な負荷"]
        C["コスト最適化が<br/>最優先"]
        D["特定のインスタンス<br/>要件がある"]
    end
    
    A --> EC2["EC2起動タイプ"]
    B --> EC2
    C --> EC2
    D --> EC2

機械学習の推論

GPUインスタンスが必要な場合は、EC2起動タイプが唯一の選択肢です。

大規模で安定したワークロード

24時間365日稼働する大規模システムでは、リザーブドインスタンスとの組み合わせでコストを最適化できます。

高度なカスタマイズが必要

カスタムカーネルパラメータ、特殊なストレージ構成、ホストレベルのモニタリングが必要な場合に適しています。

コンプライアンス要件

特定のインスタンスタイプやハードウェア分離が必要なコンプライアンス要件がある場合に選択します。

起動タイプの選択フローチャート

以下のフローチャートを参考に、ワークロードに適した起動タイプを選択してください。

flowchart TB
    Start["起動タイプを選択"] --> Q1{"GPUが必要？"}
    Q1 -->|Yes| EC2["EC2起動タイプ"]
    Q1 -->|No| Q2{"運用負荷を<br/>最小化したい？"}
    
    Q2 -->|Yes| Fargate["Fargate"]
    Q2 -->|No| Q3{"大規模で予測可能な<br/>ワークロード？"}
    
    Q3 -->|Yes| Q4{"コスト最適化が<br/>最優先？"}
    Q3 -->|No| Fargate
    
    Q4 -->|Yes| EC2
    Q4 -->|No| Q5{"インスタンスの<br/>カスタマイズが必要？"}
    
    Q5 -->|Yes| EC2
    Q5 -->|No| Fargate
    
    EC2 --> EC2Note["リザーブド/Savings Plans<br/>Spotの活用を検討"]
    Fargate --> FargateNote["Fargate Spot<br/>Savings Plansの活用を検討"]

ハイブリッドアプローチ

実際のプロダクション環境では、FargateとEC2起動タイプを組み合わせたハイブリッドアプローチも有効です。

キャパシティプロバイダー戦略

ECSのキャパシティプロバイダー機能を使用すると、同一クラスター内でFargateとEC2を併用できます。

flowchart TB
    subgraph Cluster["ECSクラスター"]
        Service["ECSサービス"]
        
        subgraph CapacityProviders["キャパシティプロバイダー"]
            Fargate["Fargate<br/>ベース: 80%"]
            FargateSpot["Fargate Spot<br/>ウェイト: 20%"]
            EC2Provider["EC2<br/>GPUワークロード用"]
        end
    end
    
    Service --> Fargate
    Service --> FargateSpot
    Service --> EC2Provider

構成例：コスト最適化されたWebサービス

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "capacityProviderStrategy": [
    {
      "capacityProvider": "FARGATE",
      "weight": 1,
      "base": 2
    },
    {
      "capacityProvider": "FARGATE_SPOT",
      "weight": 3,
      "base": 0
    }
  ]
}

この設定では、最低2つのタスクをFargateで実行し、追加のタスクは75%の確率でFargate Spotで起動します。

まとめ

ECSの起動タイプ選択は、単純な「どちらが良いか」という問題ではなく、プロジェクトの要件に基づいた総合的な判断が必要です。

選択の目安

• Fargate：運用負荷の軽減を優先し、中小規模のワークロードに最適
• EC2起動タイプ：GPUが必要、または大規模ワークロードでコスト最適化を追求する場合に選択

まずはFargateで始め、要件が明確になるにつれてEC2起動タイプへの移行やハイブリッド構成を検討するというアプローチも有効です。重要なのは、技術的な制約とビジネス要件のバランスを取りながら、継続的に最適な選択を見直していくことです。

参考リンク

• Amazon ECS 起動タイプ - AWS ドキュメント
• AWS Fargate 料金
• Amazon ECS 料金
• Amazon EC2 料金
• ECS キャパシティプロバイダー - AWS ドキュメント
• Compute Savings Plans