Amazon EKSとは｜Kubernetesとの関係・料金・ECSとの違いと始め方

EKS は「Kubernetes そのもの」ではなく、Kubernetes を AWS の上で運用しやすくした入れ物です。頭脳にあたるコントロールプレーンを AWS が持ち、利用者は Pod を動かす場所（ノード）を選びます。

flowchart LR
    subgraph CP[AWSが運用]
        API[APIサーバー<br>2台以上] --- ETCD[etcd 3台<br>3つのAZ]
    end
    CP --> A[EC2<br>Auto Mode<br>マネージド<br>セルフマネージド]
    CP --> F[Fargate<br>Podごと]
    CP --> H[Hybrid Nodes<br>自社の機械]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS・Python 3.13.18。料金・仕組み・手順は AWS の公式（aws.amazon.com の EKS・Fargate・ECS の料金ページと SLA、docs.aws.amazon.com の Amazon EKS ユーザーガイドと AWS Decision Guides）だけで確かめました。月額の試算・Fargate の Pod の大きさ・バージョンの残り日数・Fargate プロファイルの当てはまり方は、公式の単価と決まりを写した Python で計算しました。マニフェストは kubernetes-validate 1.37.0（Kubernetes 1.34 のスキーマ）で検証し、eksctl の設定ファイルは PyYAML 6.0.3 で読めることだけを確かめています。AWS には接続しておらず、クラスターの作成・eksctl・kubectl・kind は動かしていません（この環境には Docker のデーモンがなく、ローカルのクラスターも立てていません）。図は mermaid-cli 11.16.0 で描画を確かめました（確認日 2026年11月13日）。

Amazon EKSとは（意味・読み方・Kubernetesとの関係）

この節では、EKS が何の略で、Kubernetes とどういう関係にあるのかが分かります。

EKS は Amazon Elastic Kubernetes Service の略で、AWS の公式ユーザーガイドは「Kubernetes クラスターの操作の複雑性を解消するフルマネージドの Kubernetes サービス」と説明しています。読み方は英字のまま「イーケーエス」と読まれるのが一般的です。

Kubernetes（クバネティス、略して k8s）は、たくさんのコンテナを複数の機械にまたがって配置し、落ちたら立て直し、負荷に合わせて増減させるオープンソースのソフトウェアです。Kubernetes を自分で動かすと、APIサーバーや etcd（設定と状態を保存するデータベース）の冗長化・更新・バックアップまで自分で受け持つことになります。EKS はその部分を AWS が引き受けます。

EKS の FAQ には「Amazon EKS はオープンソースの Kubernetes ソフトウェアを実行する」とあり、標準的な Kubernetes のアプリケーションはコードを変えずに移せると書かれています。ユーザーガイドでも、Kubernetes 準拠（Conformance）の認定を受けていると説明されています。つまり、マニフェスト（YAML）・kubectl・Helm といった Kubernetes の道具がそのまま使えます。Kubernetes のリソースと YAML の基本は、関連記事「Kubernetes入門｜主要リソースとYAMLの書き方、kubectl早見表」で扱っています。

操作の入口は、AWS マネジメントコンソール・AWS CLI・eksctl（EKS 用のコマンド）・AWS CloudFormation・AWS CDK・Terraform などが公式に挙げられています。動かす場所は AWS のクラウドが基本で、自社のデータセンターで使う EKS Anywhere や、自社の機械をノードとしてつなぐ Amazon EKS Hybrid Nodes もあります。

EKSの仕組み：コントロールプレーンとノード

この節では、EKS のクラスターがどんな部品でできていて、どこまでが AWS の受け持ちなのかが分かります。

EKS のクラスターは「コントロールプレーン（AWS が運用）」と「ノード（Pod が動く機械。形によって受け持ちが変わる）」の2つでできています。

ユーザーガイドの「アーキテクチャ」には、コントロールプレーンは少なくとも2つの APIサーバーと3つの etcd を、リージョン内の3つのアベイラビリティゾーン（AZ）にまたがって置くと書かれています。調子の悪いインスタンスは AWS が入れ替え、必要なら別の AZ を使います。クラスターごとに専用のコントロールプレーンがあり、ほかのクラスターや AWS アカウントとは共有しません。

