AWS Compute リソースの選び方 — EC2・ECS・EKS・Lambda 実務ガイド
本記事では、AWS のコンピュートサービス（EC2・ECS・EKS・Lambda）をいつ、どのように使い分けるかを、実装負荷と運用効率の観点から整理します。
(ちょっと寝る前に書いたものなので 絵とか内容のせいさ更新していきますが、ざっと経験とつらみ・もやみ・クロウからの選択を詰め込んだのでぜひ皆さんにも 選択肢の知識共有できるといいなです)
概要表
| サービス | 用途 | メリット | デメリット |
|---|---|---|---|
| EC2 | 最後の砦。カスタム性重視 | なんでも実装できる | OS・ミドルウェア・セキュリティパッチの運用負荷 |
| ECS (EC2型) | 特殊リソース・突発スパイク対応 | 既存 EC2 インフラの活用 | オートスケーリングの応答が遅い場合がある |
| ECS Fargate | 一般的な Web アプリ・マイクロサービス | マネージド、VPC 統合、シンプル | コスト計算の複雑さ、起動時間(秒単位) |
| Lambda | 非同期処理・イベント駆動・ツール | スケーリング不要、課金最小限 | 15分の実行時間制限、ウォームスタート対応 |
| EKS | 顧客プラットフォーム・PaaS・GPU共有 | 高度なリソース制御 | 運用・学習コスト高、EOL対応 |
各サービスの詳細
1. EC2 — 最後の砦
こういう時に選ぶ：
- Windows ドメイン認証が必要
- 複数の異なるランタイムを 1台で動かす
- ステートフル性が強い（セッション管理など）
- 既存の構成管理ツール（Ansible・Chef）で統一したい
メリット：
- カスタマイズの自由度が最高
- ネイティブアプリケーション、GPU ドライバ、カーネルパラメータ調整など
デメリット（実装・運用負荷）：
- OS セキュリティパッチの定期適用
- ミドルウェアアップデート（Java・Node.js など）
- ディスク管理（EBS スナップショット、バックアップ）
- 監視・ロギング設定の自動化
- スケーリング: Auto Scaling Group で対応が標準だが、スパイク対応には事前スケールが必要
実装のコツ：
## [NOTE] EC2 は「管理すべきもの」として位置づけ
## セキュリティパッチは最低月1回の定期適用を計画に組み込む
## 数が増えると Systems Manager Patch Manager で自動化を検討
2. ECS (EC2型) — 既存インフラの活用戦略
こういう時に選ぶ：
- EC2 インスタンスプールをすでに保有している
- リソース（GPU・メモリ・CPU）を複数チームで分け合いたい
- 突発的なトラフィックスパイク（例：ECサイトのセール）に素早く対応したい
メリット：
- インスタンスの既得資産を活用できる
- 複数のコンテナワークロードを同じ EC2 にパック可能
- CloudWatch Container Insights で可視化
デメリット（ここが重要）：
- コンテナ追加時に「EC2 インスタンス起動」を伴う可能性
- EC2 起動: 1-3分
- コンテナ起動: 秒単位
- スパイク対応には不向き → Fargate を選んだ方が無難
実装のコツ：
## [WARNING] ECサイトのセール時のようなスパイク対応では要注意
## EC2 Auto Scaling Group の起動待機が大きなボトルネック
## 予測可能なスパイク（定時セール）→ Fargate でプレスケール
## 予測不可能なトラフィック → はじめから Fargate を選ぶ
3. ECS Fargate — 一般的な Web 開発のベストチョイス
こういう時に選ぶ：
- 一般的な Web アプリケーション開発（ほぼこれ）
- マイクロサービスアーキテクチャ
- バージョン管理・リリース管理が必要
- スケーリング（自動・手動）が必要
- VPC 内で完結したい
メリット（推奨理由）：
- 完全マネージド: OS パッチ・ミドルウェア管理不要
- VPC 統合: セキュリティグループ、NACLで直接制御
-
Kubernetes 機能の網羅:
- Job: 一時的なバッチタスク
- DaemonSet相当: サイドカーコンテナ
- Deployment相当: ECS Service + ALB/NLB
- ALB/NLB との連携: スケールポリシー（ターゲット追跡・ステップスケーリング）
- コンテナのライフサイクル: 使い捨てコンテナ設計が自然
メリット（実装効率）：
- リリース: ECR にイメージプッシュ → タスク定義更新 → ローリングデプロイ
- バージョン管理: イメージタグで一元化
- 環境変数・シークレット: 環境変数・Systems Manager Parameter Store との統合
デメリット：
- コスト計算が複雑 (vCPU + メモリ + データ転送)
- タスク起動時間: 秒単位 （制御不可）
- 「起動後1秒で応答」という要件は向かない
- Fargate Spot でコスト削減も可能（ただし中断リスク）
実装のコツ：
## [SPEC] Fargate の推奨構成
## - CPU: 256 ~ 2048 mCPU
## - メモリ: CPU に応じた段階値（256MB単位）
## - Network Mode: awsvpc（推奨、一択）
##
## [MEMO] スケーリング戦略の選択
## - ターゲット追跡スケーリング: CPU 70% or メモリ 80%（推奨）
## - ステップスケーリング: カスタム CloudWatch メトリクス
##
## [TODO] ALB リスナールール設計
## - パスベース（/api/* → マイクロサービス）
## - ホストベース（api.example.com → API Gateway風）
4. Lambda — イベント駆動と非同期処理
こういう時に選ぶ：
- 非同期処理（SQS、SNS、EventBridge トリガー）
- イベント駆動アーキテクチャ（S3 アップロード後の処理など）
- ECS Fargate より格安かどうか見極めたい場合
- 定期実行ツール（EventBridge Scheduler）
- Durable Workflows（Step Functions）のサブアクション
メリット：
- スケーリング無制限: 同時実行数まで自動スケール
- 課金最小限: 呼び出し数 + 実行時間（GBs）
- 管理負荷ゼロ: デプロイは ZIP または イメージプッシュのみ
デメリット：
- 15 分の実行時間制限 → 長時間バッチは不適
-
ウォームスタート: 初回呼び出しは遅い
- Node.js: ~100ms
- Python: ~50ms
- Java: ~500ms
- ステートレス性: セッション・接続管理が難しい
ECS Fargate vs Lambda のコスト比較：
Lambda:
呼び出し: 100万回 / 月
実行時間: 平均 1秒
メモリ: 512 MB
→ ¥ 約500-700円 / 月
ECS Fargate:
タスク数: 1個（常時起動）
CPU: 256 mCPU
メモリ: 512 MB
→ ¥ 約3,000-4,000円 / 月
結論: 呼び出しが少ない or スパイク型 → Lambda
常時稼働 or 継続処理 → Fargate
実装のコツ：
## [NOTE] Lambda のトリガー設計
## - S3: PUT イベント → イメージ処理・変換
## - SQS: 非同期キュー → メール送信・ログ集約
## - EventBridge: Cron or カスタムイベント
##
## [WARNING] Java Lambda は要注意
## ウォームスタート500ms + GraalVM (ネイティブイメージ) 検討
##
## [MEMO] Durable Workflows (Step Functions)
## Lambda の組み合わせで長時間処理を実装
5. EKS — 高度なリソース共有と顧客プラットフォーム
こういう時に選ぶ：
- 顧客プラットフォーム or PaaS をサービス提供する
- GPU・TPU を複数テナント（チーム）で分け合いたい
- マシンリソース（CPU・メモリ）を細粒度で制御したい
- RBAC・ネットワークポリシーで高度なテナント分離が必要
メリット：
- Kubernetes のすべての機能（Deployment・StatefulSet・DaemonSet など）
- リソース制限（QoS Classes）: Guaranteed / Burstable / BestEffort
- ノードセレクタ・アフィニティ: 特定ノードグループへの配置
- カスタムスケーラー: Karpenter などで最適化
デメリット（ここが大事）：
-
運用コスト高い:
- Kubernetes バージョン管理・EKS 更新（月1回程度）
- Addon（CNI・CoreDNS・kube-proxy）の管理
- ノードグループの EOL 対応（OS イメージ更新）
- 学習コスト: Pod・Deployment・Service などの概念習得
- トラブルシューティング複雑: ネットワーク・リソース競合の原因特定が難しい
実装のコツ：
## [SPEC] EKS ノードグループ設計
## - 汎用: m6i.2xlarge （標準ワークロード）
## - GPU: p3.2xlarge （機械学習・AI）
## - Spot: コスト最適化（非クリティカルなバッチ）
##
## [WARNING] Kubernetes への逃げ道は ECS Fargate
## 単純なマイクロサービスなら Fargate で十分
## → Kubernetes は本当に必要か、メンテコストと天秤に
##
## [TODO] PaaS 提供時の構成
## - Namespace: テナント分離
## - RBAC: 権限制御
## - ResourceQuota: CPU・メモリ制限
## - NetworkPolicy: トラフィック制御
意思決定フロー
アプリケーションを AWS で動かしたい
↓
【Q1】管理・運用の手間を最小化したい？
├─ YES → ECS Fargate / Lambda へ
└─ NO（カスタマイズ重視） → EC2 へ
↓
【Q2】大規模・複数テナント・リソース共有が必要？
├─ YES → EKS
└─ NO → ECS (EC2型) or Fargate へ
↓
【Q3】短期・バースト性・スパイク対応？
├─ YES → ECS Fargate / Lambda
├─ NO（常時稼働） → ECS Fargate
└─ 非同期・イベント駆動 → Lambda
↓
【Q4】ECS Fargate コスト vs Lambda コスト
├─ Lambda が安い → Lambda
└─ Fargate が安い → Fargate
【最終判断】
- 迷ったら Fargate にしておく（後から Lambda に切り替えやすい）
- Kubernetes は本当に必要か 3回は自問する
よくあるハマりポイント
1. ECS EC2型で「スパイク対応が間に合わない」
症状: ECサイトのセール開始 → トラフィック急増 → EC2 インスタンス起動待機中に 503 エラー
原因: インスタンス起動（1-3分）がボトルネック
解決策:
- 予測可能なスパイク（定時セール）→ 事前に Fargate タスクをスケール
- 予測不可能なトラフィック → 最初から Fargate を選ぶ
2. Lambda の 15 分制限を超える処理
症状: 大規模データ処理、レポート生成が失敗
原因: Lambda は最大 15 分で強制終了
解決策:
- Step Functions で複数 Lambda をチェーン
- ECS Fargate タスク で長時間バッチ処理
- AWS Glue / Athena でデータ処理
3. EKS の「運用負荷軽減」勘違い
症状: 「Kubernetes を導入したら運用が楽になる」と期待 → 実際は複雑化
原因: EKS はマネージドだが、Kubernetes 自体の複雑さは残る
解決策:
- シンプルなマイクロサービス → ECS Fargate で十分
- GPU・リソース共有が本当に必要か再検討
- メンテコストを開発チームに見積もらせる
4. コスト最適化の見誤り
症状: 「Lambda なら安い」と Fargate から乗り換え → 実は高くなった
原因: 常時稼働のワークロードは Fargate が安い（呼び出し頻度による）
解決策:
- 月の呼び出し数 × 平均実行時間 で計算
- Fargate Spot で 40-60% コスト削減 も検討
まとめ
| 選択肢 | 一言 |
|---|---|
| EC2 | 最後の砦。でも運用負荷を覚悟で |
| ECS EC2型 | 既存インフラ活用。スパイク対応は厳しい |
| ECS Fargate | ほぼ全ての Web アプリの第一選択肢 |
| Lambda | イベント駆動・非同期処理の王様 |
| EKS | 本当に必要か 3回自問してから |
実装戦略: 迷ったら Fargate にしておけば、後からの見直しも容易です。
本記事は AWS 技術認定者 としての実装経験に基づいています。プロジェクトの特性に応じて最適なサービスを選択ください。
※同じようにALBとかAPIGatewayどっち選ぶなんて記事も作ろうと思います。