AWS ECS / EKS / EC2 / Fargate の違いと関係を整理する【2026年5月時点】
はじめに
AWSでコンテナを扱おうとすると、ECS、EKS、EC2、Fargate といったサービス名が次々とでてきます。
「どれがなんなんだっけ？」と混乱したので、AIといっしょに2つの軸で整理してみました。
自分の備忘録として残しておきます。
まず押さえるべきポイント：2つの軸がある
コンテナをAWS上で動かすには、以下の2つの選択が必要です。
| 軸 | 選択肢 | 決めること |
|---|---|---|
| オーケストレーション | ECS or EKS | コンテナをどう管理するか |
| コンピューティング | ECS or Fargate | コンテナをどこで動かすか |
この2つは別々のレイヤーであり、組み合わせて使います。
つまり、以下の4つの組み合わせが存在します。
| EC2（自分で管理） | Fargate （AWS任せ） | |
|---|---|---|
| ECS（AWS独自） | ECS on EC2 | ECS on Fargate |
| EKS（Kubernetes） | EKS on EC2 | EKS on Fargate |
各サービスの役割
オーケストレーション層：ECS と EKS
どちらも「コンテナの管理人」です。
コンテナの起動・停止・スケーリング・ヘルスチェックなどを担います。
| ECS | EKS | |
|---|---|---|
| ベース | AWS独自の仕組み | オープンソースのKubernetes |
| 学習コスト | 低い | 高い（Kubernetesの知識が必要） |
| エコシステム | AWSサービスとの統合が中心 | Helm, Istio, ArgoCD 等が使える |
| マルチクラウド | AWSのみ | 他クラウドのKubernetesと互換性あり |
| 向いてる規模 | 小〜中規模 | 中〜大規模・複雑なマイクロサービス |
ECS（Elastic Container Service）
- AWS独自のコンテナオーケストレーションサービス
- コンテナの起動・停止・スケーリング・ヘルスチェックを管理
- 「クラスター」「サービス」「タスク」という単位で管理する
- Kubernetesの知識がなくても使えるため、学習コストが比較的低い
EKS（Elastic Kubernetes Service）
- オープンソースのKubernetesをAWS上で動かすマネージドサービス
- Kubernetesエコシステム（Helm, Istio, ArgoCD 等）をそのまま活用できる
- 他のクラウド（GCP, Azure等）のKubernetesと互換性があり、マルチクラウド戦略に向いている
- Kubernetes自体の学習コストが高く、ECSと比べて運用負荷も大きい
コンピューティング層：EC2とFargate
どちらも「コンテナの実行場所」です。違いは、サーバーを誰が管理するかです。
| ECS | Fargate | |
|---|---|---|
| 実態 | 仮想マシン（サーバーそのもの） | サーバーレスコンピューティングエンジン |
| サーバー管理 | 自分で行う（OSバッチ, キャパシティ管理等） | 不備（AWSが全て担当） |
| 柔軟性 | 高い（GPU, カーネル設定など自由） | 制限あり（GPU非対応など） |
| OS/ランタイム更新 | 自分で適用 | AWSが自動で行う |
EC2（Elastic Compute Cloud）
- 仮想マシン（サーバーそのもの）を提供するサービス
- GPUの利用や特殊なカーネル設定など、完全にコントロールできる
- その代わり、OSパッチの適用やセキュリティ更新、キャパシティ管理は全て自分で行う必要がある
Fargate
- サーバーレスコンピューティングエンジン
- サーバーの存在を意識する必要がなく、管理も一切不要
- タスクが動いている間だけ課金される（使った分だけ）
- OSやランタイムの更新はAWSが自動で行ってくれる
ECS on EC2 と ECS on Fargate の違い
ECSを例に、コンピューティング層の違いを図で比較します。
ECS on EC2 の場合
EC2インスタンス（サーバー）を自分で用意し、その上でコンテナを動かします。
EC2内ではECSエージェントが常駐しており、ECSからの指示を受け取ってコンテナの起動・停止を行います。
- EC2のOSアップデート、Dockerのインストール、キャパシティ管理はすべて自分で行う
- サーバーの台数やスペックも自分で決める必要がある
ECS on Fargate の場合
サーバーの存在を意識する必要がありません。
ECSがタスクの起動を指示すると、Fargateが裏側でリソースを確保してコンテナを実行します。
- サーバーの管理は一切不要
- OSパッチやランタイム更新もAWSが自動で行う
比較表まとめ
| 観点 | ECS on EC2 | ECS on Fargate |
|---|---|---|
| サーバー管理 | 必要 | 不要 |
| スケーリング | EC2台数を自分で調整 | タスク数を指定するだけ |
| OSパッチ適用 | 自分で行う | AWSが自動で行う |
| コスト（単価） | やすい | EC2より高い |
| コスト（運用込み） | 人件費がかかる | 管理不要で総コストが下がりやすい |
ECSの構成要素と多重度
ECSには複数の概念が階層的に存在します。
以下の図で、それぞれの関係と多重度を示します。
各要素の役割
| 概念 | 役割 | 多重度 |
|---|---|---|
| クラスター | サービスやタスクをまとめるグループ。開発者が作成する。 | 1クラスター → N個のサービス |
| サービス | 「タスクを常にN個保持する」などの管理ルール。自動復旧やスケーリングを担う。 | 1サービス → 1つのタスク定義、N個のタスク |
| タスク定義 | コンテナの設計図。イメージ、CPU、メモリ、環境変数などを定義する。 | 1タスク定義 → N個のタスクが生成 |
| タスク | コンテナの実行単位。タスク定義をもとに起動される。 | 1タスク → 1個以上のコンテナ |
| コンテナ | アプリが実際に動いているプロセス。 | - |
| ECR | コンテナイメージの保管庫。タスク起動時にFargateがpullする。 | - |
定食屋で例えると
イメージしやすいように定食屋で例えてみます。
| 概念 | 定食屋の例え |
|---|---|
| クラスター | 店舗：「渋谷店」「新宿店」のように管理単位を分ける |
| サービス | 店長の指示：「この定食を常に1セット提供し続けて。なくなったらすぐ作り直して |
| タスク定義 | メニュー表：「この定食はご飯・味噌汁・主菜のセット」 |
| タスク | お盆に載った定食1セット |
| コンテナ | ご飯、味噌汁、主菜（お盆の上のそれぞれの品） |
| ECR | 食材倉庫（下ごしらえ済みの食材キットが保管されている。取りに来られたらそのまま渡す） |
ECRとデプロイの流れ
コンテナイメージのビルドからデプロイまでの流れを示します。
ECR に保存されるのは コンテナイメージ（アプリのコード＋動作環境をまとめたパッケージ）です。
ECR（Elastic Container Registry） はコンテナイメージのプライベート保管庫です。
自分からは何もせず、pullされたらイメージを返します。Docker HubのAWS版と考えるとわかりやすいです。
タスク定義は ECS が読み取る設計図です。
ECSがタスク定義の内容(image のECRリポジトリURL、CPU、メモリなど)をFargateに渡し、Fargateはその情報をもとにECRからコンテナイメージをpullしてコンテナを起動します。
ECS vs EKS の用語対応
Kubernetes を知っている方向けに、ECS との用語の対応を示します。
| Kubernetes（EKS） | ECS | 意味 |
|---|---|---|
| Cluster | クラスター | サービスやタスクをまとめるグループ |
| Pod | タスク | コンテナをグループ化した実行単位 |
| Deployment | サービス | Pod/タスクの数や更新を管理 |
| Container | コンテナ | アプリの実体 |
| Container Registry | ECR | イメージ保管庫 |
| Node | EC2/Fargate | コンテナの実行場所 |
選定ガイド
ECS vs EKS
| 観点 | ECS | EKS |
|---|---|---|
| 利用クラウド | AWSのみ | マルチクラウドも視野に入る |
| シンプルさ | シンプル | 学習コスト高い |
| エコシステム | AWS寄り | Kubernetes 資産を活用可能 |
| 向いている規模 | 小〜中規模 | 大規模・複雑なマイクロサービス |
EC2 vs Fargate（機能面）
| 観点 | EC2 | Fargate |
|---|---|---|
| GPU | 対応 | 非対応 |
| OS/カーネル設定 | 自由 | 制限あり |
| サーバー管理 | 必要 | 不要 |
| スケーリング | 自分で台数管理 | タスク数指定のみ |
EC2 vs Fargate（コスト面）
| EC2 | Fargate | |
|---|---|---|
| 課金単位 | インスタンス（サーバー）単位 | タスク（vCPU + メモリ）単位 |
| 課金タイミング | 起動中ずっと（未使用でも課金） | タスクが動いている間だけ |
| 単価 | 安い | EC2より高い |
| サーバー管理コスト | あり（人件費がかかる） | なし |
| 状況 | 安くなる傾向 |
|---|---|
| 24時間365日常時稼働 | EC2 |
| 大量タスクを常時稼働 | EC2 |
| 負荷が変動する・スパイクがある | Fargate |
| 短時間だけ動く処理 | Fargate |
| サーバー管理の人件費も含めた総コスト | Fargate |
まとめ
- ECS/ECKは「コンテナをどう管理するか」を決めるオーケストレーション層
- EC2/Fargateは「コンテナをどこで動かすか」を決めるコンピューティング層
- この2つは別々のレイヤーであり、組み合わせて使う
まずは「ECS on Fargate」が最もシンプルな構成なので、ここから始めて、要件に応じて EKS や EC2 を検討するのがよさそうに思いました。
参考サイト
- Amazon ECS とは - ECS 公式ドキュメント
- Amazon EKS とは - EKS 公式ドキュメント
- AWS Fargate - Fargate 製品ページ
- Amazon ECR とは - ECR 公式ドキュメント
- Amazon EC2 - EC2 製品ページ
- Fargate の料金 - Fargate 料金ページ
- EC2 の料金 - EC2 料金ページ
- Fargate プラットフォームバージョン - プラットフォームバージョンとタスクメンテナンスについて