SLA（サービスレベルの約束）では、Kubernetes APIサーバーのエンドポイントについて、標準のコントロールプレーンは月間稼働率99.95%以上、後で触れるプロビジョンドコントロールプレーンは99.99%以上とされています。1か月730時間で計算すると、止まってよい時間の上限は次のとおりです。

99.95 21.9 分/月
99.99 4.38 分/月

ここで約束されているのは APIサーバーのエンドポイントで、利用者のアプリ（Pod）の稼働ではありません。アプリの可用性は、Pod を複数の AZ のノードに分けて置くなど、利用者側の設計で決まります。Auto Mode のページでも、アプリのコンテナの可用性・セキュリティ・監視は利用者の責任と書かれています。

ノードの種類：Auto Mode・マネージドノードグループ・セルフマネージド・Fargate・Hybrid Nodes

この節では、EKS で Pod を動かす場所の5つの選択肢と、それぞれで AWS がどこまで受け持つかが分かります。

ノードの形を選ぶことは、「運用をどこまで AWS に任せるか」を選ぶことです。1つのクラスターの中で、複数の形を組み合わせることもできます。

5つ目の Amazon EKS Hybrid Nodes は、自社の拠点やエッジにある機械を EKS のノードとして使う形です。コントロールプレーンは AWS が運用し、機械と OS は利用者が管理します。

EKS Auto Mode が受け持つこと

Auto Mode のユーザーガイドによると、Auto Mode はコントロールプレーンに加えてデータプレーン（ノード）の管理まで AWS が受け持ちます。具体的には次のとおりです。

• ノードの増減：Karpenter による自動拡縮で、置き場所のない Pod があればノードを足し、要らなくなったノードを片付ける。
• 変更しない AMI：Bottlerocket 系の AMI を使い、SELinux を有効にし、ルートファイルシステムは読み取り専用。SSH や SSM での接続はできない。
• ノードの寿命は最長21日（短くもできる）。21日たつと新しいノードに置き換わる。
• 組み込みの部品：Pod の IP アドレス割り当て、ネットワークポリシー、DNS、GPU のプラグイン、EBS CSI のストレージ、ロードバランサーとの連携。EKS Pod Identity Agent を入れる必要もない。
• NodePool と NodeClass：既定のものは編集せず、別の NodePool・NodeClass を追加して、インスタンスの種類などを指定する。

ノードの形の比較（公式の比較表から抜粋）

ユーザーガイドの「コンピューティング」の比較表と、Fargate の考慮事項から、判断に効く行を抜き出しました。

Fargate については、ほかにも特権コンテナ・HostPort・HostNetwork が使えない、Pod はプライベートサブネットだけ、Fargate Spot は EKS では使えない、といった考慮事項が公式に並んでいます。

EKSの料金：クラスター料金と延長サポートを月額で試算

この節では、EKS の料金の内訳と、公式の単価から計算した月額が分かります。

EKS の請求は「クラスター料金」＋「ノードの料金（EC2・Fargate など）」＋「周辺の料金（EBS・ロードバランサー・データ転送・IPv4 アドレスなど）」の3つに分けて考えます。Amazon EKS の料金ページ（2026年11月13日時点）の単価は次のとおりです。料金ページにはリージョンごとの違いの記載がなく、例の一部だけが米国西部（オレゴン）・米国東部（バージニア北部）で示されています。

この単価を Python に入れて、1か月730時間で計算しました（料金ページの例4と同じ時間数）。

STD, EXT = 0.10, 0.60            # クラスター1時間あたり（USD）
H = 730                          # 1か月の時間
for name, r in [("標準サポート", STD), ("延長サポート", EXT)]:
    print(f"{name}: {r:.2f} USD/h x {H}h = {r*H:,.2f} USD/月, 12か月 {r*H*12:,.2f} USD")
