EC2 vs ECS/Fargate vs Lambda vs App Runner: AWSコンピュートサービスの使い分け

はじめに

AWSには多数のコンピュートサービスがあり、どれを使えばいいか迷うことが多い。本記事では、主要な4つのコンピュートサービスを比較し、プロジェクトに最適なサービスを選ぶための判断基準を解説します。

身近な例えで理解するコンピュートサービス

• EC2 = 一軒家を借りるようなもの。自由度は最高だが、メンテナンス（セキュリティパッチ、OS更新）も全て自分でやる
• ECS/Fargate = マンションの一室を借りるようなもの。共用部分（インフラ管理）は管理会社（AWS）がやってくれるが、部屋の中（コンテナ）は自分で管理
• Lambda = コワーキングスペース。使いたい時だけ使えて、使わない時は料金がかからない。ただし利用時間の制限がある
• App Runner = ホテル暮らし。何もかもお任せで楽だが、自由度は低い

各サービスの概要

EC2（Elastic Compute Cloud）

AWSの最も基本的な仮想マシンサービス。OSレベルから自由にカスタマイズできる。

特徴:

• 完全な制御権（OS、ネットワーク、ストレージ）
• インスタンスタイプが豊富（汎用、コンピュート最適化、メモリ最適化等）
• 常時稼働のワークロードに向いている
• Auto Scalingで負荷に応じたスケーリングが可能

ECS/Fargate

コンテナベースのアプリケーションを実行するサービス。ECSがオーケストレーション、Fargateがサーバーレスコンテナ実行環境。

特徴:

• コンテナ（Docker）を直接実行
• ECS on EC2: 自分でEC2インスタンスを管理（コスト最適化向き）
• ECS on Fargate: サーバーレスでコンテナを実行（運用負荷軽減）
• タスク定義でCPU/メモリを柔軟に設定

Lambda

サーバーレス関数サービス。コードだけを書けば、インフラ管理は一切不要。

特徴:

• イベント駆動（APIリクエスト、S3アップロード、SQSメッセージ等がトリガー）
• 実行時間の上限は15分
• 使った分だけ課金（リクエスト数 + 実行時間）
• コールドスタートがある（初回実行時に遅延が発生）
• 対応言語: Node.js, Python, Java, Go, .NET, Ruby等

App Runner

フルマネージドなWebアプリケーション実行サービス。コンテナイメージまたはソースコードを渡すだけ。

特徴:

• 設定がほぼ不要（ソースコードまたはコンテナイメージを指定するだけ）
• 自動スケーリング（ゼロまでスケールダウンも可能）
• ロードバランサー、SSL、ヘルスチェックが自動設定
• VPCへのアクセスも可能

比較表

基本機能

料金比較

月間のコスト概算（東京リージョン）:

料金の仕組み

運用負荷の比較

判断フローチャート

[AWSコンピュートサービス選定]
    |
    v
[実行時間が15分以内のイベント駆動処理?]
    |
    +-- はい --> Lambda
    |           （API Gateway連携、S3イベント処理、定期バッチ等）
    |
    +-- いいえ
         |
         v
    [コンテナ化済み or コンテナ化できる?]
         |
         +-- はい --> [運用をできるだけ楽にしたい?]
         |               |
         |               +-- はい --> [設定をほぼゼロにしたい?]
         |               |               |
         |               |               +-- はい --> App Runner
         |               |               |
         |               |               +-- いいえ --> ECS/Fargate
         |               |
         |               +-- いいえ --> ECS on EC2（コスト最適化）
         |
         +-- いいえ
              |
              v
         [特殊なOS設定やソフトウェアが必要?]
              |
              +-- はい --> EC2
              |           （カスタムAMI、GPUインスタンス、Windows Server等）
              |
              +-- いいえ --> ECS/Fargate or App Runner
                            （コンテナ化を検討）

ユースケース別の推奨

