現場で「うちは EKS で動いている」「Kubernetes のマニフェストを直して」と言われ、クラスター・ノード・Pod の語に置いていかれていませんか。ECS の経験があっても、EKS は「複雑なもの」と片づけられがちで、AWS が持つ範囲と自分が持つ範囲の境目が見えにくいものです。この記事では、その境目を中心に Amazon EKS を整理します。
この記事の結論
- EKS は、AWS が運用する Kubernetes のコントロールプレーンを借りるサービスです。Kubernetes 本体の仕様は変えないので、Kubernetes 準拠のツールやマニフェストをそのまま使えます。
- コントロールプレーンは 1 クラスターごとに独立していて、3 つの AZ に分散して置かれます（API サーバー 2 つ以上、etcd 3 つ）。
- アプリを動かすノードは、Auto Mode・Fargate・マネージドノードグループ・Karpenter・セルフマネージド・ハイブリッドノードから選べます。選び方で「自分が持つ範囲」が変わります。
- 権限は Kubernetes の RBAC と IAM の 2 層で決まります。IAM は「クラスターの API に入れるか」と「Pod が AWS を呼べるか」に効きます。
- 料金は、クラスター単位の料金に加えて、ノードなどの実リソースを別に払う形です。金額は料金ページで確認します。
- ECS との違いは、AWS 独自の API か、Kubernetes という共通の仕様か、にあります。選び分けは別の記事に送ります。
Amazon EKS とは何か｜「Kubernetes のコントロールプレーンを AWS が持つ」サービス
Amazon EKS（Elastic Kubernetes Service）は、AWS が提供するマネージドな Kubernetes のサービスです。Kubernetes は、コンテナを多数のサーバーにまたがって動かし、数を保ち、入れ替えるためのオープンソースの仕組みです。その頭脳にあたる部分（コントロールプレーン）を、AWS が運用してくれるのが EKS です。
大事なのは、EKS が Kubernetes の仕様を変えたものではない点です。公式ドキュメントでも、EKS は Kubernetes 準拠のツールやプラグインをそのまま使える、という位置づけで説明されています。オンプレミスで Kubernetes を使っていた組織が、既存のマニフェストや Helm チャートを活かして移行する先として EKS が挙がるのは、この性質のためです。練習問題でも「Kubernetes を使うコンテナ基盤は EKS」「既存のマニフェストをそのまま使える」という論点が繰り返し出てきます。
一方で、「EKS にすれば全部 AWS がやってくれる」というわけではありません。AWS が持つのはコントロールプレーンで、ノード（アプリが載るサーバー）やアプリそのものをどこまで AWS に任せるかは、後述のとおり選び方次第です。公式ドキュメントでは、標準の使い方に加えて、ノード側の運用も AWS に寄せる EKS Auto Mode が紹介されています。なお、Argo CD などを AWS 側で動かす EKS Capabilities という仕組みもありますが、この記事では扱いません。
CHECK 1ここまでの確認
EKS で、AWS が運用する部分として正しいのはどれか?
答えと解説
答え: 1. Kubernetes のコントロールプレーン
EKS が借りられるのは Kubernetes のコントロールプレーンです。ノードやアプリをどこまで AWS が持つかは、ノードの種類（Auto Mode など）で変わります。「EKS とは何か」の章を読み直してください。
Kubernetes を 1 枚で｜クラスター・ノード・Pod・マニフェストは何をするか
EKS の用語の大半は Kubernetes の用語です。まず最低限の語を押さえます。
| 語 | 何か | ECS で近いもの |
|---|---|---|
| クラスター | 管理対象のまとまり。コントロールプレーンとノードを合わせた全体 | クラスター |
| コントロールプレーン | 「何をどこで動かすか」を決めて記録する頭脳（API サーバー・etcd など） | ECS が内部で持つ制御部分 |
| ノード | Pod を実際に載せて動かすサーバー（EC2 など） | コンテナインスタンス（EC2 起動タイプの場合） |
| Pod | 一緒に動かすコンテナの最小単位。1 つ以上のコンテナを含む | タスク |
| マニフェスト | 「こういう状態にしたい」を書いた YAML などの宣言 | タスク定義とサービスの設定 |
| Deployment | Pod の数を保ち、入れ替えを管理する部品 | サービス |
Kubernetes の特徴は、利用者が「あるべき状態」をマニフェストで宣言し、コントロールプレーンが実際の状態をそれに近づけ続ける点です。Pod が落ちれば、Deployment が宣言された数になるよう新しい Pod を作ります。この考え方は ECS のサービスと似ていますが、宣言の書式と API が Kubernetes という共通の仕様になっています。
なお、Pod は VPC のアドレスを使う設計です。そのため、Pod の数が増えるとサブネットの IPv4 アドレスが足りなくなることがあります。対処にはセカンダリ CIDR とカスタムネットワーキングの組み合わせがあり、ネットワーク設計の話になるため、ここでは「アドレスの消費先が Pod にもある」と覚えておけば十分です。
EKS では誰が何を持つのか｜コントロールプレーンとデータプレーンの分担
Kubernetes の構成は、大きく 2 つに分けて考えると整理できます。
- コントロールプレーン: 全体を管理する側。API サーバーや etcd（クラスターの状態を記録するデータベース）が動く
- データプレーン: アプリを実際に動かす側。ノードと、その上の Pod
EKS では、コントロールプレーンを AWS が運用します。公式ドキュメントによれば、コントロールプレーンは 1 クラスターごとに独立していて、他のクラスターや他の AWS アカウントと共有されません。API サーバーは 2 つ以上、etcd は 3 つで構成され、3 つの AZ に分散して置かれます。自分で Kubernetes を組む場合に、etcd の冗長化やバックアップ、API サーバーの更新で悩む部分を、AWS が引き受けると考えてください。
WHO OWNS WHATEKS の分担
コントロールプレーンは常に AWS。ノードから上は選び方しだい
ノードを自分で持つ
- コントロールプレーン — API サーバー・etcd（3 つの AZ に分散）
- ノード — Pod を載せる EC2 / Fargate など
- Pod とアプリ — マニフェストで宣言する
Auto Mode など
- コントロールプレーン — API サーバー・etcd（3 つの AZ に分散）
- ノード — Pod を載せる EC2 / Fargate など
- Pod とアプリ — マニフェストで宣言する
自分が持つ層AWS が持つ層
データプレーンのうち、ノードと Pod の中身は、選び方で責任が変わります。Pod の中のアプリとマニフェストは、どの選び方でも利用者のものです。ノードを EC2 で自分で持つなら、OS の更新や容量の確保も自分の仕事になります。一方、Auto Mode のようにノード側を AWS に寄せれば、自分の担当はアプリとマニフェストの側に絞られます。
セキュリティの面でも、持つ範囲が運用に効きます。たとえばコンテナ内での不審なプロセスの実行といった OS レベルの振る舞いは、Amazon GuardDuty の Runtime Monitoring で見られます。対象には EKS・ECS（Fargate）・EC2 が含まれます。詳しい設定はこの記事の範囲外です。
CHECK 2ここまでの確認
EKS のコントロールプレーンの置かれ方として正しいのはどれか?
答えと解説
答え: 2. 1 クラスターごとに独立し、3 つの AZ に分散して置かれる
コントロールプレーンはクラスターごとに独立していて、複数クラスターで共有されません。3 つの AZ に分散するので、単一 AZ の障害に引きずられにくい作りです。「分担」の章を読み直してください。
ノードはどう選ぶのか｜Auto Mode・Fargate・マネージドノードグループ・セルフマネージドの違い
公式ドキュメントでは、EKS で Pod を動かすノードの選択肢として、次のものが挙げられています。
| 選び方 | ノードの正体 | 自分が持つ範囲の目安 |
|---|---|---|
| セルフマネージドノード | 自分で用意した EC2 | EC2 の起動・OS・更新・容量まで自分 |
| マネージドノードグループ | EC2 のノード群を AWS が作成・更新する仕組みを使う | ノードグループの設定や更新のタイミングは自分が決める |
| AWS Fargate | サーバーを意識せず Pod 単位で動かす | ノードの管理は不要。Pod の定義とネットワークの設計は自分 |
| EKS Auto Mode | ノードの用意・スケール・更新まで AWS が運用する | アプリとマニフェストが中心 |
| Karpenter | Pod の需要に合わせてノードを増減するオープンソースの仕組み | Karpenter の設定と運用を自分が持つ |
| ハイブリッドノード | オンプレミスのサーバーをクラスターにつなぐ | 物理サーバーの運用は自分 |
NODE OPTIONSノードの選び方
自分で持つ範囲が広い順に、セルフマネージドから Auto Mode まで
-
広い
セルフマネージド — EC2 の起動から更新まで自分
細かい制御が要るとき
-
↓
マネージドノードグループ — ノード群の作成・更新を AWS の仕組みで
設定と更新のタイミングは自分
-
↓
Fargate — ノードを意識せず Pod 単位で動かす
Pod の定義とネットワークは自分
-
狭い
Auto Mode — ノードの用意・スケール・更新まで AWS
アプリとマニフェストが中心
選ぶときの考え方は、ECS の Fargate と EC2 起動タイプの選び方に近く、「ノードの面倒を自分で見たいか」が軸になります。ノードの種類や細かい設定を自分で決めたい、特殊なインスタンスを使いたいといった理由があれば、ノードを自分で持つ側に寄ります。そうした理由がなければ、持つ範囲の小さい側から検討するのが自然です。1 つのクラスターに複数の方式を併用することもできるため、「どれか 1 つ」と決め切る必要はありません。
ここで挙げた値や機能の細部は、改定で変わりやすい領域です。実際の選択では、必ず公式ドキュメントの最新の比較を確認してください。
CHECK 3ここまでの確認
ノードの OS の管理まで、できるだけ AWS に任せたいときに向く選び方はどれか?
答えと解説
答え: 2. Auto Mode（または Fargate）
セルフマネージドは EC2 の起動からノードの更新まで自分で持つ選び方です。Auto Mode や Fargate は、ノード側の運用を AWS に寄せられます。「ノードはどう選ぶのか」の章を読み直してください。
権限はどこで決まるのか｜IAM と Kubernetes RBAC の 2 層
EKS の権限は、2 つの仕組みが重なっています。
- AWS 側の IAM: 誰がクラスターを作れるか、クラスターの API に入れるか、Pod が S3 などの AWS サービスを呼べるか
- Kubernetes 側の RBAC: クラスターの中で、誰がどの Pod や Deployment を見たり変えたりできるか
つまり、IAM でクラスターに入れても、Kubernetes の RBAC で許されなければ、中のリソースは操作できません。逆に、RBAC だけ整えても、そもそも入口で IAM が許していなければ入れません。「入れるか」は IAM、「入ってから何ができるか」は RBAC、と分けて考えると混乱が減ります。
もう 1 つの論点が、Pod が AWS のサービスを呼ぶときの権限です。ノードの IAM ロールに権限を付けると、そのノードに載った Pod がすべて同じ権限を持ちます。これを避けるには、Kubernetes のサービスアカウントを IAM のロールと結び付け、Pod ごとに権限を絞る仕組みを使います。ECS で、タスクロールをタスクごとに付けたのと同じ発想です。ノード全体に権限を付けない、というのが原則です。
権限まわりで避けたいこと
- Pod が必要とする AWS の権限を、ノードの IAM ロールにまとめて付ける
- IAM で入れたことを理由に、RBAC の確認を省く
CHECK 4ここまでの確認
Pod から AWS のサービスを呼ぶ権限を、ノード全体の IAM ロールに付けるのを避けるのはなぜか?
答えと解説
答え: 1. ノード上のすべての Pod が同じ権限を持ってしまうから
ノードのロールに権限を足すと、同じノードに載った別の Pod も使えてしまいます。Pod 単位で IAM と結ぶ仕組みを使い、権限を Pod ごとに絞ります。「権限はどこで決まるのか」の章を読み直してください。
ECS と何が違うのか｜用語の対応表と、EKS が選ばれる理由
ECS を知っている人にとって、EKS の理解は「用語の対応」から入ると早く進みます。
ECS VS EKS用語の対応
同じ「コンテナを保つ」でも、言葉と API が違う
Amazon ECS
AWS 独自の API と概念
- タスク定義 — 設計図
- タスク — 実行中のコンテナの組
- サービス — 決めた数を保つ
Amazon EKS
Kubernetes という共通の仕様
- マニフェスト — あるべき状態の宣言
- Pod — 一緒に動かす最小単位
- Deployment — Pod の数を保つ
対応はあくまで「近い」にとどまり、同じものではありません。たとえば ECS のタスク定義には、ロールや CPU・メモリの指定が入ります。Kubernetes のマニフェストは、Pod や Deployment といった複数の種類のリソースに分かれて書かれます。
根本的な違いは、ECS が AWS 独自の API と概念で動くのに対し、EKS は Kubernetes という共通の仕様の上に載る点です。EKS が選ばれる典型的な理由は次のとおりです。
- すでに Kubernetes を使っていて、マニフェストや Helm チャート、Kubernetes 向けの監視ツールを活かしたい
- Kubernetes 準拠のツールや人材の知識を、AWS 以外にもつなげたい
- 組織として Kubernetes を共通の基盤にしている
逆に言えば、そうした背景がない場合、覚える語が増えるぶん EKS は学習の負担が重くなります。どちらを選ぶかの判断軸は、別の記事で扱います。
READ ALSO — 実務向け・段3 基盤
ECS か EKS か、それとも EC2 か Lambda か｜コンテナ基盤の判断を「何を自分で持ちたいか」で決める
EKS の料金は何で決まるのか｜クラスター料金とノード・周辺サービス
EKS の料金は、大きく 2 つに分かれます。
- EKS そのものの料金: クラスター単位の料金
- 実リソースの料金: ノードとして使う EC2 や Fargate、EBS、ロードバランサー、データ転送など
つまり「EKS を使う料金」だけでなく、「その上で動かすものの料金」を別に見積もる必要があります。Auto Mode など、ノード側の運用を AWS に寄せる選び方には、別の料金の仕組みが付く場合があります。金額やその条件は変わりうるので、数値を記事やメモに写さず、必ず AWS の料金ページで確認してください。
最後に、この記事の内容を一言で言い直します。EKS は「Kubernetes のコントロールプレーンを AWS が持ち、ノードとアプリは選び方に応じて自分（または Auto Mode では AWS）が持つ」サービスです。
Cloudory 執筆者（AWS 認定 全冠）
EKS の説明は、機能の一覧から入ると迷いやすいものです。まず「AWS が持つ範囲」と「自分が持つ範囲」の境目を引き、そのうえで用語を足していくと、現場の会話に追いつきやすくなります。
参照ソース
- Amazon EKS とは（Amazon EKS ユーザーガイド） — EKS の定義、Kubernetes 準拠、標準と Auto Mode の位置づけ、料金の考え方の根拠（2026 年 10 月時点）
- Amazon EKS のアーキテクチャ（Amazon EKS ユーザーガイド） — コントロールプレーンの構成（API サーバー 2 以上・etcd 3・3 AZ）とノードの種類の根拠（2026 年 10 月時点）