avg = (STD*14 + EXT*12) / 26
print(f"26か月の平均（標準14か月+延長12か月）: {avg:.4f} USD/h  （料金ページ例1は約0.33）")
for n in (1, 3, 5):
    print(f"クラスター{n}個 標準: {STD*H*n:,.2f} / 延長: {EXT*H*n:,.2f} USD/月  差 {(EXT-STD)*H*n:,.2f}")

標準サポート: 0.10 USD/h x 730h = 73.00 USD/月, 12か月 876.00 USD
延長サポート: 0.60 USD/h x 730h = 438.00 USD/月, 12か月 5,256.00 USD
26か月の平均（標準14か月+延長12か月）: 0.3308 USD/h  （料金ページ例1は約0.33）
クラスター1個 標準: 73.00 / 延長: 438.00 USD/月  差 365.00
クラスター3個 標準: 219.00 / 延長: 1,314.00 USD/月  差 1,095.00
クラスター5個 標準: 365.00 / 延長: 2,190.00 USD/月  差 1,825.00

26か月の平均が料金ページの例1（約0.33ドル）と一致したので、単価の読み方は合っています。開発・検証・本番の3クラスターを延長サポートのまま置くと、標準との差は月1,095ドルです。

プロビジョンドコントロールプレーンと Auto Mode の管理料

料金ページの例5（XL を半月使う）と例4（Auto Mode のノード4台）も、同じ計算で再現できました。

== 2. プロビジョンドコントロールプレーン（例5の再現: XL を半月）
標準 0.10x720=72 + XL 1.65x360=594 = 666 USD
XL: (0.10+1.65) x 730 = 1,277.50 USD/月
2XL: (0.10+3.4) x 730 = 2,555.00 USD/月
4XL: (0.10+6.9) x 730 = 5,110.00 USD/月
8XL: (0.10+13.9) x 730 = 10,220.00 USD/月
== 3. Auto Mode の管理料（例4の再現: 米国西部オレゴン）
c6a.2xlarge: EC2 0.306 / 管理料 0.03672  比率 12%
c6a.4xlarge: EC2 0.612 / 管理料 0.07344  比率 12%
m5a.2xlarge: EC2 0.344 / 管理料 0.04128  比率 12%
m5a.xlarge: EC2 0.172 / 管理料 0.02064  比率 12%
合計 EC2 1.434 USD/h (1,046.82/月)  管理料 0.17208 USD/h (125.62/月)

例4の4種類では、管理料はどれも EC2 の単価の12%でした。料金ページには管理料の一覧表がないため、ほかのインスタンスやリージョンでも12%になるとは言い切れません。見積もりでは AWS Pricing Calculator などの公式の計算で確かめます。例5の「月720時間」は、料金ページの例がその時間数で計算しているためです。

EKS on Fargate の料金はPodの大きさで決まる（256MB の上乗せを計算）

この節では、EKS で Fargate を使うときに、Pod にいくらかかるかと、指定より大きく割り当てられる理由が分かります。

Fargate は、Pod が使う vCPU とメモリに対して秒単位で課金されます（最低1分）。AWS Fargate の料金ページに例として載っている米国東部（バージニア北部）の Linux/x86 の単価は、1 vCPU 1秒 0.000011244ドル、1GB 1秒 0.000001235ドルです（東京リージョンの単価は料金ページの例にはありませんでした）。

注意したいのは、EKS の Fargate では、Pod のメモリに Kubernetes の部品（kubelet・kube-proxy・containerd）の分として256MB が足され、そのうえで用意された組み合わせに切り上げられることです（ユーザーガイド「Fargate Pod の設定」）。この決まりを Python に写し、リクエストごとの割り当てと月額を出しました。

COMBOS = {0.25:[0.5,1,2], 0.5:[1,2,3,4], 1:[2,3,4,5,6,7,8],
          2:list(range(4,17)), 4:list(range(8,31)), 8:list(range(16,61,4)), 16:list(range(32,121,8))}
