copied!

EKS Auto Mode と標準クラスタの違いを4つの軸で比較する

Sreake事業部

2026.7.22

copied!

Table of Contents

1. はじめに

はじめまして、Sreake事業部インターン生の大石です。SRE の技術の調査と研究を目的とした長期インターンに参加しています。

本記事では、Amazon EKS の Auto Mode と 標準クラスタ を、実際に両方構築して 4つの軸(構築コスト / 学習コスト / ランニングコスト / 移行容易性)で比較します。

新規に EKS を採用するチームで「標準クラスタと Auto Mode のどちらを選ぶべきか」迷っている方に向けて、判断材料を提示することを目的としています。

想定読者: 新規に EKS を採用予定で、Auto Mode と標準クラスタの選択に迷っている人

なお筆者は、インターン参加までは Kubernetes を一切触ったことがない完全な初学者でした。本検証の少し前に、ハンズオンを通じて標準クラスタの手動構築(Karpenter / ALB Controller / EBS CSI Driver の導入)を一通り経験したばかりです。記事中の「ハマりポイント」は初学者の視点で書いているため、想定読者の方々と近い感覚で読んでいただけると思います。

2. TL;DR

新規 EKS 採用は 「楽さ重視なら Auto Mode、コスト重視なら standard」というトレードオフになります。Auto Mode は構築・学習コストが劇的に下がり、アプリ層の YAML(Deployment / Service / Secret / HPA)はそのまま動きますが、本検証では月額約 +$80 高い結果でした(Karpenter 無制約時。NodePool で絞れば縮む可能性あり)。また「Auto Mode → standard」の逆移行コストも高めです。

軸	standard	auto-mode	軍配
① 構築コスト	累計 3〜4 時間 / 自作 YAML 57 行 / IAM ロール +7	クラスタ作成 12 分 / 自作 YAML 0 / IAM ロール +2	Auto Mode
② 学習コスト	ハマりポイント 3 個(Karpenter / IAM / metrics-server)	学ぶことがほぼない	Auto Mode
③ ランニングコスト	48h 約 $15.31 (t3.medium × 2)	48h 約 $20.65※ (c5a.large + c6g.large)	standard(月額換算で約 +$80 高)
④ 移行容易性	アプリ層 YAML は無修正、Auto Mode へは中難易度	Auto Mode → standard は高難易度	注意点あり

※ Auto Mode は Karpenter がインスタンスを自動選定するため、standard 側の t3.medium と同条件比較ではありません。NodePool で instance family を絞れば差は縮みます(詳細は 5.3)。

3. EKS Auto Mode とは

3.1 概要

EKS Auto Mode は、AWS が Kubernetes クラスタのインフラ運用を肩代わりする機能です。従来の標準クラスタでは、ユーザーが自分でセットアップ・運用していた以下のような部品を、AWS が自動で管理してくれます。

コンピュート(ノードの自動増減)
Pod / Service のネットワーキング
アプリケーションロードバランシング
クラスタ DNS
ブロックストレージ
GPU サポート

公式ドキュメントの表現を借りると、Auto Mode は「日々の運用の専門知識(deep EKS expertise)がなくても、本番グレードのクラスタを動かせる」ことを目指したものです。

出典: EKS Auto Mode 公式ドキュメント

3.2 標準クラスタとの責任分界

EKS は元々「2つの VPC」で構成されます。

AWS-managed VPC: Kubernetes Control Plane(API Server / etcd)が動く。顧客アカウントからは見えない。
Customer VPC: ワーカーノードやロードバランサーが動く。顧客が管理する。

標準クラスタでも Control Plane は AWS が管理しますが、Auto Mode はさらに「データプレーンの運用」まで AWS 側に移譲します。

出典: Security Overview of Amazon EKS Auto Mode – EKS control plane

“The Kubernetes control plane managed by Amazon EKS runs inside an EKS-managed VPC. … In a standard Amazon EKS cluster, the components that perform auto-scaling, manage Elastic Network Interfaces (ENIs) and Amazon EBS devices run as Kubernetes Pods on nodes in the cluster. With Auto Mode, AWS manages these components and runs them outside of the cluster.”

