「新しいシステムはコンテナで」と決まったあと、実務で必ず出るのが「ECS か EKS か」です。そしてその手前には、「そもそもコンテナにするのか、EC2 のままでいいのか、Lambda にできないのか」があります。ネットには「EKS は本格的、ECS は簡単」のような言い方があふれていますが、それでは判断の根拠を人に説明できません。この記事は、この判断を「何を自分で持ちたいか」と「チームが持っている知識」の2軸で整理し、判断を記録として残すところまでを扱います。
この記事の結論
- 判断の軸は2つ。運用で何を自分で持ちたいか（責任の範囲）と、チームがすでに持っている知識です。「どれが高機能か」では決まりません。
- EC2 → ECS on EC2 → ECS on Fargate → Lambda の順に、自分で持つものが減り、自由度も減ります。
- ECS と EKS の違いは「オーケストレータを誰の流儀で動かすか」です。ECS は AWS の流儀、EKS は Kubernetes の流儀。機能の差より、学習と運用のコストの差が大きい。
- Kubernetes を選ぶ理由は「Kubernetes の資産・ツール・人がある」こと。無ければ ECS on Fargate から始めるのが執筆者の判断です。
- 判断は ADR（Architecture Decision Record）として、「何を、なぜ、何を捨てて」を残します。あとで見直せない判断は、判断ではありません。
判断の軸は「何を自分で持ちたいか」
クラウドとは何かで書いた IaaS・PaaS の区分は、コンテナの判断でも同じ形で効きます。選択肢を「自分で持つもの」の多い順に並べます。
WHAT YOU OWN何を自分で持つか
下に行くほど持つものが減り、自由度も減る
-
EC2
OS・ミドルウェア・アプリ・スケールの仕組みを全部持つ
既存のサーバーをそのまま移す、特殊な OS 設定
-
ECS on EC2
コンテナと、それを動かす EC2 を持つ
GPU が要る、予約で安くしたい
-
ECS on Fargate
コンテナ（イメージ・タスク定義）だけを持つ
一般的な Web・API・バッチ。小さいチームの最初の選択
-
Lambda
コードだけを持つ
イベントに反応する短い処理。15 分の上限
| 選択肢 | 自分で持つもの | AWS が持つもの | 向くもの |
|---|---|---|---|
| EC2 | OS・ミドルウェア・アプリ・スケールの仕組み | ハードウェア・仮想化 | 既存のサーバーをそのまま移す、特殊な OS 設定が要る |
| ECS on EC2 | コンテナ、コンテナを動かす EC2（OS の更新・容量） | オーケストレーション | GPU や特定のインスタンスタイプが要る、EC2 の予約で安くしたい |
| ECS on Fargate | コンテナ（イメージ・タスク定義） | コンテナを動かす機械の全部 | 一般的な Web・API・バッチ。運用で持つものを最小にしたい |
| Lambda | コード | 実行環境の全部 | イベントに反応する短い処理、負荷の波が大きい処理 |
下に行くほど、OS の更新・パッチ・容量の管理といった運用の仕事が減ります。その代わり、「この設定を変えたい」の自由度も減ります。迷ったら、いまのチームで「持てる」範囲の一番下を選ぶ。持てないものを持つと、運用で必ず破綻します。
LAYERS YOU OWN何を自分で持つか
右に行くほど、持つものが減る
EC2
- ハードウェア
- OS（更新・パッチ）
- コンテナの実行環境
- コンテナ（イメージ・タスク定義）
- コード
ECS on EC2
- ハードウェア
- OS（更新・パッチ）
- コンテナの実行環境
- コンテナ（イメージ・タスク定義）
- コード
ECS on Fargate
- ハードウェア
- OS（更新・パッチ）
- コンテナの実行環境
- コンテナ（イメージ・タスク定義）
- コード
Lambda
- ハードウェア
- OS（更新・パッチ）
- コンテナの実行環境
- コンテナ（イメージ・タスク定義）
- コード
自分で持つAWS が持つ
Lambda には実行時間の上限（15 分）や、起動時の遅延（コールドスタート）があります。常に一定の負荷がある処理や、長い処理は、Lambda より Fargate のほうが素直です。「サーバーレスだから運用が無い」ではなく、「サーバーの運用が無い代わりに、関数の運用がある」と理解します。
ECS と EKS の違いは「誰の流儀で動かすか」
コンテナにすると決めたら、次はオーケストレータ（複数のコンテナをどこで何個動かし、落ちたら立て直す仕組み）を選びます。AWS には2つあります。
- ECS（Elastic Container Service）は、AWS が独自に作ったオーケストレータです。概念は「クラスター・サービス・タスク定義・タスク」の4つで、IAM・ALB・CloudWatch との統合が最初から組み込まれています。
- EKS（Elastic Kubernetes Service）は、Kubernetes の制御プレーン（API サーバーなど）を AWS が運用してくれるサービスです。中身は Kubernetes そのもので、概念は「Pod・Deployment・Service・Ingress」など Kubernetes の語彙です。
| 項目 | ECS | EKS |
|---|---|---|
| 流儀 | AWS 独自 | Kubernetes（オープンソース、他のクラウドやオンプレと共通） |
| 覚える概念の数 | 少ない（4つ） | 多い（Kubernetes 本体＋AWS との連携部分） |
| AWS サービスとの統合 | 組み込み | アドオンやコントローラを入れて設定する |
| 制御プレーンの料金 | 無料（動かすタスクの分だけ） | クラスターごとに時間課金がある |
| 持ち運び | AWS の中だけ | Kubernetes が動く場所ならどこでも |
| エコシステム | AWS の範囲 | Helm・Operator・多数の OSS ツール |
| 運用で自分が持つもの | タスク定義とサービスの設定 | 上に加えて、Kubernetes 自体のバージョン更新、アドオンの更新、マニフェストの管理 |
機能の差で選ぼうとすると決まりません。どちらでも Web サービスは動きます。差が出るのは、学習と運用にかかるコストと、それを払う理由があるかです。
ECS VS EKS誰の流儀で動かすか
機能の差ではなく、学習と運用のコストの差
ECS
AWS 独自の流儀
- 覚える概念は4つ（クラスター・サービス・タスク定義・タスク）
- IAM・ALB・CloudWatch との統合が組み込み
- 制御プレーンは無料
- 持ち運びは AWS の中だけ
EKS
Kubernetes の流儀
- Kubernetes 本体＋AWS との連携部分を覚える
- アドオンやコントローラを入れて設定する
- クラスターごとに時間課金
- Helm・Operator・多数の OSS。他のクラウドでも同じ流儀
CHECK 1ここまでの確認
EC2・ECS on EC2・ECS on Fargate・Lambda を並べたとき、「自分で持つもの」が一番少ないのはどれ?
答えと解説
答え: 3. Lambda
Lambda はコードだけを持ちます。その代わり実行時間の上限やコールドスタートがあり、常に一定の負荷がある処理は Fargate のほうが素直です。
Kubernetes を選ぶ理由と、選ばない理由
執筆者が EKS を選ぶのは、次のどれかがあるときです。
EKS（Kubernetes）を選ぶ理由
- すでに Kubernetes で動いている資産があり、それを AWS に移す
- Helm チャートや Operator で配布されているツールに依存している（データ基盤や ML 基盤に多い）
- 複数のクラウドやオンプレと同じ流儀で動かす必要がある
- チームに Kubernetes を運用できる人がすでにいて、その知識を活かしたい
逆に、これらが無いのに EKS を選ぶと、「Kubernetes を学ぶこと」自体が仕事になり、本来のサービスの開発と運用にかける時間が減ります。Kubernetes は、それを使う理由がある組織には強力ですが、「本格的だから」「流行っているから」で選ぶと、運用で持つものが一気に増えます。
ECS on Fargate を最初に選ぶ理由は、その逆です。運用で持つものが一番少なく、IAM・ALB・CloudWatch との統合が素直で、覚える概念が4つ。小さいチームが最初に選ぶ形として、執筆者はこれを勧めます。あとで Kubernetes が要る理由が出てきたら、そのときに移ればよく、コンテナイメージはそのまま使えます。
TWO AXES2軸で決める
小さいチームの最初の選択は ECS on Fargate
自分で持てる運用の範囲 →
ECS on EC2
資産は無いが、GPU や予約で機械を持つ理由がある
EKS on EC2
資産があり、機械も持てる
ECS on Fargate
資産が無く、持つものを最小に。ここから始める
EKS on Fargate
資産はあるが、機械は持ちたくない
Kubernetes の資産・ツール・人 →
Fargate と EC2 起動タイプ
ECS でも EKS でも、コンテナを動かす「機械」を Fargate（AWS が持つ）にするか、EC2（自分が持つ）にするかを選べます。
- Fargate は、OS もインスタンスも見えません。タスクに CPU とメモリを指定すれば、AWS が機械を用意します。OS の更新・容量の管理が要らない代わりに、GPU や特定のインスタンスタイプは使えず、同じ性能あたりの単価は EC2 より高めです。
- EC2 起動タイプ は、コンテナを動かす EC2 を自分で用意します。GPU が要る、予約（Savings Plans / RI）で安くしたい、インスタンスの中に入って調べたい、といった理由があるときに選びます。その代わり、EC2 の運用（EC2 とは何かで書いた OS の更新・容量）が戻ってきます。
判断は「機械を持つ理由があるか」の一点です。無ければ Fargate です。
CHECK 2ここまでの確認
ECS と EKS の一番の違いはどれ?
答えと解説
答え: 2. オーケストレータを AWS の流儀で動かすか、Kubernetes の流儀で動かすか
どちらでも Web サービスは動きます。差は機能ではなく、学習と運用のコストと、それを払う理由があるかです。
判断を記録として残す
この種の判断で一番大事なのは、決めることより「なぜそう決めたか」を残すことです。半年後に「なぜ EKS じゃないのか」と聞かれて答えられなければ、その判断は見直せません。
ADR（Architecture Decision Record）は、1つの判断を1枚の短い文書にする型です。
| 項目 | 書くこと | 例 |
|---|---|---|
| 状況 | 何を決める必要があったか | 新しい API 基盤のコンピュートを選ぶ |
| 選択肢 | 検討したもの | EC2 / ECS on Fargate / EKS / Lambda |
| 決定 | 何を選んだか | ECS on Fargate |
| 理由 | なぜか（軸で書く） | チームに Kubernetes の運用経験が無い。持つものを最小にしたい。GPU は不要 |
| 捨てたもの | 選ばなかったことで失うもの | Kubernetes のエコシステム。他クラウドへの持ち運び |
| 見直す条件 | いつ再検討するか | Kubernetes 依存のツールが必須になったとき。チームに運用できる人が入ったとき |
「捨てたもの」と「見直す条件」を書くのが要点です。判断は正解を当てることではなく、捨てたものを分かったうえで選び、見直せるようにすることです。この考え方は、段4のトレードオフの考え方でさらに扱います。
CHECK 3ここまでの確認
この記事が挙げた、EKS（Kubernetes）を選ぶ理由に当てはまらないのはどれ?
答えと解説
答え: 3. 本格的で、流行っているから
「本格的だから」「流行っているから」で選ぶと、運用で持つものが一気に増えます。資産・ツール・人のどれかがあるときに選びます。
まとめ
コンテナ基盤の判断は、「何を自分で持ちたいか」と「チームが持っている知識」の2軸で決めます。EC2 → ECS on EC2 → ECS on Fargate → Lambda の順に持つものが減り、自由度も減ります。ECS と EKS は流儀の違いで、Kubernetes を選ぶ理由（資産・ツール・人）が無ければ ECS on Fargate から始めます。判断は ADR で「捨てたもの」と「見直す条件」まで残します。動かしたあとの「何を見るか」は、次の監視設計で扱います。
参照ソース
- Amazon ECS とは（AWS ECS 開発者ガイド） — クラスター・サービス・タスク定義・タスクの概念と、Fargate / EC2 起動タイプの根拠。2026年9月時点の記載
- AWS Fargate（AWS ECS 開発者ガイド） — Fargate では利用者がインスタンスを管理しないことの根拠
- Amazon EKS とは（AWS EKS ユーザーガイド） — EKS が Kubernetes の制御プレーンを AWS が運用するサービスであることの根拠
- Kubernetes の概要（Kubernetes 公式ドキュメント） — Pod・Deployment・Service など Kubernetes の概念の一次情報
- Lambda クォータ（AWS Lambda 開発者ガイド） — 関数の実行時間の上限（15 分）の根拠
- Architecture Decision Records（adr.github.io） — ADR の型（状況・決定・結果）の出典