WebアプリのAPI

バッチ処理

機械学習推論

実際の企業での採用パターン

パターン1: Lambda中心（スタートアップ）

[ユーザー] --> [API Gateway] --> [Lambda] --> [DynamoDB]
                                    |
                                    +--> [S3]

メリット: 初期コストほぼゼロ、運用不要 デメリット: コールドスタート、15分制限

パターン2: ECS/Fargate中心（成長期）

[ユーザー] --> [ALB] --> [ECS/Fargate]
                              |
                              +--> [RDS]
                              +--> [ElastiCache]
                              +--> [S3]

メリット: 安定した応答、柔軟なスケーリング デメリット: Lambdaより運用負荷が高い

パターン3: ハイブリッド（大規模プロダクト）

[ユーザー] --> [ALB] --> [ECS/Fargate] --> [RDS]
                |                              |
                +--> [API Gateway] --> [Lambda] --> [DynamoDB]
                                          |
                                          +--> [SQS] --> [ECS Task]

メリット: 各サービスの強みを活かせる デメリット: アーキテクチャが複雑

コスト最適化のポイント

EC2

1. リザーブドインスタンス: 1年/3年の前払いで最大72%割引
2. Savings Plans: 柔軟な割引プラン（1年/3年）
3. スポットインスタンス: 余剰キャパシティを最大90%割引で利用（中断リスクあり）
4. Auto Scaling: 負荷に応じてインスタンス数を調整

ECS/Fargate

1. Fargate Spot: 最大70%割引（中断リスクあり）
2. Savings Plans: Fargate使用量にも適用可能
3. タスクサイズの最適化: 必要最小限のCPU/メモリを設定

Lambda

1. メモリサイズの最適化: メモリを増やすとCPUも増えて実行時間が短くなることがある
2. Provisioned Concurrency: コールドスタートを排除（追加料金あり）
3. ARM64（Graviton2）: x86比で約20%安く、パフォーマンスも向上

App Runner

1. 自動スケーリング設定の最適化: 最小インスタンス数を適切に設定
2. Pause/Resume: 使わない時はサービスを一時停止

移行パスの考え方

成長に合わせたサービス移行の一般的なパターン:

Lambda（MVP期）
    ↓ トラフィック増加、コールドスタートが問題に
App Runner（成長初期）
    ↓ より細かい制御が必要に
ECS/Fargate（成長期）
    ↓ コスト最適化が必要に
ECS on EC2（成熟期）
    ↓ 特殊要件が発生
EC2（特殊要件対応）

ただし、全てのプロジェクトがこの順序を辿るわけではない。要件に応じて最適なサービスを最初から選ぶことも重要。

まとめ

迷ったらまずLambdaで始めて、制約に当たったらECS/Fargateに移行するのが、多くのプロジェクトにとって合理的なアプローチである。

2025年の最新動向

Lambda SnapStart

Java Lambda関数のコールドスタートを大幅に短縮する機能。従来数秒かかっていたJavaのコールドスタートが、SnapStartにより100ms以下に短縮される。

Lambda Web Adapter

既存のWebフレームワーク（Express、Flask、Spring Boot等）をそのままLambda上で動かせるアダプター。コードの書き換えなしにLambdaへの移行が可能。

App Runner の進化

App Runnerは継続的に機能が追加されており、WAFの統合、VPCコネクターの改善、自動スケーリングの高度化など、より本格的なワークロードに対応可能になっている。

Graviton (ARM) プロセッサ

AWSの独自設計ARMプロセッサ「Graviton」を使うことで、x86と比べて最大40%のコスト削減が可能。ECS/Fargate、Lambda、EC2の全てでGravitonが利用可能。

参考リンク

• AWS EC2公式ドキュメント
• AWS ECS公式ドキュメント
• AWS Lambda公式ドキュメント
• AWS App Runner公式ドキュメント
• AWS Compute Optimizer