Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説

Amazon EKS（Elastic Kubernetes Service）は、KubernetesのコントロールプレーンをAWSが運用してくれるマネージドサービスです。この記事では、マルチAZで冗長化されたコントロールプレーンの仕組み、ワーカーノードを動かす4つの提供形態（Auto Mode・マネージドノードグループ・セルフマネージド・Fargate）、1クラスターあたり0.10ドル毎時から積み上がる料金構造を一次情報で整理します。ECSや自前構築のKubernetes、GKE／AKSとの使い分け、そしてEKSを採用すべき条件と見送るべき場面まで、構成設計で迷う論点を数値で示します。

まとめ：Amazon EKSの仕組み・料金と採用判断の要点

Amazon EKSは、Kubernetesの頭脳にあたるコントロールプレーン（APIサーバーやetcd）をAWSがマルチAZで冗長化して運用し、利用者はアプリを載せるワーカーノードとマニフェストの管理に集中できるマネージドKubernetesです。素のKubernetesを自前で構築するとマスターの可用性設計やバージョン追従が重い運用負荷になりますが、EKSはそこをAWSへ委ねられます。

料金はコントロールプレーンが1クラスター0.10ドル毎時（標準サポート）で、これにワーカーノードのコンピューティング費が乗る二階建てです。ノードはAuto Modeで運用ごと任せるか、マネージドノードグループやFargateから選びます。コンテナを動かしたいだけでKubernetesの表現力が要らないならECS、複数クラウドにまたがるならGKE／AKSも含めて比較すべきで、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて判断してください。

Amazon EKSの仕組みとマネージドコントロールプレーンの構成

EKSを設計に落とすには、AWSが管理する範囲と利用者が管理する範囲の境界線を最初に押さえます。Kubernetesのコンテナオーケストレーションとしての役割を前提に、コントロールプレーンとデータプレーン（ノード）を分けて捉えると構成が整理できます。

AWSが運用するコントロールプレーンと利用者が持つワーカーノードの境界

EKSクラスターは、Kubernetes APIサーバーやスケジューラ、etcd（クラスター状態のキーバリューストア）といったコントロールプレーンと、実際にPodを動かすワーカーノードに分かれます。コントロールプレーンはAWSが複数のアベイラビリティゾーンにまたがって冗長構成で運用し、障害時の切り替えやパッチ適用を肩代わりします。一方、ワーカーノードはVPC内の利用者アカウント側に置かれ、そのスペックや台数、OSパッチの範囲は利用者の管轄です。この責任分界のうち、ノード側の自動化をどこまで任せるかが後述の提供形態の選択につながります。

ワーカーノードを動かす4つの提供形態と選び分けの起点となる観点

ノードの提供形態は4つあります。ノードの起動から縮退までをAWSへ任せるEKS Auto Mode、起動テンプレートをAWSが面倒を見るマネージドノードグループ、EC2を自分で組むセルフマネージドノード、サーバーレスにPod単位で動かすAWS Fargateです。運用の手間を最小化したい新規構築ならAuto Modeが起点になり、既存のEC2運用資産や細かなカーネル調整が要る場合はマネージド／セルフマネージドを選びます。各ノードの実体はAmazon EC2の仮想サーバーであり、Fargateだけは物理ホストを意識しない従量モデルになる点が分岐の勘所です。

VPC CNI・IAM連携などクラスターを支えるアドオンの構成

EKSはKubernetesに準拠しつつ、AWSのネットワークや認証と統合するためのアドオンを持ちます。Podへリアルなリソース権限を渡す認証は、サービスアカウントにIAMロールを結び付けるIRSA（IAM Roles for Service Accounts）と、より新しいEKS Pod Identityの2方式があり、いずれもAWS IAMによる権限管理を土台にします。ネットワークはAmazon VPC CNIがPodへVPCのIPを直接割り当て、名前解決はCoreDNS、サービス転送はkube-proxyの担当です。コンテナイメージの置き場所はコンテナレジストリ（ECR）を使うのが基本で、ここまでを一体で設計するとクラスターが素直に立ち上がります。