def size(init, long_running):
    iv = max([c[0] for c in init], default=0); im = max([c[1] for c in init], default=0)
    lv = sum(c[0] for c in long_running);      lm = sum(c[1] for c in long_running)
    v, m = max(iv, lv), max(im, lm)            # init は最大、常駐コンテナは合計、大きい方
    m_gb = m/1024 + 0.25                       # 256MB を足す
    for cv in sorted(COMBOS):
        if cv < v: continue
        for cm in COMBOS[cv]:
            if cm >= m_gb: return v, m, cv, cm

リクエスト                                           合計          割り当て    月額USD
指定なし                                     0vCPU     0Mi -> 0.25vCPU 0.5GB     9.01
250m / 256Mi                          0.25vCPU   256Mi -> 0.25vCPU 0.5GB     9.01
500m / 1Gi                             0.5vCPU  1024Mi -> 0.5vCPU 2GB    21.27
500m / 768Mi                           0.5vCPU   768Mi -> 0.5vCPU 1GB    18.02
1 / 8Gi（公式の例）                            1vCPU  8192Mi -> 2vCPU 9GB    88.31
アプリ500m/512Mi + サイドカー250m/256Mi       0.75vCPU   768Mi -> 1vCPU 2GB    36.04
init 1/2Gi + アプリ250m/512Mi               1vCPU  2048Mi -> 1vCPU 3GB    39.29

「1 vCPU・8GB」が「2 vCPU・9GB」になる行は、ユーザーガイドに載っている例と同じ結果です。メモリを 1Gi ちょうどで頼むと、256MB が足されて 2GB に切り上がり、768Mi で頼んだときより月3ドルほど高くなりました。実際に割り当てられた大きさは、Pod の注釈 CapacityProvisioned（kubectl describe pod で見える）に出て、これが料金の基準になると公式に書かれています。

• 1メモリは「組み合わせ − 256MB」以下で頼む0.5 vCPU なら 768Mi で 1GB に収まる。1Gi だと 2GB になる
• 2サイドカーの分も合計される常駐するコンテナのリクエストは足し算。init コンテナは最大の1つだけ
• 3終わった Job の Pod を残さない公式は ttlSecondsAfterFinished で自動で消す例を載せている。残すと課金が続く
• 4kubectl get nodes の大きさで判断しないFargate のノードの表示と Pod の割り当ては一致しない。CapacityProvisioned を見る

一時ストレージは Pod ごとに既定で20GiB、最大175GiB まで増やせます。0.5 vCPU・1GB の Pod を4つ1か月動かす例では、Pod が72.08ドル、クラスター料金が73.00ドルで、合計145.08ドルでした（ロードバランサー・ログ・データ転送は含みません）。

Kubernetesのバージョンとサポート期限（2026年11月13日時点）

この節では、EKS の Kubernetes バージョンの寿命と、いまどのバージョンが標準・延長のどちらにあるかが分かります。

EKS では、Kubernetes のマイナーバージョンは公開から14か月が標準サポート、その後12か月が延長サポートで、合わせて26か月使えます。延長サポートの終わりまでに上げないと、コントロールプレーンは延長サポート中のいちばん前の版へ自動で上げられます。そのときマネージドノードグループやセルフマネージドのノードは前の版のまま残るため、アドオンとノードは自分で上げます。

ユーザーガイドの表の日付から、2026年11月13日時点の残り日数を Python で出しました。

1.37: いま標準  標準終了まで   383日  延長終了まで   749日  時間単価 0.1
1.36: いま標準  標準終了まで   262日  延長終了まで   628日  時間単価 0.1
1.35: いま標準  標準終了まで   134日  延長終了まで   500日  時間単価 0.1
1.34: いま標準  標準終了まで    19日  延長終了まで   384日  時間単価 0.1
1.33: いま延長  標準終了まで  -107日  延長終了まで   258日  時間単価 0.6
1.32: いま延長  標準終了まで  -235日  延長終了まで   130日  時間単価 0.6
1.31: いま延長  標準終了まで  -352日  延長終了まで    13日  時間単価 0.6