管理対象	標準クラスタ	Auto Mode
Control Plane(API Server / etcd)	AWS	AWS
ノードの OS / パッチ	ユーザー	AWS
ノードの自動増減(Karpenter)	ユーザーが導入	AWS が組み込み
ロードバランサー連携	ユーザーが導入	AWS が組み込み
ブロックストレージ(EBS CSI)	ユーザーが導入	AWS が組み込み

公式ドキュメントによると、Auto Mode クラスタを eksctl やコンソールで作成した場合、クラスタ内で動く Pod は Metrics Server のみで、Karpenter / AWS Load Balancer Controller / EBS CSI Driver などは「すべてクラスタ外で AWS が実行・管理」されます。

引用: “If you create a cluster with eksctl or the AWS console, the only pods running in an EKS Auto Mode cluster are Kubernetes Metrics Server pods.”

出典: EKS Best Practices – Auto Mode

実機で検証した結果、両クラスタでワークロードを稼働させた状態で kubectl get pods -A を実行したところ、明確な差が出ました。

Auto Mode クラスタの kubectl get pods -A 出力

$ kubectl get pods -A
NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE
default       nginx-6d96c84f86-7hqxk            1/1     Running   0          18h
default       nginx-6d96c84f86-hvgb4            1/1     Running   0          18h
default       postgres-0                        1/1     Running   0          18h
kube-system   metrics-server-54d494bcc8-58xjm   1/1     Running   0          18h
kube-system   metrics-server-54d494bcc8-tdxjc   1/1     Running   0          18h

standard クラスタの kubectl get pods -A出力(同じワークロードを稼働)

$ kubectl get pods -A
NAMESPACE     NAME                                            READY   STATUS    RESTARTS   AGE
default       nginx-6d96c84f86-b6fbk                          1/1     Running   0          19h
default       nginx-6d96c84f86-vmfcj                          1/1     Running   0          19h
default       postgres-0                                      1/1     Running   0          19h
kube-system   aws-load-balancer-controller-65bb7d57f7-5w27v   1/1     Running   0          19h
kube-system   aws-load-balancer-controller-65bb7d57f7-ksppz   1/1     Running   0          19h
kube-system   aws-node-4gwch                                  2/2     Running   0          7d2h
kube-system   aws-node-n6jf2                                  2/2     Running   0          7d2h
kube-system   coredns-78bd55977d-mb47l                        1/1     Running   0          7d2h
kube-system   coredns-78bd55977d-nrfj2                        1/1     Running   0          7d2h
kube-system   ebs-csi-controller-995c565c-sqxn7               6/6     Running   0          7d2h
kube-system   ebs-csi-controller-995c565c-zdqvg               6/6     Running   0          7d2h
kube-system   ebs-csi-node-pvm7r                               3/3     Running   0          7d2h
kube-system   ebs-csi-node-vv9n7                               3/3     Running   0          7d2h
kube-system   karpenter-7b76fbfd66-6v7r5                      1/1     Running   0          6d23h
kube-system   karpenter-7b76fbfd66-vznvh                      1/1     Running   0          6d23h
kube-system   kube-proxy-bqmnb                                1/1     Running   0          7d2h
kube-system   kube-proxy-xs4tj                                1/1     Running   0          7d2h
kube-system   metrics-server-6bf9f46b5-498xs                  1/1     Running   0          7d2h
kube-system   metrics-server-6bf9f46b5-mkj4q                  1/1     Running   0          7d2h

→ アプリケーション(default ネームスペースの 3 Pod: nginx × 2 + postgres × 1)は両クラスタで同一。差は kube-system ネームスペースに現れます:

Auto Mode: 2 Pod(metrics-server のみ)
standard: 16 Pod(8 種類のアドオン × 2 Pod ずつ)

これが「ユーザー管理範囲」の差です。

3.3 Auto Mode の独自リソースと料金モデル

Auto Mode は、ノード管理に Karpenter ベースの仕組みを採用しています。新規クラスタには、あらかじめ2つの NodePool(general-purpose と system)が組み込みで設定されています(Enable or Disable Built-in NodePools):

$ kubectl get nodepool
NAME              NODECLASS   NODES   READY   AGE
general-purpose   default     0       True    10m
system            default     2       True    10m

