SAA コンテナ設計パターン（ECS / EKS / Fargate）｜起動タイプと選択基準を体系化
AWS SAA-C03 でコンテナは「管理負荷の軽減 × Kubernetes 必要性 × コスト最適化」の3軸で選択を問われる頻出テーマ。ECS と EKS の違い、Fargate と EC2 起動タイプの比較、4つの代表設計パターン（ECS+Fargate / ECS+EC2 / EKS+Fargate / EKS+EC2）を要件キーワードから即断できる粒度で整理。結論は「Kubernetes 不要かつ管理負荷最小→ECS+Fargate、コスト重視→ECS+EC2、既存 k8s 移行→EKS+EC2」。
コンテナ問題を「ECS か EKS か」だけで解こうとすると、起動タイプ（Fargate / EC2）の選択で毎回引っかかる。 AWS SAA-C03 でコンテナは、配点26%の「高パフォーマンスなアーキテクチャ」と「コスト最適化されたアーキテクチャ」の双方に絡む頻出テーマだ。攻略の核心は、「オーケストレーター（ECS / EKS）× データプレーン（Fargate / EC2）」の2軸のマトリクスで4設計パターンを整理し、要件文にある**「Kubernetes 互換」「運用負荷最小」「コスト重視」「既存ワークロード移行」**といったキーワードから正解を一意に絞ることだ。本記事では4パターンを、どのサービスを使うか・コストと管理の特性はどう違うか・試験ひっかけのポイントはどこか、まで分解する。読み終えればコンテナシナリオ問題をパターンマッチで解けるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：コンテナ選択は「オーケストレーター × データプレーン」の2軸マトリクスで決まる
- ECS の基本構造（タスク・サービス・クラスター）
- EKS の基本構造（Pod・Node・コントロールプレーン）
- Fargate の役割（サーバーレス実行プラットフォーム）
- ECS vs EKS / Fargate vs EC2 比較表
- パターン1：ECS + Fargate（管理負荷最小・中小規模）
- パターン2：ECS + EC2（大規模バッチ・コスト最適化）
- パターン3：EKS + Fargate（Kubernetes 標準・小規模）
- パターン4：EKS + EC2（大規模・既存 Kubernetes 移行）
- 要件キーワード早見表
- 頻出ひっかけパターンと正しい打ち手
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：コンテナ選択は「オーケストレーター × データプレーン」の2軸マトリクスで決まる
SAA-C03 のコンテナ問題を最短で解く骨格は、**「オーケストレーター（ECS / EKS）とデータプレーン（Fargate / EC2）を独立して選び、4パターンのどれかに1本に絞る」**ことだ。
| 軸 | 問いかけ | 判断のキーワード |
|---|---|---|
| オーケストレーター | Kubernetes 互換が必要か？ | 「Kubernetes」「kubectl」「既存 k8s」→ EKS、「AWS ネイティブ」「シンプル」→ ECS |
| データプレーン | 運用負荷を下げたいか？コストを最小化したいか？ | 「サーバーレス」「管理不要」→ Fargate、「コスト最適化」「GPU」「大量定常処理」→ EC2 |
4パターンは「ECS+Fargate → ECS+EC2 → EKS+Fargate → EKS+EC2」という管理複雑度のグラデーションを作る。要件に対して**「必要十分・管理負荷最小」**のパターンを選ぶのが正解の鉄則であり、Kubernetes が不要なのに EKS を選ぶと「過剰設計」として誤答になる。
2. ECS の基本構造（タスク・サービス・クラスター）
Amazon ECS（Elastic Container Service）は、AWS ネイティブのコンテナオーケストレーションサービスだ。Kubernetes を使わずに Docker コンテナを管理できる。
- タスク定義（Task Definition）：コンテナイメージ・CPU・メモリ・ネットワーク設定を定義するテンプレート。1つのタスク定義に複数コンテナを含められる（サイドカーパターン）。
- タスク（Task）：タスク定義から生成される実行単位。1タスク = 1グループのコンテナ。バッチ処理など一回限りの処理に使う。
- サービス（Service）：タスクを指定数維持し続ける仕組み。「常時N個のタスクが動いていること」を保証する。ALB との統合でロードバランシングも担う。
- クラスター（Cluster）：タスク・サービスを実行する論理的なグループ。Fargate と EC2 の両起動タイプを同一クラスターで混在させることも可能。
- 制御プレーンのコスト：ECS のコントロールプレーン自体は無料。課金はデータプレーン（Fargate 利用料 or EC2 インスタンス代）のみ。
3. EKS の基本構造（Pod・Node・コントロールプレーン）
Amazon EKS（Elastic Kubernetes Service）は、AWS が管理するマネージド Kubernetes サービスだ。標準 Kubernetes API との完全互換性を持ち、オンプレや他クラウドの k8s ワークロードをそのまま移行できる。
- Pod：Kubernetes の最小デプロイ単位。1つ以上のコンテナをまとめたもの（ECS のタスクに相当）。
- Node：Pod を実行するワーカーマシン。EKS では Fargate か EC2 インスタンスが Node になる。
- コントロールプレーン：EKS のマスターノード。AWS が管理・パッチ適用・バックアップを担う。**コントロールプレーンのコストは1クラスターあたり約 $0.10/時間（月約 $72）**かかる。
- マネージドノードグループ：EKS の EC2 Node を自動プロビジョニング・パッチ・更新する機能。EC2 データプレーンの管理負荷を大幅に削減。
- Kubernetes 互換性：kubectl・Helm・ArgoCD など標準ツールがそのまま使える。CNCF 認定の Kubernetes のため、オンプレ k8s との親和性が最大の強み。
4. Fargate の役割（サーバーレス実行プラットフォーム）
AWS Fargate は、ECS または EKS のデータプレーンとして機能するサーバーレスコンテナ実行環境だ。EC2 インスタンスのプロビジョニング・パッチ・スケーリングが不要になる。
- 対応オーケストレーター：ECS と EKS の両方で利用可能。「ECS on Fargate」「EKS on Fargate」と呼ぶ。
- 課金モデル：タスク/Pod が使用した vCPU・メモリの秒単位課金。アイドル時はほぼ課金なし（最低1分）。
- 管理不要の範囲：ホスト OS・カーネル・ハイパーバイザーのパッチ・スケーリング・容量計画をすべて AWS が担う。
- 制約事項：GPU インスタンスは非対応。特権コンテナ（privileged mode）の実行が制限される。ホストネットワーク（host network mode）は ECS Fargate では非対応。
- セキュリティ：各タスク/Pod が独立したカーネル境界で動作（マルチテナントの強い分離）。
5. ECS vs EKS / Fargate vs EC2 比較表
| 評価項目 | ECS + Fargate | ECS + EC2 | EKS + Fargate | EKS + EC2 |
|---|---|---|---|---|
| Kubernetes 互換 | ✕ 不要 | ✕ 不要 | ◎ 完全互換 | ◎ 完全互換 |
| OS 管理 | 不要（AWS 管理） | 必要（ユーザー管理） | 不要（AWS 管理） | △ マネージドノードグループで軽減 |
| コントロールプレーン費用 | 無料 | 無料 | 月 $72〜 | 月 $72〜 |
| GPU サポート | ✕ 非対応 | ◎ 対応 | ✕ 非対応 | ◎ 対応 |
| コスト最適化 | △ アイドル時は安価、常時稼働は割高 | ◎ Reserved/Spot で大幅削減可能 | △ Fargate 料金＋EKS 料金 | ◎ EC2 最適化＋EKS（k8s 標準ツール活用） |
| 管理の複雑さ | ◎ 最もシンプル | △ インスタンス管理が必要 | △ k8s 知識が必要 | ✕ 最も複雑 |
| 主なユースケース | Web API・中小規模バッチ・スタートアップ | 大規模定常処理・コスト最適化・GPU | k8s 互換・開発チームの k8s スキル活用 | オンプレ k8s 移行・大規模 k8s ワークロード |
6. パターン1：ECS + Fargate（管理負荷最小・中小規模）
要件のキーワード
- 「インフラ管理を最小限にしてコンテナを動かしたい」
- 「Kubernetes は不要、AWS ネイティブでシンプルに構成したい」
- 「スタートアップ / 少人数チームでインフラ専任がいない」
- 「スパイク性のあるトラフィックで、アイドル時間が多い」
アーキテクチャ
ユーザー
↓
ALB（Application Load Balancer）
↓
ECS サービス（タスク数を ALB ターゲットに登録）
├─ Fargate タスク ×N（vCPU / メモリ を秒課金）
└─ ECR（コンテナイメージを格納）
スケーリング：ECS サービスオートスケーリング（CPU / ALB リクエスト数）
ログ：CloudWatch Logs へ自動転送試験での正解条件
- 「最小の運用オーバーヘッド」「サーバーレス」「インスタンス管理不要」→ Fargate 確定。
- 「Kubernetes の機能は不要」「AWS マネージドでシンプルに」→ ECS。
- 「コスト最適化」が要件でも、アイドル時間が多いならECS+Fargate の方が EC2 より安くなるケースがある。
7. パターン2：ECS + EC2（大規模バッチ・コスト最適化）
要件のキーワード
- 「大量の定常ワークロードを処理するため、コスト最適化が最優先」
- 「Reserved Instance / Savings Plans を活用してコストを削減したい」
- 「GPU インスタンス（p3 / g4 等）でコンテナを実行する必要がある」
- 「特権コンテナ・ホストネットワークを使うカスタムワークロードがある」
アーキテクチャ
ECS クラスター
├─ EC2 Auto Scaling グループ（m5.2xlarge × N）
│ （ECS Agent が自動インストール済み）
├─ ECS サービス（常時稼働 Web 層）
└─ ECS バッチタスク（スポットインスタンス活用）
コンテナイメージ：ECR
ログ：CloudWatch Logs / CloudWatch Container Insights試験での正解条件
- 「Reserved Instance で ECS の実行コストを下げたい」→ EC2 起動タイプが必要（Fargate は RI 割引が効かない）。
- 「GPU を使う機械学習推論コンテナ」→ EC2（g4dn 等）が必須。Fargate は非対応。
- 「常時高負荷・CPU/メモリ使用率が常に高い」→ Fargate の秒課金より EC2+RI の方が安くなる傾向。
8. パターン3：EKS + Fargate（Kubernetes 標準・小規模）
要件のキーワード
- 「開発チームが Kubernetes に精通しており、kubectl / Helm でデプロイしたい」
- 「インフラ管理は最小限にしつつ Kubernetes の標準 API を使いたい」
- 「他クラウドや別 AWS リージョンに同じ k8s 構成を展開したい（ポータビリティ）」
- 「小〜中規模の k8s ワークロードを迅速に立ち上げたい」
アーキテクチャ
EKS クラスター（コントロールプレーン：AWS 管理）
└─ Fargate プロファイル（namespace 単位で Fargate を紐付け）
└─ Pod × N（各 Pod が独立した Fargate 環境で稼働）
デプロイ：kubectl apply / Helm chart
ロードバランシング：AWS Load Balancer Controller + ALB
ログ：Fluent Bit → CloudWatch / OpenSearch試験での正解条件
- 「Kubernetes ネイティブツール（Helm / ArgoCD / Istio）を使いたい」→ EKS 必須。
- 「Node 管理をなくしたい」→ Fargate プロファイルで Node レスに。
- ただし「EKS + Fargate でできないこと」（DaemonSet・GPUなど）に注意（後述）。
9. パターン4：EKS + EC2（大規模・既存 Kubernetes 移行）
要件のキーワード
- 「オンプレミスの Kubernetes ワークロードを AWS に移行したい」
- 「大規模な k8s クラスターを GPU / 高メモリインスタンスで実行したい」
- 「DaemonSet（ログ・モニタリングエージェント）を全 Node に展開する必要がある」
- 「StatefulSet + EBS を使った有状態アプリケーション（データベース等）を動かしたい」
アーキテクチャ
EKS クラスター（コントロールプレーン：AWS 管理）
└─ マネージドノードグループ（m5.2xlarge Auto Scaling）
├─ DaemonSet（DatadogAgent / Fluent Bit 全 Node に1つ）
├─ Deployment（Web アプリ Pod）
└─ StatefulSet（Redis / Cassandra + EBS PV）
クラスターオートスケーラー：Karpenter または Cluster Autoscaler
コンテナイメージ：ECR
IAM for Service Accounts（IRSA）でPod に最小権限付与試験での正解条件
- 「オンプレの k8s を AWS にリフト＆シフト」→ EKS + EC2 が最適（ツール・マニフェストをほぼそのまま再利用）。
- 「GPU での推論ジョブ + k8s スケジューリング」→ EKS + EC2（g4dn 等）。
- 「マネージドノードグループ」を選ぶと Node のパッチ・更新が半自動化され、運用負荷を EC2 直接管理より大きく削減できる。
10. 要件キーワード早見表
| 要件文のキーワード | 正解パターン | 理由 |
|---|---|---|
| 「最小の運用オーバーヘッド」「インスタンス管理不要」 | ECS + Fargate | サーバーレスでインフラ管理ゼロ |
| 「Kubernetes 互換」「kubectl を使いたい」 | EKS（Fargate or EC2） | ECS は k8s 非互換 |
| 「コスト最適化」「Reserved Instance」 | ECS + EC2 | Fargate は RI 割引非対応 |
| 「GPU インスタンスでコンテナ実行」 | ECS + EC2 or EKS + EC2 | Fargate は GPU 非対応 |
| 「オンプレ Kubernetes 移行」 | EKS + EC2 | k8s マニフェストをそのまま利用可能 |
| 「DaemonSet を使いたい」 | EKS + EC2 | EKS + Fargate は DaemonSet 非対応 |
| 「スタートアップ・少人数チーム」 | ECS + Fargate | 最もシンプルで運用知識最小 |
| 「スポットインスタンスで大規模バッチ」 | ECS + EC2 or EKS + EC2 | Fargate Spot より EC2 Spot の方が制御が細かい |
| 「コンテナを ECR に保存して ECS で実行」 | ECS（Fargate or EC2） | ECR は ECS / EKS 両対応だが、ECS が最も統合がシンプル |
| 「Helm Chart でデプロイしたい」 | EKS（Fargate or EC2） | Helm は Kubernetes ツール |
11. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：「最小コスト = ECS + Fargate」とは限らない
「コスト最適化」という要件を見て ECS + Fargate を選ぶのが罠になることがある。常時高負荷のワークロード（CPU 使用率80%以上が常態）では、Fargate の秒課金より EC2 + Reserved Instance の方が安くなる。問題文に「スパイク」「アイドル時間あり」→ Fargate、「24/7 定常高負荷」→ EC2 と読み分ける。
ひっかけ2：「EKS を使えば EC2 管理が不要になる」は誤り（データプレーンによる）
EKS はコントロールプレーンを AWS が管理するだけで、EC2 データプレーンを使うとノード（EC2）の管理はユーザー側に残る（マネージドノードグループを使うと軽減されるが完全にはなくならない）。「EKS を使えばすべてサーバーレスになる」という勘違いを誘う選択肢に注意。完全なサーバーレス = EKS + Fargate のみ。
ひっかけ3：「ECR はコンテナのビルドにも使える」は誤り
Amazon ECR はコンテナイメージの保存・配信専用のレジストリサービスだ。コンテナのビルドは行わない。ビルドには AWS CodeBuild を使う。「ECR でビルドしてデプロイ」という選択肢は誤答。
ひっかけ4：「ECS のサービスとタスクの違い」
| 比較軸 | ECS タスク | ECS サービス |
|---|---|---|
| 実行性質 | 1回限り（バッチ処理等） | 常時N個を維持 |
| ALB 統合 | ✕ 不可 | ◎ ALB ターゲット登録可能 |
| Auto Scaling | ✕ なし | ◎ サービスオートスケーリング対応 |
| 使いどころ | マイグレーション・バッチ・1回実行 | Web API・常時稼働マイクロサービス |
「ALB でロードバランシングしながら常時稼働させたい」→ ECS サービスが必要。タスクを直接起動するだけでは ALB のターゲットにならない。
12. 次のアクション チェックリスト
- 「ECS vs EKS」と「Fargate vs EC2」を2軸独立で判断できるか確認
- 「Kubernetes 不要・管理負荷最小 → ECS + Fargate」を即答できるか
- 「GPU・特権コンテナ → Fargate 非対応 → EC2 起動タイプ」を覚えたか
- ECS のタスクとサービスの違い（ALB 統合・常時稼働 vs 1回実行）を説明できるか
- EKS のコントロールプレーン料金（月 $72〜）と ECS は無料の違いを覚えたか
- 「DaemonSet → EKS + Fargate では非対応 → EC2 必要」を理解したか
- マネージドノードグループの役割（EC2 Node のパッチ・ドレイン自動化）を確認
- 模擬問題でコンテナシナリオを3問以上解いて正答確認
13. 関連記事
- Amazon EKS とは？マネージド Kubernetes の特徴と使いどころ
- AWS Fargate とは？サーバーレスコンテナの仕組みと料金体系
- ECS タスクとサービスの違い｜バッチ処理と常時稼働の使い分け
- Amazon ECR とは？コンテナイメージレジストリの基本
- SAA Lambda / サーバーレス設計パターン
- SAA Auto Scaling / ELB 設計パターン