1.34 は2026年12月2日に標準サポートが終わり、その日から1時間0.60ドルになります。1.31 は2026年11月26日に延長サポートも終わります。日付は UTC で、延長サポートの課金は標準サポートが終わる日の始まりから、と書かれています。

アップグレードポリシーは、新しいクラスターも既存のクラスターも既定で EXTENDED です。延長サポートを無効にすると、標準サポートの終わりに自動で上げられます。各バージョンの状態は aws eks describe-cluster-versions で確かめられると公式に書かれています（この記事では実行していません）。

EKSとECSの違い（公式の説明の範囲で）

この節では、同じ AWS のコンテナサービスである Amazon ECS と EKS の違いが、公式の説明に沿って分かります。

いちばん大きな違いは、EKS が Kubernetes を使い、ECS が AWS 独自のオーケストレーションを使うことです。AWS の Decision Guide「Choosing an AWS container service」（2025年5月16日更新）は、ECS を「コンテナ化されたアプリのデプロイ・管理・スケーリングを簡単にするフルマネージドのオーケストレーションサービス」、EKS を「Kubernetes を使ってコンテナ化されたアプリをデプロイ・管理・スケーリングできるマネージドな Kubernetes サービス」と説明しています。

ECS の料金ページには「Amazon ECS のオーケストレーションに追加料金はかからない」とあり、EC2 や Fargate の料金だけを払います（ECS Managed Instances には管理料、ECS Anywhere は登録したインスタンス1時間0.01025ドル）。Decision Guide は選ぶときの観点として、運用の負担、組織のスキル、組織の大きさ、移しやすさを挙げ、Kubernetes を運用するには頻繁なクラスターの更新に向き合う体制が要り、Kubernetes は年3回のリリースがあると書いています。

ECS で使うタスク定義の書き方は、関連記事「ECSタスク定義JSONの書き方｜Fargate必須項目と環境変数secrets」、Fargate のコンテナに入って調べる方法は、関連記事「ECS Execの使い方｜Fargateのコンテナに入る設定と失敗の原因」で扱っています。

EKSの始め方：eksctl・AWS CLI・kubectlの手順

この節では、EKS のクラスターを作ってから消すまでの最短の流れが、公式の手順どおりに分かります。

公式の「eksctl で始める」手順では、AWS CLI・kubectl・eksctl を入れて設定したうえで、eksctl のコマンド1行でクラスターとノードを作ります。この記事の環境では AWS に接続していないため、以下は公式のコマンドをそのまま載せたものです。

# 公式の手順のコマンド（region-code と my-cluster は置き換える）
eksctl create cluster --name my-cluster --region region-code            # マネージドノード
eksctl create cluster --name my-cluster --region region-code --fargate  # Fargate
eksctl create cluster --name=my-cluster --enable-auto-mode              # Auto Mode
aws eks update-kubeconfig --region region-code --name my-cluster
kubectl get svc
kubectl get nodes -o wide
eksctl delete cluster --name my-cluster --region region-code

公式の手順に載っている kubectl get svc の出力例は次の形です。

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
svc/kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   1m

設定をファイルで残したいときは、eksctl の ClusterConfig を使います。Auto Mode のユーザーガイドの見本から、最小限の項目だけを残すと次のようになります（eksctl create cluster -f cluster.yaml で作成）。手元では PyYAML で読めることだけを確かめました。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: demo-cluster
  region: region-code
autoModeConfig:
  enabled: true

{'apiVersion': 'eksctl.io/v1alpha5', 'kind': 'ClusterConfig', 'metadata': {'name': 'demo-cluster', 'region': 'region-code'}, 'autoModeConfig': {'enabled': True}}

AWS マネジメントコンソールからもクラスターを作れます。コンテナイメージを置く場所としては Amazon ECR がよく使われ、使い方は関連記事「Amazon ECR の使い方 リポジトリ作成とライフサイクルポリシー」で扱っています。

EKSに置くマニフェストを手元で検証する（実行結果）