Amazon EKSの料金モデルとコスト構造・付帯コストの実務ポイント

EKSのコストは、コントロールプレーンの固定費とノードの変動費という二階建てで捉えると読み違えません。同じクラスターでもノードの提供形態と付帯リソースの扱いで総額が変わります。

コントロールプレーンの固定費と拡張サポート料金という落とし穴

コントロールプレーンは1クラスターあたり0.10ドル毎時で、標準サポート対象のKubernetesバージョンを動かしている限りこの単価です（2026年7月時点・AWS公式）。月換算では固定で数十ドル規模になり、クラスター数がそのまま倍数で効きます。注意したいのは拡張サポートで、標準サポートが切れた古いバージョンを使い続けると0.60ドル毎時へ跳ね上がります。バージョン追従を怠ると6倍のコントロールプレーン費を払い続けることになるため、Kubernetesは標準サポート内（1.34系が2025-10-06公開で最新の対象）で計画的に上げるのが定石です。

Auto Mode・EC2・Fargateで変わるコンピューティング費

ノードの費用は提供形態で計算基盤が異なります。Auto ModeはKarpenterが必要な分だけEC2を起動する仕組みで、EC2の実費に加えて管理費がインスタンスタイプ別に上乗せされ、秒単位（最小1分）で課金されます。マネージド／セルフマネージドはEC2の料金がそのまま乗るため、Savings Planやスポットの割引をノードにも効かせられる点が違いです。Fargateは動かしたPodのvCPUとメモリ使用量に対し、イメージ取得からPod終了まで秒単位（最小1分）で課金します。常時稼働の土台はEC2系ノードで割引を効かせ、断続的なジョブはFargateへ寄せる、という組み合わせが総額を抑える起点です。

EBS・IPv4・クロスAZ通信という見落としやすい付帯コスト

コンピューティング費だけを見積もると総額を外します。ノードやPodが使うEBSボリューム、割り当てられるIPv4アドレス（有料化済み）、そしてノードとコントロールプレーン、あるいはPod同士がゾーンをまたいで通信するクロスAZのデータ転送料が積み上がるためです。とくに大規模クラスターではクロスAZ通信が無視できない額になりやすいので、通信の多いPodは同一ゾーンへ寄せる、あるいはトポロジー制約を使うといった設計で抑えます。EBSのスナップショットや未使用IPの解放まで含めて棚卸しすると、請求の想定外を減らせます。

Amazon EKSを採用すべき条件とECS・自前Kubernetesとの使い分け

ここでは判断を言い切ります。EKSはKubernetesの表現力をそのまま得られる反面、クラスター運用やアドオンの学習コストが伴います。自社システムのどこにEKSを差し込むかを、条件付きで見極めてください。

Amazon EKSの採用が効くワークロードの条件と設計の起点

採用が効くのは、Kubernetesの標準APIやエコシステム（Helm・Operator・Argo CD・サービスメッシュなど）をそのまま使いたい、既存のオンプレKubernetesやGKE／AKSからAWSへ寄せたい、マイクロサービスを本格的にオーケストレーションしたい、という条件が重なるときです。こうしたAWS上のコンテナ基盤を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、ノード形態の選定やコスト設計、運用体制の妥当性を相談するとよいでしょう。運用工数を抑えたい場合は、EKS Auto Modeでクラスターを構築する手順から入ると立ち上げが速くなります。

ECS・Fargate単体・GKE／AKSへ寄せるべき場面の見極め

コンテナを動かしたいだけで、Kubernetesの豊富なリソース定義や周辺エコシステムまでは要らないなら、AWSネイティブで学習コストの軽いECSが向きます。ECSとEKSの分岐点は、AWS ECSとEKSの違いを解説した記事で起動タイプや料金を追って確認できます。複数クラウドをまたぐ標準化を優先するならKubernetes系のGKE／AKSも含めて比較し、逆にAWS一本かつ小規模ならECS＋Fargateが総運用コストで有利になりがちです。Auto ModeとFargateのノード運用の違いは、EKS Auto ModeとEKS on Fargateのノード管理を解説した記事で具体的に押さえられます。