料金面では、EC2 の標準料金に加えて、Auto Mode が管理するノードに対する管理手数料がインスタンスタイプごとに加算されます(Amazon EKS の料金ページ参照)。AWS 公式ページの Example(c6a.2xlarge)では EC2 料金($0.306/h)に対し管理料 $0.03672/h = 約 12% に相当しますが、AWS は「12%」という率を明言しているわけではなく、インスタンスタイプによって金額が異なります。本記事の軸③で実測値を提示します。

4. 検証環境とワークロード

4.1 環境スペック

公平な比較のため、両クラスタを同一スペックで構築します。

項目	値
リージョン	ap-northeast-1(東京)
AZ	2つ(ap-northeast-1a / 1c)
VPC CIDR	10.0.0.0/16(auto-mode は 10.1.0.0/16)
Kubernetes バージョン	1.34
ノード	t3.medium × 2
EBS	gp3 30GB × 2
NAT Gateway	× 1
eksctl バージョン	0.226.0-dev

注: HA 性能は今回の比較軸に含まれないため、検証コストを抑える最小構成を採用しています。本番運用では NAT Gateway の冗長化(各 AZ 配置)や 3 AZ 構成が推奨されます。

4.2 検証ワークロード

両クラスタに 完全に同じアプリ群 を載せて、その挙動の違いを比較します。違うアプリを動かすと「クラスタの差」と「アプリの差」が混ざってしまい、純粋な比較ができないためです。

デプロイする 2 つのアプリ群(独立して動作)

両クラスタに、以下の 2 つのアプリ群 を載せます。両アプリ群は クラスタ内で独立にデプロイされ、お互い通信しません。検証用に「ステートレス・ステートフル両方のアプリ」を観測したいので、並べているだけです。

アプリ群 1: ステートレスアプリ(nginx + ALB)

役割	リソース
外部公開	ALB Ingress
アプリ本体	nginx Deployment + Service
自動スケール	HPA + Metrics Server

アプリ群 2: ステートフルアプリ(postgres + EBS)

役割	リソース
データベース本体	postgres StatefulSet
永続ストレージ	PVC + EBS Volume

観測ポイント

リソース	役割	観測する軸
nginx Deployment + Service	基本的なステートレスアプリ	構築 / 移行
Postgres StatefulSet + PVC	ステートフル + ストレージ	移行(StorageClass の差)
ALB Ingress	外部公開	移行(IngressClass の差)
HPA + Metrics Server	Pod 自動スケール	学習

このワークロード一式を立てるだけで、標準クラスタでは Karpenter / AWS Load Balancer Controller / EBS CSI Driver / Metrics Server の 4 つのアドオンを手動で導入 する必要があります。Auto Mode ではこれらが組み込み済みです。

4.3 検証の前提と限界

ランニングコストは「両クラスタを同時に48時間並走」させて計測します(別々の時間帯で計測すると、AWS のメンテナンスや日次のトラフィック差などが片方だけに影響して比較を歪めるため)。
検証ワークロードは最小構成のため、本番規模とは料金スケールが異なります。
標準クラスタを先に構築するため、Auto Mode 側は学習効果で作業が早くなる可能性があります(この点は結果に注釈します)。

5. 4軸での比較

5.0 なぜこの4軸か

新規に EKS を採用するチームが「どちらを選ぶか」を判断するとき、気になるのは次の4点だと考えました。

軸	読者の疑問
① 構築コスト	立ち上げにどれだけ手間がかかる？
② 学習コスト	チームにどれだけの知識が必要？
③ ランニングコスト	動かし続けるのにいくらかかる？
④ 移行容易性	後から乗り換えられる？ロックインは？

5.1 構築コスト

「同じ環境を立ち上げるのにどれだけ手間がかかるか」を実測しました。

項目	standard	auto-mode
`cluster-config.yaml` 行数	68 行	22 行(-68%)
アドオン手動導入	3 種類(Karpenter / ALB Controller / EBS CSI Driver)	0(すべて組み込み)
自作 YAML(NodePool / StorageClass / IngressClass 等)	57 行	0 行
作成された IAM ロール	+7(クラスタ +3 / EBS CSI +1 / Karpenter +2 / ALB Controller +1)	+2
累計作業時間	約 3〜4 時間(ハマり込み)	クラスタ作成 12 分のみ

設定ファイルの行数の根拠

$ wc -l standard-cluster/cluster-config.yaml auto-mode-cluster/cluster-config.yaml
  68 standard-cluster/cluster-config.yaml
  22 auto-mode-cluster/cluster-config.yaml