この節では、EKS に適用する前に、Kubernetes のマニフェストの間違いを手元で見つける方法と、その出力が分かります。

EKS は標準の Kubernetes なので、Kubernetes のスキーマで検証すればクラスターがなくても形の間違いを見つけられます。ここでは pip で入る kubernetes-validate 1.37.0 を使い、EKS の標準サポート中の 1.34 のスキーマで検証しました。検証したのは次の Deployment・Service と、ユーザーガイドの Fargate のページにある Job（終わったら60秒で消える）です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: public.ecr.aws/nginx/nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: demo
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80

$ kubernetes-validate -k 1.34.0 --strict app.yaml
INFO app.yaml passed for resource namespace/demo against version 1.34
INFO app.yaml passed for resource deployment/web against version 1.34
INFO app.yaml passed for resource service/web against version 1.34
INFO app.yaml passed for resource job/busybox against version 1.34
exit=0

次に、わざと間違えたマニフェストを検証しました。4つのうち2つは、オプションや書き方しだいで「通ってしまう」ことが分かりました。

### selector を書き忘れた
ERROR bad3.yaml did not validate for resource deployment/web against version 1.34: spec: 'selector' is a required property
exit=1
### containerPort を "80"（文字列）にした
ERROR bad2.yaml did not validate for resource deployment/web against version 1.34: spec.template.spec.containers.0.ports.0.containerPort: '80' is not of type 'integer'
exit=1
### replicas を replica と打ち間違えた（--strict あり）
ERROR bad2b.yaml did not validate for resource deployment/web against version 1.34: spec: Additional properties are not allowed ('replica' was unexpected)
exit=1
### 同じファイルを --strict なしで
INFO bad2b.yaml passed for resource deployment/web against version 1.34
exit=0
### apiVersion: extensions/v1beta1 の Deployment（前の版の書き方）
WARN bad1.yaml Couldn't find schema for kind Deployment with api version extensions/v1beta1 for kubernetes version 1.34
exit=0

Service を外に出すときは、Fargate では Network Load Balancer・Application Load Balancer とも IP ターゲットだけが使える、と公式に書かれています。Ingress の書き方は、関連記事「Kubernetes Ingressの書き方｜パス・ホスト・TLS設定例」で扱っています。

Fargateプロファイル：どのPodがFargateで動くか

この節では、EKS で Fargate を使うときの「Fargate プロファイル」の決まりと、Pod が Pending のままになる理由が分かります。

EKS の Fargate では、Pod がどれかの Fargate プロファイルのセレクターに合ったときだけ Fargate で動きます。ユーザーガイドの決まりは次のとおりです。

• セレクターには名前空間が必須で、ラベルも付けられる。ラベルは全部合った Pod だけが対象。
• 名前空間・ラベルのキー・値に *（0文字以上）と ?（ちょうど1文字）が使える。正規表現は使えない。
• 1つのプロファイルにセレクターは5つまで。複数のプロファイルに合ったら、プロファイル名の英数字順で選ばれる。
• プロファイルは変更できない。新しいものを作ってから前のものを消す。消すと、その上の Pod は止まって Pending になる。
• Pod はプライベートサブネットだけで動き、公開 IP アドレスは付かない。

この決まりを Python に写した小さなモデルで、どの Pod がどのプロファイルに当たるかを確かめました（Fargate の動作そのものではなく、公式の決まりを再現した計算です）。

from fnmatch import fnmatchcase
profiles = {
  "fp-batch":   [{"namespace": "batch-*"}],
  "fp-default": [{"namespace": "demo", "labels": {"compute": "fargate"}},
                 {"namespace": "kube-system", "labels": {"k8s-app": "kube-dns"}}],
  "fp-prod":    [{"namespace": "prod?"}],
}
def matches(sel, ns, labels):
    if not fnmatchcase(ns, sel["namespace"]): return False
    for k, v in sel.get("labels", {}).items():
        if not any(fnmatchcase(lk, k) and fnmatchcase(lv, v) for lk, lv in labels.items()): return False
    return True