Amazon EKSを見送るべき場面とはまりやすい失敗パターン

見送るべきなのは、コンテナ化していない単一のアプリを載せたいだけの用途、Kubernetesを運用できる人員がいない小規模チーム、そしてクラスター1つに小さなアプリを1本だけ載せてコントロールプレーン固定費に見合わない構成です。これらをEKSで抱えると、学習コストと0.10ドル毎時の固定費が回収できません。もう1つの失敗パターンは、標準サポート切れのバージョンを放置して拡張サポート費（0.60ドル毎時）を払い続ける、あるいはクロスAZ通信を意識せずデータ転送料を膨らませる構成です。バージョンを計画的に上げ、通信の局所化と付帯コストの棚卸しを前提に組めば、EKSの表現力を過剰投資なしに使えます。EKSはあくまでクラウドネイティブの構成技術の一部品で、要件がECSで足りるなら無理に選ぶ必要はありません。

よくある質問

Amazon EKSの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Amazon EKSとECSはどちらを選ぶべきですか？

Kubernetesの標準APIやHelm・Operatorなどのエコシステムを使いたい、複数クラウドで運用を標準化したいならEKS、AWS一本でコンテナを手早く動かしたいだけならECSが基本の分岐です。ECSは学習コストとコントロールプレーンの固定費がない分、小〜中規模では総運用コストで有利になりがちです。移行性やチームのKubernetes習熟度を軸に選定してください。

EKSのコントロールプレーンの料金はいくらですか？

標準サポート対象のKubernetesバージョンで、1クラスターあたり0.10ドル毎時です（2026年7月時点・AWS公式）。これとは別にワーカーノードのEC2やFargate、EBS、IPv4、クロスAZ通信の費用が乗ります。標準サポートが切れたバージョンを使い続けると拡張サポートとして0.60ドル毎時に上がるため、バージョン追従を計画に組み込んでください。

EKS Auto ModeとFargateはどう違いますか？

Auto ModeはKarpenterがEC2ノードを自動で起動・縮退させる仕組みで、GPUやスポットなどEC2の購入オプションをそのまま使えます。Fargateはノードという概念自体を意識せず、Pod単位でvCPUとメモリの使用量に課金するサーバーレス方式です。EC2の割引を効かせて常時稼働を安くしたいならAuto Mode、ノード運用を完全に排除したいならFargateが向きます。

素のKubernetesを自前構築するのと比べて何が楽になりますか？

コントロールプレーン（APIサーバーやetcd）の冗長化・バックアップ・バージョンパッチをAWSが肩代わりする点が最大の差です。自前構築ではマスターの可用性設計や証明書更新、etcdの運用が重い負荷になりますが、EKSではそこを委ねてノードとアプリの管理へ集中できます。その代わりコントロールプレーンの固定費が発生します。

EKSでPodにAWSリソースの権限を渡すにはどうしますか？

サービスアカウントにIAMロールを結び付けるIRSA（IAM Roles for Service Accounts）か、より新しいEKS Pod Identityを使います。どちらもノード全体に強い権限を付けず、Pod単位で必要最小限の権限を渡せるため、最小権限の原則に沿った設計ができます。新規構築では設定がシンプルなPod Identityを起点に検討するとよいでしょう。

関連記事

• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い：EKSと迷ったときにECSを選ぶ判断軸を料金と起動タイプで整理
• Amazon EKS Auto Modeを利用したクラスターの構築手順：本記事で概要を掴んだあとに読む具体的な構築how-to
• EKS Auto ModeとEKS on Fargateのノード管理とアクセス方法：ノード提供形態の運用差を実装レベルで解説
• コンテナオーケストレーションとは？Kubernetesの役割と自社への要否：EKSの前提となるオーケストレーションの上位概念
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル：EKSワーカーノードの実体となる仮想サーバーの体系