IAM ロール数の根拠

構築前: 16
standard 構築後: 19(+3)
EBS CSI Driver 導入後: 20(+1)
Karpenter 導入後: 22(+2)
ALB Controller 導入後: 23(+1、累計 +7)
auto-mode 構築後: 25(+2)

決定的なのは「Karpenter の導入手順 7 ステップが丸ごと消える」こと。CloudFormation での IAM/SQS 作成、サブネット/SG タグ付け、Controller の IRSA ロール、access entry、Helm install、NodePool 作成 — これらすべてが Auto Mode では不要です。

5.2 学習コスト

k8s 基礎の学習(両クラスタ共通の大前提)

EKS の比較に入る前に、Kubernetes の基本概念はどちらのモードを選ぶにせよ必須です。筆者は完全初学者から始めたため、ハンズオンを通じて以下を一通り学習しました:

カテゴリ	学んだ概念
ワークロード	Pod / Deployment / StatefulSet / DaemonSet / ReplicaSet
ネットワーク	Service / Ingress / IngressClass
ストレージ	PVC / PV / StorageClass
自動スケール	HPA / Cluster Autoscaler / Karpenter
その他	ConfigMap / Secret / Namespace / Volume

これらの理解には、筆者の場合 約 2 週間 のローカル(minikube)+ ハンズオン期間を要しました。EKS を選ぶ前に、ローカルで k8s の基礎を一通り触っておくことを推奨します。

→ 上記の前提が満たされている場合の、standard と Auto Mode の追加学習コストは以下の通り差が出ます:

領域	standard で追加で必要	Auto Mode で追加で必要
IAM	IRSA(IAM Roles for Service Accounts)の設定	ほぼ不要(Pod Identity Agent が組み込み)
ノード管理	Karpenter の概念 / NodePool / EC2NodeClass / access entry	NodePool(Auto Mode 版、概念はほぼ同じ)
ロードバランサー	ALB Controller の各種アノテーション仕様	IngressClassParams(Auto Mode 独自リソース)
ストレージ	StorageClass + EBS CSI Driver の概念 + IRSA	StorageClass のみ(provisioner が違うだけ)
インストールツール	Helm / CloudFormation / eksctl の使い分け	eksctl のみ
ハマりやすさ	高(後述の 3 つに遭遇)	低(クラスタを作るだけ)

→ Auto Mode は「k8s 基礎 + α」で済むが、standard は「k8s 基礎 + クラスタ運用ツール群」を一気に把握する必要があります。これが学習コスト軸の実体です。

standard 側のハマりポイント(実体験)

standard 側で実際にハマったポイントを記録しました。Auto Mode では原理的にこれらに遭遇しません。

#	ハマりどころ	解決時間
1	metrics-server の予期せぬ自動導入	調査 30 分
2	Karpenter の Controller ポリシーが 6 分割	調査 15 分
3	IAM ポリシー再利用が裏目に	調査 15-20 分

① metrics-server の予期せぬ自動導入

cluster-config.yaml の addons セクションに 書いていないのに metrics-server が自動でデプロイされました。

該当 cluster-config.yaml と eksctl ログ

cluster-config.yaml(addons セクション):

addons:
  - name: vpc-cni    # Pod に VPC の IP を割り当てる(必須)
  - name: coredns    # クラスター内 DNS 解決(必須)
  - name: kube-proxy # Pod 間ネットワーク通信(必須)

eksctl 実行ログ(metrics-server が勝手に出てくる):

2026-05-29 11:33:47 [ℹ]  creating addon: metrics-server
2026-05-29 11:33:47 [ℹ]  successfully created addon: metrics-server

AWS 公式ドキュメント(Kubernetes Metrics Server)には「Metrics Server は EKS クラスタにデフォルトでは展開されない」と明記されているため、最初は混乱しました。