demo          {'app': 'web', 'compute': 'fargate'}  -> Fargate（fp-default）
demo          {'app': 'web'}                        -> Fargate にのらない（EC2 ノードが無ければ Pending）
batch-nightly {}                                    -> Fargate（fp-batch）
prod1         {}                                    -> Fargate（fp-prod）
prod          {}                                    -> Fargate にのらない（EC2 ノードが無ければ Pending）
prod-a        {}                                    -> Fargate にのらない（EC2 ノードが無ければ Pending）
kube-system   {'k8s-app': 'kube-dns'}               -> Fargate（fp-default）

prod? は prod1 には合いますが、prod（1文字足りない）と prod-a（2文字多い）には合いません。公式の説明どおり、? はちょうど1文字です。名前空間を広く拾いたいときは prod* にします。eksctl でプロファイルを作るコマンドは、公式では次の形です。

eksctl create fargateprofile \
    --cluster my-cluster \
    --name my-fargate-profile \
    --namespace my-kubernetes-namespace \
    --labels key=value

EKSでよくあるエラー・つまずき

この節では、EKS を使い始めたときによく出るエラーの原文と、原因・直し方が分かります。

kubectl のエラーの多くは「どの IAM のユーザー・ロールで接続しているか」と「そのプリンシパルにクラスターへのアクセスが登録されているか」で説明がつきます。原文は Amazon EKS のトラブルシューティングのページと、上の節で手元に出した出力です。

そのほか、終わった Job の Pod が Fargate で残って課金が続く、延長サポートに入ったことに気づかず料金が6倍になる、Fargate で DaemonSet のログ収集が動かない（サイドカーにする）、といった点も公式の記載から起こりやすいつまずきです。

判断表：EKSのどの形を選ぶか

この節では、やりたいことから EKS のノードの形や ECS との選び分けを決める順番が分かります。

上から順に当てはまるものを選ぶと、迷いが減ります。どれも公式の比較表・考慮事項に書かれた条件をもとにしています。

1. 1Kubernetes を使う理由がない → Amazon ECS も候補にするECS はオーケストレーションの追加料金なし。Kubernetes の版の更新に向き合う体制が要らない
2. 2Windows のコンテナ・ノードへの SSH・独自の AMI が要る → マネージドノードグループAuto Mode ではできない項目
3. 3ノードの運用を減らしたい・GPU や DaemonSet も使う → EKS Auto ModeEC2 料金に管理料が加わる
4. 4小さな Pod を機械なしで動かしたい → FargateDaemonSet・GPU・EBS・特権コンテナは使えない
5. 5自社の拠点の機械をノードにしたい → Hybrid NodesvCPU 時間で課金。GovCloud と中国のリージョンを除く
6. 6すべてを自分で決めたい → セルフマネージドノード管理・拡縮・保守はすべて自分

よくある質問

この節では、EKS について検索されることの多い質問に短く答えます。

Q. EKS は無料で使えますか？
クラスターがある間は1時間0.10ドル（標準サポート）がかかります。Pod を動かすノードの料金も別にかかります。料金ページには無料の枠の記載はありませんでした（2026年11月13日時点）。

Q. EKS の料金は月いくらですか？
クラスター料金だけで1つ月73ドル（730時間）、延長サポート中は438ドルです。ここにノード・ストレージ・ロードバランサー・データ転送の料金が加わります。

Q. EKS と Kubernetes は何が違いますか？
Kubernetes はオープンソースのソフトウェア、EKS はそれを AWS が運用して提供するサービスです。EKS ではコントロールプレーンを AWS が冗長化・更新します。

Q. EKS と ECS はどちらを選べばよいですか？
Kubernetes の道具や知識をそのまま使いたいなら EKS、AWS の中で完結させ、クラスター料金をかけずに Kubernetes の版の更新からも離れたいなら ECS が候補です。AWS の Decision Guide は、運用の負担・組織のスキル・組織の大きさ・移しやすさで考えるよう勧めています。

