EKS Auto Modeは、Amazon EKSのマネージド範囲をコントロールプレーンの外側へ広げ、ノードの調達とパッチ適用、ロードバランサーやEBSボリュームの払い出しまでAWSに委ねる動作モードです。Karpenterによるオートスケーリングやロードバランシングをアドオンではなくコア機能として持つ一方、ビルトインNodePoolはオンデマンド専用、ノードへのSSHは不可、対応OSはLinuxのみという制約も抱えます。公式ドキュメントの記述をもとに、任せられる範囲と手元に残る責任、有効化のコマンド、料金の内訳、2026年4月22日から変わったマネージドリソースの見え方までを整理します。
まとめ
- AWSが引き受けるのはEC2インスタンスのライフサイクルとOS・パッチ、オートスケーリング、Podネットワーキングとネットワークポリシー、ELB連携、ブロックストレージのドライバー構成。アプリケーションコンテナとVPC・クラスター設定は利用者の責任のまま。
- 有効化にはクラスター用とノード用の2つのIAMロールが要る。
aws eks create-clusterでcomputeConfig・kubernetesNetworkConfig.elasticLoadBalancing・storageConfig.blockStorageを同時に有効化し、認証モードはAPIを指定する。 - ビルトインNodePoolは
systemとgeneral-purposeの2つ。どちらもC・M・Rファミリーの第5世代以降、オンデマンド容量のみ。Spotを使うにはカスタムNodePoolが必須。 - 料金はクラスター料金（標準サポートで0.10ドル/時）とEC2料金に管理手数料が上乗せされる三層構造。手数料は購入オプションに依存せず、秒単位・最低1分で課金される。
- 2026年4月22日以降に作られたマネージドインスタンスと付随リソースは、EC2コンソールと
describe系のリスト操作から既定で非表示になる。棚卸しやCSPMの対象範囲を見直す必要がある。 - Windowsコンテナ、ノードへのSSH/SSM接続、AMI固定が要件なら採用できない。判断基準は本文最後の章で条件付きに示す。
Auto Modeが肩代わりする管理範囲と、手元に残る責任
Auto Modeの本質は、Kubernetesの機能をアドオンではなくコアコンポーネントとして扱う点にあります。公式ドキュメントは、AWSが管理するクラスターインフラに「compute autoscaling, pod and service networking, application load balancing, cluster DNS, block storage, and GPU support」が含まれると明記しています。標準EKSでEBS CSIドライバーやAWS Load Balancer Controllerを自分でインストールしてバージョンを追いかけていた運用は、ここで消えます。
AWS側に移る責任と、利用者に残り続ける責任
AWS側は、起動したEC2インスタンスのライフサイクル全体（OS設定・パッチ適用・監視・ヘルス維持）、オートスケーリング、ネットワークポリシー適用を含むPodネットワーキング、Elastic Load Balancing連携、ストレージドライバーの構成を受け持ちます。ノードにはBottlerocketの派生AMIが使われ、ソフトウェアはロックダウン、ルートファイルシステムは読み取り専用、SSHやSSMによる直接通信は遮断されます。
可用性まわりでは、Amazon Application Recovery Controller（ARC）のゾーンシフトとの連携も自動で効きます。障害の起きたアベイラビリティゾーンではノードの新規プロビジョニングを止め、ゾーンシフト中は自発的な中断（voluntary disruption）を保留します。AZ障害時にKarpenterが劣化したAZへノードを補充し続ける、という標準構成でありがちな挙動を、設定なしで避けられる点は見落とされがちです。
それでも「全部おまかせ」ではありません。公式ドキュメントは「customers continue to maintain responsibility for the application containers, including availability, security, and monitoring. They also maintain control over VPC infrastructure and EKS cluster configuration」と述べています。VPCの設計とサブネットの配置、クラスター構成、アプリケーションの可用性とセキュリティは自分で持ち続けます。EKS本体のノード提供形態や料金モデルを先に押さえたい場合は、Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説で全体像を確認してください。
標準EKSのマネージドノードグループとの違い
マネージドノードグループとAuto ModeのNodePoolは別物ですが、同一クラスター内に共存できます。決定的な違いは、Auto Modeのインスタンスが「マネージドインスタンス」としてEKSに所有される点です。公式の比較表は、標準EC2インスタンスなら利用者がパッチと更新を担いSSHで入れるのに対し、マネージドインスタンスではEKSが kubelet・コンテナランタイム・OSに責任を持ち、利用者にできるのはPodとコンテナのデプロイだけだと整理しています。インスタンスタイプの選定もAWS側が行い、利用者はNodePoolで選択肢を絞り込む形で関与します。Pod Identity AgentとNeuron Device Pluginのインストールも不要です。ただし他のノードが混在するクラスターでは、Neuron Device PluginがAuto Modeノード上で動かないよう設定を分けてください。
AWS CLIでのAuto Modeクラスター作成と既存クラスターでの有効化
先に用意する2つのIAMロールと管理ポリシー
Auto ModeはEC2インスタンスの払い出しなどをアカウント内で実行するため、クラスターIAMロールを必要とします。公式ドキュメントが推奨する管理ポリシーは5つです。
# trust-policy.json のプリンシパルは eks.amazonaws.com、
# Action は sts:AssumeRole と sts:TagSession の2つ
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
for P in AmazonEKSClusterPolicy AmazonEKSComputePolicy \
AmazonEKSBlockStoragePolicyV2 AmazonEKSLoadBalancingPolicy \
AmazonEKSNetworkingPolicy; do
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/$P
doneノードIAMロールは別に作ります。付けるのは AmazonEKSWorkerNodeMinimalPolicy と AmazonEC2ContainerRegistryPullOnly の2つだけ。名前のとおり最小権限で、ノード上のワークロードにAWSサービスへの権限を渡したい場合はこのロールを太らせず、EKS Pod Identityを使います。信頼ポリシーのプリンシパルはクラスターロールが eks.amazonaws.com、ノードロールが ec2.amazonaws.com と異なる点に注意してください。サービスリンクロールのAWSServiceRoleForAmazonEKSは自動作成されます。
create-clusterで有効化する3つの設定ブロック
Auto Modeはひとつのフラグではなく、コンピュート・ロードバランシング・ブロックストレージの3ブロックを揃えて有効化します。認証モードは API、つまりEKSアクセスエントリが前提です。実行前に環境変数を設定しておきます。
export AWS_REGION=us-east-1
export CLUSTER_NAME=my-auto-cluster
export K8S_VERSION=1.35
export CLUSTER_ROLE_ARN=arn:aws:iam::111122223333:role/AmazonEKSAutoClusterRole
export NODE_ROLE_ARN=arn:aws:iam::111122223333:role/AmazonEKSAutoNodeRole
export SUBNETS_JSON='["subnet-ExampleID1","subnet-ExampleID2","subnet-ExampleID3"]'
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": { \"enabled\": true }
},
\"storageConfig\": {
\"blockStorage\": { \"enabled\": true }
},
\"accessConfig\": { \"authenticationMode\": \"API\" }
}"クラスターの作成には約15分かかると公式ドキュメントは案内しています。完了後は aws eks update-kubeconfig --name "${CLUSTER_NAME}" でkubeconfigを更新し、kubectl get nodepools でNodePoolが2つ見えることを確認します。ノードはPodがスケジュールできない状態を検知してから起動するため、この時点で0台でも異常ではありません。
既存クラスターでの切り替えとNodePoolの出し入れ
既存クラスターへ後から有効化する場合は aws eks update-cluster-config に computeConfig・kubernetesNetworkConfig・storageConfig をまとめて渡します。注意すべきは computeConfig.nodePools の扱いです。ビルトインNodePool名をこの配列から外すと、公式ドキュメントいわく「the corresponding NodePool Kubernetes resource is deleted from the cluster. Any nodes managed by that NodePool are drained and terminated」。KarpenterはKubernetes API経由でNodePoolリソースを見つけるため、削除された時点で供給が止まります。設定変更のつもりでNodePool名を落とすと稼働中ノードのドレインと終了が走るので、容量計画を伴う変更として扱ってください。
ビルトインNodePoolの仕様とSpotインスタンスの扱い
ビルトインNodePoolは system と general-purpose の2つです。system には CriticalAddonsOnly のtaintが付き、CoreDNSをはじめ多くのEKSアドオンがこれをtolerateします。クラスターの中核コンポーネントをアプリケーションから隔離する用途です。general-purpose は一般ワークロード向けでamd64のみ、system はamd64とarm64の両方をサポートします。
| 項目 | ビルトインNodePool | カスタムNodePool |
|---|---|---|
| インスタンスファミリー | C / M / R のみ | 自分で指定 |
| 世代 | 第5世代以降 | 自分で指定 |
| 容量タイプ | オンデマンドのみ | spot / on-demand / reserved |
| アーキテクチャ（system） | amd64 + arm64 | 自分で指定 |
| アーキテクチャ（general-purpose） | amd64 のみ | 自分で指定 |
| リソース上限 limits | 未設定（無制限） | 自分で設定 |
| 編集 | 不可（有効/無効の切替のみ） | 可 |
実務でいちばん効いてくるのは容量タイプと limits の行です。ビルトインNodePoolは上限なしにスケールします。
Spot利用に必須となるカスタムNodePoolの書き方
ビルトインNodePoolでSpotは選べません。公式のコスト最適化ドキュメントは、その特性を「On-demand capacity only — No Spot instances, which avoids interruption-driven churn but also means no Spot savings」と明記しています。中断による入れ替わりを避ける代わりに、Spotの割引も得られない設計です。Spotを使うなら karpenter.sh/capacity-type を指定したカスタムNodePoolを作ります。中断耐性のあるCI/CDランナー向けの構成例が公式ドキュメントに掲載されています。
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: ci-runners
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: Lte
values: ["32"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
limits:
cpu: "500"
memory: 1000Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 30s容量タイプを明示しない場合、Karpenterは reserved、spot、on-demand の順に優先します。Auto Modeのラベルは素のKarpenterと異なり、EC2マネージドインスタンス関連は eks.amazonaws.com で始まります。Karpenterの記事や既存マニフェストをそのまま持ち込むとキー名が合わないので、移植時に読み替えてください。
選ばれるインスタンスの下限条件
Auto Modeが起動するインスタンスには下限があります。CPUが1個より多いこと、サイズがnano・micro・smallでないことです。t3.microで検証環境のコストを抑える運用は成立しません。カスタムNodePoolで選べる対応ファミリーはC・M・R・T・Z/X・I/D・P/G/Inf/Trn・HPCと幅広く（ビルトインNodePoolは前掲のとおりC・M・Rの第5世代以降に限定）、GPU向けにはp6-b200やg7eも含まれます。ただしカスタムNodePoolで制約を書かないと、EC2のサービスクォータが枯渇したときなどにAuto Modeが可用性を優先して高価なインスタンスタイプへフォールバックします。GPUを要求しないワークロードなら instance-category を c・m・r に絞っておくのが安全です。
クラスター料金・EC2料金・管理手数料の三層構造
コストは3層で積み上がります。第1層はEKSクラスター自体の料金で、標準のKubernetesバージョンサポートなら1クラスターあたり0.10ドル/時。Auto Modeでも標準モードでも変わりません。ここで見落としやすいのが延長サポートで、サポート期限を過ぎたバージョンを使い続けると1クラスターあたり0.60ドル/時（標準料金に0.50ドル/時が加算）になります。第2層は起動されたEC2インスタンスそのものの料金です。
第3層が管理手数料です。公式の料金ページは「You pay for EKS Auto Mode based on the duration and type of Amazon EC2 instances launched and managed by EKS Auto Mode. The EKS Auto Mode prices below are in addition to the Amazon EC2 instance price」と説明しています。EC2料金の代わりではなく上乗せです。手数料は購入オプションに依存せず、秒単位・最低1分で課金されます。公式の計算例ではm5a.xlargeが0.02064ドル/時、m5a.2xlargeが0.04128ドル/時、c6a.2xlargeが0.03672ドル/時、c6a.4xlargeが0.07344ドル/時と、おおむねvCPU数に比例します。料金ページはリージョンを明示していないため、実際の単価は使用リージョンで確認してください。
見積もりで外しやすいのは、手数料がインスタンス時間に比例する点です。ノード台数が増えればEC2料金と手数料が両方増え、コンソリデーションが効いて減れば手数料も減ります。次に扱う「最適化が止まる条件」は、そのまま手数料の増減に直結します。
ノード寿命とAMIドリフトによる置き換え周期
Auto Modeのノードは使い捨てです。寿命には既定値と上限という2つの数字があり、これを分けて押さえると設計を外しません。NodePoolのページは既定動作として「Terminates instances after 336 hours」＝14日で置き換えが走ると記載し、概要ページは「nodes launched by EKS Auto Mode have a maximum lifetime of 21 days (which you can reduce)」と、21日を短縮のみ可能な上限として示しています。矛盾ではなく、既定の置き換えタイミングとサービスが強制する上限という別レイヤーの値です。
両者の差が表に出るのは、置き換えがブロックされたときです。公式ドキュメントは「Up to the 21-day maximum lifetime, intervention might be required if blocking PDBs or other configurations prevent updates」と述べています。厳しいPod Disruption Budgetを書いていると336時間を過ぎても置き換えが進まず、最終的に21日で強制的に打ち切られます。PDBの書き方しだいでノードの実寿命が14日側にも21日側にも寄る、というのが実務上の意味です。加えて、新しいAuto Mode AMIがリリースされるたびにドリフト扱いで置き換えが発生します。リリース頻度は「roughly once per week」、週1回程度です。
置き換えは無停止ではありません。新ノードが起動してReadyになり、Pod Disruption Budgetを尊重しながら旧ノードからPodがドレインされ、その間は新旧2台が同時に動きます。ノード数の多いクラスターでは、この重複が周期的なコスト増として現れます。既定のdisruption budgetはノードの10%、terminationGracePeriod をNodePoolで明示していない場合はNodeClaim側に24時間の既定値が適用されます。
コンソリデーションが止まる条件とコスト上限の設計
do-not-disrupt注釈とPDBが最適化を止める仕組み
Auto Modeはbin-packing、コンソリデーション、ライトサイジングの3つでコンピュートコストを継続的に下げます。ところがこれらは、ワークロード側の設定で簡単に無効化されます。
ひとつ目が karpenter.sh/do-not-disrupt: "true" の注釈です。これが付いたPodの載るノードは、使用率が低くてもコンソリデーション・置換・終了の対象から外れます。公式ドキュメントは「The node continues to run at its current instance size regardless of actual utilization」と明言しており、多数のノードに散らばればクラスター全体の最適化が大きく損なわれます。ふたつ目がPod Disruption Budgetです。maxUnavailable: 0 や minAvailable を現在のレプリカ数と同じにしたPDBは、対象Podのコンソリデーションを事実上すべて止めます。可用性のつもりで書いたPDBが、そのままコスト増の設定になっているケースです。
公式ドキュメントの推奨は明快です。do-not-disrupt は中断でデータ損失や大きなやり直しが発生するワークロード、たとえばチェックポイントを持たない長時間バッチに限って使う。CI/CDランナーやビルドエージェントには使わず、CI側のリトライ機構に任せる。中断を止めるのではなく、PDBで中断の速度を制御する。この使い分けだけで、手数料込みのコンピュート費用は変わります。
カスタムNodePoolにはコスト上限を自分で書く
ビルトインNodePoolには limits がありません。バーストしうるワークロードを載せるなら、上限を持つカスタムNodePoolを作るほうが安全です。前掲のサンプルにある limits: cpu: "500" は、そのNodePoolが確保できる合計vCPUを500に固定します。上限に達すると新しいノードは起動せず、Podは Pending のまま待機します。コストを止めるかスケジューリングを止めるか、どちらを優先するかを明示的に決める設定です。
ephemeral storageにも節約の仕組みが入っています。NodeClassで設定したサイズがインスタンスのローカルNVMe容量より小さい場合、Auto Modeは20GiBの小さいEBSデータボリュームを使い、NVMeをフォーマットしてephemeral用に構成します。NVMeが複数あればRAID 0を組みます。逆に ephemeralStorage.size がローカルNVMe容量以上なら、小さいEBSボリュームは作らずNVMeを直接ワークロードへ見せます。
2026年4月22日から変わったマネージドリソースの見え方
運用体制に直接影響する変更が2026年に入りました。公式ドキュメントの注記はこうです。「Beginning April 22, 2026, new Amazon EC2 managed instances and associated resources (for example, EC2 launch templates, EBS volumes, and network interfaces (ENIs)) created by EKS Auto Mode are hidden from EC2 console views and describe API list operations by default.」
対象は新規に作られたリソースだけで、その日より前から存在するものは引き続き表示されます。設定はアカウント全体に適用され、リソース種別や作成元サービスごとの出し分けはできません。隠れているだけなので、リソースは通常どおり稼働し課金も続きます。AWSが挙げる意図は、ガバナンスダッシュボードの単純化、可観測性ツールのノイズ削減、CSPMスキャナーがマネージドリソースを設定不備として誤検知するのを防ぐことです。裏を返せば、EC2の DescribeInstances をインベントリの正本にしている組織では、Auto Modeのノードが棚卸しから丸ごと抜け落ちます。
非表示でも確認手段は残っています。EKSコンソールのクラスターのComputeタブ、kubectl get nodes などのKubernetes API、インスタンスIDを直接指定した describe-instances --instance-ids i-0123456789abcdef0、DescribeInstances の include-managed-resources パラメータ、EC2コンソールでの可視性設定の変更です。資産管理スクリプトがリスト系APIに依存しているなら、パラメータを追加するか可視性設定そのものを変えるかを先に決めておいてください。
Auto Modeを採用すべきでない場面
Auto Modeが向かないケースははっきりしています。以下に当てはまるなら、標準EKSかFargateを検討してください。
- Windowsコンテナを動かす：Auto ModeはLinuxのみ対応で、
kubernetes.io/osとnode.kubernetes.io/windows-buildのラベルはサポート対象外です。回避策はありません。 - ノードへのSSH/SSM接続が運用手順に組み込まれている：Bottlerocket系AMIが直接通信を遮断しています。ノードにログインして調査する障害対応手順は、そのままでは使えません。
- PodからIMDSを叩く必要がある：IMDSv2がhop limit 1で強制され、Auto Modeではこの設定を変更できません。必要なPodは
hostNetwork: trueで動かすことになりますが、メタデータサービスへのアクセスを与える影響は引き受ける前提です。アドオン側にリージョン等のパラメータを渡してIMDS参照を避けるほうが筋のよい対処です。 - AMIを固定してカーネルやエージェントを作り込む：AMIはAWSが決め、週1回程度更新されます。ノードへソフトウェアを直接インストールすることもできません。DaemonSetで代替できない要件があるなら不適合です。
- AWS Fault Injection Serviceでインスタンス障害を注入したい：
ec2:RebootInstances、ec2:StopInstances、ec2:TerminateInstances、ec2:SendSpotInstanceInterruptions、ec2:StartInstances、ec2:PauseVolumeIOは非対応です。Podレベルのaws:eks:podアクションは使えるため、カオスエンジニアリングをPod層に寄せられるかが分かれ目です。
逆に、標準的なLinuxワークロードで、KarpenterとAWS Load Balancer ControllerとEBS CSIドライバーのバージョン追従に人手を割いているなら、Auto Modeへ寄せる価値は高いと言えます。ノードレスで動かす選択肢との比較はEKS Auto ModeとEKS on Fargateの違いが、Kubernetesのバージョン更新計画はKubernetes 1.34の新機能・変更点とEOLが扱っています。
よくある質問
EKS Auto ModeでSpotインスタンスは使えますか？
使えます。ただしビルトインNodePoolでは選べません。system と general-purpose はどちらもオンデマンド容量のみを使う仕様のため、Spotを利用するには karpenter.sh/capacity-type に spot を含むカスタムNodePoolを別途作成します。容量タイプを指定しない場合、Karpenterは reserved、spot、on-demand の順に優先します。中断耐性のあるCI/CDランナーやバッチにはSpot、状態を保持するビルドエージェントにはオンデマンドを組み合わせる構成が公式ドキュメントで推奨されています。
Auto Modeのノードにログインして調査できますか？
できません。Auto Modeのノードはマネージドインスタンスとして扱われ、Bottlerocketの派生AMIがSSHとSSMによる直接通信を遮断しています。ルートファイルシステムは読み取り専用で、SELinuxもenforcingモードです。ノードへソフトウェアを直接インストールすることもできません。監視エージェントなどノード上で動かしたいものがある場合は、DaemonSetとしてデプロイする形に置き換えます。
既存のEKSクラスターをAuto Modeに切り替えられますか？
切り替えられます。新規クラスターを作らずに aws eks update-cluster-config で computeConfig・kubernetesNetworkConfig.elasticLoadBalancing・storageConfig.blockStorage を有効化します。既存のマネージドノードグループとAuto ModeのNodePoolは同一クラスター内に共存できるため、段階的な移行が可能です。なお自己管理のKarpenterを併用する場合は、ワークロードがKarpenterとAuto Modeのどちらに紐づくかをNodePoolで明確に分ける設定が必要です。
Auto Modeの料金はEC2の料金とは別にかかりますか？
別にかかります。公式の料金ページは、Auto Modeの価格が「in addition to the Amazon EC2 instance price」であると明記しています。つまりEC2インスタンス料金に管理手数料が上乗せされ、さらにEKSクラスター自体の料金（標準サポートで1クラスターあたり0.10ドル/時）も別途発生します。手数料は起動されたインスタンスの種類と稼働時間で決まり、購入オプションには依存しません。課金は秒単位で、最低1分から計上されます。
Auto Modeのノードが EC2 コンソールに表示されないのはなぜですか？
2026年4月22日以降に作成されたマネージドインスタンスと付随リソース（起動テンプレート、EBSボリューム、ENI）が、EC2コンソールと describe 系のリスト操作から既定で非表示になったためです。同日より前から存在するリソースは表示されたままです。非表示でも稼働しており課金も続きます。確認にはEKSコンソールのComputeタブ、kubectl get nodes、インスタンスIDを直接指定した describe-instances、DescribeInstances の include-managed-resources パラメータを使います。可視性設定はアカウント単位で変更できます。