調査の結果、これは eksctl v0.201.0(2025-01)からの仕様 で、コミュニティでも議論中(Issue #8652、廃止 PR は却下)。eksctl チームは「意図的な挙動」と回答しています。

→ 「公式 EKS は入れない」と「eksctl は入れる」のギャップは、ドキュメントを読むだけでは気付かない罠です。

② Karpenter の Controller ポリシーが 6 分割

Karpenter は AWS の API(ノード起動、IAM 連携など)を呼ぶため、専用の IAM 権限を Karpenter Pod に渡す必要があります。Karpenter v1.x では必要権限が増え(Zonal Shift 対応など)、IAM ポリシーのサイズ上限対策として 6 個のマネージドポリシーに分割されました(Issue #7874)。ネット上で見つかる Karpenter インストール解説記事(Qiita / Zenn / 個人ブログ等)の多くは v0.x 時代のもので、「KarpenterControllerPolicy という 1 つのポリシーをアタッチすれば OK」と書かれていますが、そのポリシーには v1.x で増えた権限が含まれていない ため、v1.x の Karpenter は権限不足で動きません。

用語:

IAM ポリシー: AWS の「これはやっていい / だめ」のルール書

アタッチ(attach): ポリシー(=権限)を IAM ロールに「付ける」操作

Controller: Karpenter 本体の Pod(クラスタ内で常駐して動く)

身近な例で言うと、昔は万能鍵 1 本で済んでいたのが、今は用途別の 6 本の鍵を全部渡さないとどこかのドアが開かない、というイメージです。

6 個の Karpenter Controller ポリシーの内訳

ポリシー名	何ができる権限か
`KarpenterControllerNodeLifecyclePolicy-<cluster>`	ノード(EC2)の起動・停止
`KarpenterControllerIAMIntegrationPolicy-<cluster>`	IAM 連携(Pod に権限を渡すなど)
`KarpenterControllerEKSIntegrationPolicy-<cluster>`	EKS API の操作
`KarpenterControllerInterruptionPolicy-<cluster>`	Spot インスタンス中断通知の処理
`KarpenterControllerZonalShiftPolicy-<cluster>`	AZ 障害時のトラフィック切り替え
`KarpenterControllerResourceDiscoveryPolicy-<cluster>`	サブネット・SG などのリソース発見

解決法: eksctl create iamserviceaccount の --attach-policy-arn オプションを 6 回繰り返して 全ポリシーを Karpenter Controller の IAM ロールにアタッチする。

→ v0.x 時代の解説記事を信じて 1 個だけアタッチすると、Karpenter が「権限がない」エラーで動かない、というのが本検証でハマったポイントでした。検索で出てくる記事が新しいか古いかは Karpenter のバージョン(v0.x or v1.x)で見分ける のが確実です。

出典:

Karpenter Getting Started – CloudFormation テンプレート — v1.x の 6 個マネージドポリシーの定義元

GitHub Issue #7874 – karpenter-provider-aws — IAM ポリシーサイズ上限対策で分割された経緯

③ IAM ポリシー再利用が裏目に

AWS アカウントに残っていた既存の AWSLoadBalancerControllerIAMPolicy(過去に別の作業で作成済み)を再利用したところ、ALB Controller v2.14.1 が新 API elasticloadbalancing:DescribeListenerAttributes を呼ぶため、403 になり ALB target group バインディングが完了せず HTTP 404 が返り続けました。

エラーログ

"error":"operation error Elastic Load Balancing v2: DescribeListenerAttributes,
 https response error StatusCode: 403, ...
 AccessDenied: User: arn:aws:sts::xxx:assumed-role/AmazonEKSLoadBalancerControllerRole-standard/...
 is not authorized to perform: elasticloadbalancing:DescribeListenerAttributes
 because no identity-based policy allows the elasticloadbalancing:DescribeListenerAttributes action"

解決: v2.14.1 の iam_policy.json で create-policy-version --set-as-default してポリシーを更新、ALB Controller を rollout restart。

→ 「IAM ポリシーの再利用」は時短になるが、Controller のバージョンアップ時に詰まる。Auto Mode ではこの問題が原理的に発生しません(IAM ポリシーをユーザーが管理しないため)。

Auto Mode はこれら 3 つすべてに無縁。クラスタを作るだけで動きます。

5.3 ランニングコスト

両クラスタを同条件で 48 時間並走させ、Cost Explorer のサービス別日次集計から実測しました

重要な前提：ノード構成の違い

検証中に判明したのは「Auto Mode は cluster-config に instanceType を書かないため、組み込み Karpenter がノードを自動選定する」こと。実際の選定結果は以下の通りでした:

クラスタ	ノード	インスタンスタイプ
standard	2 台	t3.medium × 2(明示指定)
auto-mode	2 台	c5a.large + c6g.large(Karpenter が自動選定、ARM も混在)

→ Auto Mode 側はやや高単価のインスタンスを選ぶため、「同じインスタンスタイプ同士の加算料金比較」にはなりませんでした。

48h 並走コスト(Tax 除く、クラスタ別推定)

standard 単独期間(5/30-6/3)との差分から算出:

サービス	standard 48h	auto-mode 48h	差額
EC2 – Compute(インスタンス)	$5.22	$8.72	+$3.50
EC2 – Other(EBS / データ転送)	$3.40	$4.20	+$0.80
EKS Control Plane(+ Auto Mode 加算)	$4.80	$5.84	+$1.04
ALB	$1.17	$1.17	$0
Public IPv4 アドレス	$0.72	$0.72	$0
48h 合計	$15.31	$20.65	+$5.34(約 +35%)

両クラスタ合計の実測: $35.96 / 48h

Auto Mode 加算料金の実測 – 観測 6 タイプすべてで 12.0% に一致

AWS 公式の Example(c6a.2xlarge)では加算料金が EC2 料金の約 12% に相当します(料金ページ)。本検証でも Cost Explorer の APN1-EKS-Auto:*-management-hours から管理料金を直接読み取って検証しました:

APN1-EKS-Auto:c5a.large-management-hours (48h): $0.55296
APN1-EKS-Auto:c6g.large-management-hours (48h): $0.4931
─────────────────────────────────────────────────────────
合計:                                            $1.046

→ 上記合計 $1.046 は、サービス別表の EKS 行の差額 +$1.04 と一致します(管理料金は EKS 側の専用 usage type に計上されており、EC2 – Compute には含まれていません)。

各タイプの加算率(管理料金 ÷ 東京リージョン EC2 標準価格):

タイプ	管理料金 / 1h	EC2 標準価格 / 1h	率
c5a.large	$0.01152	$0.096	12.0%
c6g.large	$0.010272	$0.0856	12.0%

→ 本検証の 2 タイプとも 12.0% で、AWS 公式 Example 4(c6a.2xlarge / c6a.4xlarge / m5a.2xlarge / m5a.xlarge)の 4 タイプすべての 12.0% と完全に一致しました。観測したインスタンスタイプ計 6 種類すべてで率が 12.0% に揃っています(ただし AWS は「率は 12% 固定」とは明言しておらず、公式表現は「インスタンスタイプによって変動する」までです)。

月額換算

48h を 1ヶ月(720h)に換算すると:

構成	月額
standard(t3.medium × 2)	約 $230 / 月
auto-mode(Karpenter 自動選定 c5a/c6g)	約 $310 / 月
差額	+$80 / 月(約 35% 高)

→ 「Auto Mode の手間削減と引き換えに月額約 $80 上乗せ」が、本検証規模での実額です。

補足: この +35% は Karpenter を絞れば縮む

本検証の +35% は Karpenter を無制約にした結果です。Auto Mode の NodePool には requirements フィールドがあり、instance family / type を絞ることができます:

spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["t3"]

→ 同等のインスタンスタイプに揃えれば、差は 管理料金分(観測した 6 タイプすべてで 12.0%)程度に縮む可能性があります(本検証では未検証)。本記事の「+35%」は Karpenter を絞らないデフォルト挙動の結果であって、Auto Mode の本質的な料金プレミアムではない点に注意してください。

注意点・限界

本検証はノードが各クラスタ 2 台の最小構成。本番規模ではスケール特性で比率が変わる可能性
表の「Public IPv4 アドレス」行は PublicIPv4:InUseAddress 課金($0.005/h/個)。物的検証の結果、両クラスタとも対称的に 3 個ずつ保有(NAT GW × 1 + ALB の AZ ごと × 2)であることが確定。auto-mode の組み込み NodeClass は eksctl が Private Subnet ID を直接埋め込む仕様のため、ノードに Public IP は付かない(kubectl get nodes -o wide で EXTERNAL-IP = None を確認済み)。eksctl で作成した本検証構成では、Auto Mode が何も指定しなくてもノードを Private Subnet に配置する(これは eksctl 固有の挙動。AWS 公式の Auto Mode 仕様自体は「public/private どちらでも可能」)
Cost Explorer の最小粒度が日次のため、純粋な 48h ぴったりの切り出しではなく「6/5(24h)+ 6/6(24h)」の 2 日分

5.4 移行容易性

両方向で実機検証しました。アプリ層の YAML(Deployment / Service / Secret / HPA)は両方向とも 1 行も書き換えずに動きます。書き換えが必要なのは AWS 連携リソース 3 種類のみ(StorageClass / IngressClass / IngressClassParams)。

リソース	standard → Auto Mode	Auto Mode → standard
StorageClass	provisioner 書き換え(`ebs.csi.aws.com` → `ebs.csi.eks.amazonaws.com`)	逆方向書き換え
IngressClass	controller 書き換え + IngressClassParams 参照追加	`controller` フィールドが immutable で既存と衝突
IngressClassParams	Auto Mode 独自リソース、新規作成	CRD が存在しないため持ち込み不可
EBS CSI Driver / Karpenter / ALB Controller	削除(不要)	再導入が必要(手間が大きい)

逆方向の検証で得たエラーが、難易度差の根拠です:

$ kubectl apply -f auto-mode-cluster/addons/ingressclass.yaml --dry-run=server
resource mapping not found for name: "alb" namespace: "" from
".../ingressclass.yaml": no matches for kind "IngressClassParams" in
version "eks.amazonaws.com/v1"
ensure CRDs are installed first

Error from server (Invalid): IngressClass.networking.k8s.io "alb" is invalid:
spec.controller: Invalid value: "eks.amazonaws.com/alb": field is immutable

重要: 移行方向で難易度が違う

standard → Auto Mode: 書き換え量は限定的、移行は容易
Auto Mode → standard: IngressClassParams を完全に捨て、各種 Controller を再導入 → 手間が大きい

→ 「Auto Mode で始めると、後から standard に戻すコストが高い」=部分的なロックインがあります。逆に「standard で始めれば、後から Auto Mode へは比較的楽に移行可能」。手順の詳細は次章で。

6. 移行プロセスの詳細

ここでは、実際に行った双方向の移行プロセスを具体的に示します。

6.1 standard → Auto Mode の移行手順

1. 不要なアドオンの削除

Karpenter / ALB Controller / EBS CSI Driver は Auto Mode が管理するので削除可能。ただし「standard で動いている Pod がぶら下がっている」ので、まずワークロードを引き剥がす順序で。

2. StorageClass の書き換え

- provisioner: ebs.csi.aws.com         # standard(自分で立てた EBS CSI Driver)
+ provisioner: ebs.csi.eks.amazonaws.com  # Auto Mode 組み込み

3. IngressClassParams を新規作成(Auto Mode 独自リソース、standard には存在しない)

apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
  name: alb
spec:
  scheme: internet-facing

4. IngressClass を書き換え

- controller: ingress.k8s.aws/alb       # standard(自分で立てた ALB Controller)
+ controller: eks.amazonaws.com/alb     # Auto Mode 組み込み
+ parameters:
+   apiGroup: eks.amazonaws.com
+   kind: IngressClassParams
+   name: alb

5. Ingress 本体からアノテーションを削除(IngressClassParams に移したため)

- annotations:
-   alb.ingress.kubernetes.io/scheme: internet-facing

6. PVC の storageClassName を新しい StorageClass 名に

- storageClassName: ebs-gp3
+ storageClassName: auto-ebs-sc

実機ではこの手順で 3〜4 分でデプロイ完了、HTTP 200 取得まで一気に到達しました。

6.2 Auto Mode → standard の移行手順(こちらが難しい)

IngressClassParams を捨てる(standard 側では CRD 自体が存在しないため)
IngressClass の controller を書き換え: ただし既存に同名 IngressClass があると field is immutable で失敗するので、既存を一度削除する必要がある
EBS CSI Driver を手動導入(IRSA + addon + 自作 StorageClass)
Karpenter を手動導入(前述の 7 ステップ)
ALB Controller を手動導入(IRSA + IAM ポリシー + Helm install)
その後 standard 用に書き換えた YAML をデプロイ

→ ステップ数も時間も逆方向は段違いに多くなります。これが「Auto Mode → standard が高難易度」と評価する根拠です。

7. まとめと採用判断

EKS の Auto Mode と standard を 4 軸で実測比較しました。結論として、新規 EKS 採用は 「運用負担を軽くしたいなら Auto Mode、コストを抑えたいなら standard」 というトレードオフになります。Auto Mode は楽だが月額約 +$80 の追加コストと逆移行の重さがあり、standard は手間がかかるが自由度・コストを最適化できる、という関係です。

7.1 タイプ別の推奨

あなたのチームはどのタイプに当てはまりますか？

こんなチーム	推奨	理由
初めての EKS、すぐ動かしたい	Auto Mode	構築・学習コストが圧倒的に低い
Karpenter / ALB Controller を細かくチューニングしたい	standard	各 Controller への完全な制御権
将来 standard に戻す可能性がある	standard で始める	逆移行コストを避ける
月額約 $80 の追加料金より運用負担削減を優先	Auto Mode	本検証規模では auto-mode が月額約 +$80
K8s 経験が浅いチーム	Auto Mode	アドオン手動導入で詰まる時間が業務価値を生まない

7.2 私自身の見解

検証を通じて一番感じたのは、「Auto Mode は楽だが、安くはない」 ということでした。構築・学習コストの差は体感でも圧倒的で、初めての EKS や小規模チームには素直に Auto Mode を勧めたいです。

ただ、「将来 standard に戻すかも」「各 Controller を細かくチューニングしたい」なら、最初から standard を選ぶ方が手戻りが少ない、というのが実際に両方を触った上での所感です。

8. 参考文献

AWS 公式ドキュメント

EKS Auto Mode 公式ドキュメント — Auto Mode の全体像と「deep EKS expertise 不要」の表現。3.1 の引用元
Security Overview of Amazon EKS Auto Mode – EKS control plane — 「EKS-managed VPC」「データプレーン運用の AWS 移譲」の引用元。3.2 の根拠
EKS Best Practices – Auto Mode — 「クラスタ内 Pod は Metrics Server のみ」の引用元。3.2 の根拠
EKS Best Practices – VPC and Subnet Considerations — 「最低 2 AZ 以上」推奨の根拠。4.1 注記
Enable or Disable Built-in NodePools — 組み込み NodePool(general-purpose / system)の仕様根拠。3.3
Create an IngressClass to configure an Application Load Balancer (EKS Auto Mode) — Auto Mode の IngressClass / IngressClassParams 仕様。5.4 / 6.1
Create a storage class (EKS Auto Mode) — Auto Mode の StorageClass provisioner(ebs.csi.eks.amazonaws.com)仕様。5.4 / 6.1
View resource usage with the Kubernetes Metrics Server — 「Metrics Server は EKS にデフォルトで展開されない」の引用元。5.2 ①
Install AWS Load Balancer Controller with Helm — standard クラスタへの ALB Controller インストール手順。5.1 / 5.2 ③
Amazon EKS の料金ページ — Auto Mode 加算料金の Example 4(c6a/m5a 系 4 タイプ)の出典。3.3 / 5.3

Karpenter / eksctl

Karpenter Getting Started – CloudFormation テンプレート — v1.x で生成される 6 個のマネージドポリシーの正式な定義。5.2 ② の根拠
GitHub Issue #7874 – karpenter-provider-aws — IAM ポリシーがサイズ上限対策で 6 個に分割された経緯。5.2 ②
Karpenter Upgrading Compatibility — Karpenter v0.x → v1.x のバージョン互換性情報
eksctl Addons — eksctl の addons 機能仕様。5.2 ① の挙動の前提

GitHub Issue / PR(metrics-server 自動導入の根拠)

eksctl PR #8118 – Support create cluster default addon metrics-server — metrics-server を eksctl デフォルトで入れるようにした PR。5.2 ① の根拠
eksctl Issue #8652 – eksctl unexpectedly installs metrics-server addon — この仕様への疑問・議論スレッド(eksctl チームは「意図的」と回答)。5.2 ①
eksctl v0.201.0 リリースノート — metrics-server 自動導入が入ったバージョンの公式リリースノート

Public IPv4 課金

New AWS Public IPv4 Address Charge + Public IP Insights (AWS Blog) — 2024/2/1 から Public IPv4 が $0.005/IP/h で課金開始されたことの公式アナウンス。5.3 注意点・限界 の前提

SRE NEXT 2026に参加してきました！