Q. EKS Auto Mode と Fargate の違いは？
Auto Mode は EKS が EC2 のノードを用意・更新・拡縮する形で、DaemonSet や GPU も使えます。Fargate は Pod ごとに独立した計算環境を AWS が用意する形で、DaemonSet・GPU・EBS は使えません。

Q. 延長サポートとは何ですか？
標準サポート（公開から14か月）が終わったバージョンを、さらに12か月使えるようにするものです。料金は1時間0.60ドルになります。既定ではすべてのクラスターが延長サポートに入る設定です。

Q. kubectl はそのまま使えますか？
使えます。aws eks update-kubeconfig で kubeconfig を作ると、ふだんの kubectl のコマンドで操作できます。

Q. EKS のクラスター作成にはどれくらい時間がかかりますか？
公式の eksctl の手順には「数分かかる」とだけ書かれています。正確な時間の記載はありませんでした。

Q. Fargate の Pod の料金が思ったより高いのはなぜですか？
EKS の Fargate では、Pod のメモリに256MB が足され、用意された組み合わせに切り上げられるためです。0.5 vCPU・1Gi で頼むと 2GB が割り当てられます。CapacityProvisioned の注釈で実際の大きさを確かめられます。

Q. ローカルで EKS を試せますか？
EKS そのものは AWS のサービスなので、手元では動きません。マニフェストは Kubernetes のスキーマで検証でき、Kubernetes の動きは kind などのローカルのクラスターで確かめられます（この記事では kind は動かしていません）。

まとめ

この節では、記事の要点を5つにまとめます。

• EKS は AWS のマネージドな Kubernetes。APIサーバー2台以上と etcd 3台を3つの AZ で AWS が運用する。
• 料金はクラスター1時間0.10ドル（月73ドル）＋ノード。延長サポートは0.60ドルで6倍。1.34 は2026年12月2日に標準サポートが終わる。
• ノードは Auto Mode・マネージドノードグループ・セルフマネージド・Fargate・Hybrid Nodes から選ぶ。任せる範囲とできることが違う。
• Fargate は256MB の上乗せと切り上げで料金が決まる。1 vCPU・8GB は 2 vCPU・9GB になる（公式の例と計算が一致）。
• マニフェストは --strict で検証する。付けないと打ち間違いが通り、前の版の apiVersion は警告だけで終了コード0だった。

参考・出典

この節では、この記事で確かめた AWS の公式の情報源をまとめます（いずれも確認日 2026年11月13日）。

• Amazon EKS の料金：https://aws.amazon.com/eks/pricing/
• Amazon EKS Service Level Agreement：https://aws.amazon.com/eks/sla/
• Amazon EKS よくある質問：https://aws.amazon.com/eks/faqs/
• Amazon EKS とは（ユーザーガイド）：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/what-is-eks.html
• Amazon EKS architecture：https://docs.aws.amazon.com/eks/latest/userguide/eks-architecture.html
• Compute（ノードの比較）：https://docs.aws.amazon.com/eks/latest/userguide/eks-compute.html
• EKS Auto Mode：https://docs.aws.amazon.com/eks/latest/userguide/automode.html
• AWS Fargate（EKS）：https://docs.aws.amazon.com/eks/latest/userguide/fargate.html
• Fargate Pod configuration：https://docs.aws.amazon.com/eks/latest/userguide/fargate-pod-configuration.html
• Fargate profile：https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html
• Kubernetes versions：https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
• Get started with eksctl：https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html
• Create an Auto Mode cluster with eksctl：https://docs.aws.amazon.com/eks/latest/userguide/automode-get-started-eksctl.html
• Connect kubectl（kubeconfig）：https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
• Troubleshoot problems with Amazon EKS：https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html
• AWS Fargate の料金：https://aws.amazon.com/fargate/pricing/
• Amazon ECS の料金：https://aws.amazon.com/ecs/pricing/
• Choosing an AWS container service（AWS Decision Guides）：https://docs.aws.amazon.com/decision-guides/latest/containers-on-aws-how-to-choose/choosing-aws-container-service.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。