copied!

EKS Auto Mode 導入前に知っておきたい7つのこと

Sreake事業部

2026.6.10

copied!

Table of Contents

自己紹介

Sreake事業部で長期インターンをさせていただいている大久保です。

本記事では2024年末に発表された Amazon EKS Auto Modeについての行った調査結果を紹介したいと思います。

” クラスター管理をワンクリックで効率化 “というキャッチコピーは魅力的ですが、導入にあたっては自動更新の仕組みやネットワークの柔軟性などを正しく理解しておく必要があります。

Streamline Kubernetes cluster management with new Amazon EKS Auto Mode

今回は、EKS Auto Modeの仕様を深掘りし、標準のEKSとの違いや運用上の注意点をまとめました。

従来のEKS運用の壁

従来のEKS運用においては、大きく分けて3つの負担がありました。

インフラの保守
- マネージド型ノードグループやセルフマネージド型ノードでは、インスタンスタイプの選定・OSのパッチ適用などはユーザーが手動で設定・管理
アドオン運用
- VPC CNI・CoreDNS・AWS Load Balancer Controller・EBS CSI Driverなど、クラスターの運用に欠かせない多くのアドオンを個別にインストール・管理・更新し続ける
責任範囲の広さ
- Nodeのセキュリティ確保や、Podの要求に合わせた最適なリソース確保の責任が重い

これにより、インフラの深い知識がないエンジニアにとっては、どこから手をつけるべきか判断が難しく、導入のハードルが非常に高い状態にありました。

また、経験豊富なエンジニアであっても、本質的な開発以外の日々の細かなアップデートやリソースの最適化といった運用は、多くの現場でもっと効率化できるはずだという強い改善意欲を抱えながら運用を続けてきたはずです。

この高いハードルと運用負荷を解消し、誰でも等しくKubernetesの恩恵を享受できるようにしたいというニーズは、非常に根強いものでした。

比較項目	標準 EKS (EC2)	EKS Fargate	EKS Auto Mode
ノード管理	ユーザー (マネージド型ノード含む)	不要 (AWS)	不要 (AWS)
アドオン管理	手動 (Helm/アドオン)	一部制限あり	自動 (フルマネージド)
DaemonSet	対応	非対応	対応
ノード起動速度	普通 (数分)	やや遅い	速い (Karpenterベース)
カスタマイズ性	高い (OS/AMI選択可)	低い	中程度 (インスタンスタイプ等は自動)
コスト構造	インスタンス料金	vCPU/メモリ課金	インスタンス料金 + 約12%手数料

EKSではこれまでも、インフラ管理を不要にする選択肢としてEKS Fargateが存在していました。しかし、FargateにはDaemonSetが使えない・起動が少し遅いといった制約がありました。

今回登場した EKS Auto Modeは、Fargateのような管理の楽さを維持しつつ、EC2ベースの柔軟性も捨てない、いいとこ取りの解決策と言えます。

EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する

EKS Auto Modeとは

EKS Auto Modeは、Kubernetesのインフラ管理を大幅に簡素化・自動化した新しい運用スタイルです。

これまでユーザーが行っていたワーカーノードのプロビジョニング・管理・スケーリングなどといった運用負荷をAWS側が引き受けることで、ユーザーがアプリケーションの開発に専念できる環境を生み出します。

EKS 自動モード

いわば、Kubernetesの運用をAWSが責任を持って定義・実行してくれるモードだと言えるでしょう。

EKS Auto Mode は何が自動になるのか

では、Auto Modeを導入することで、具体的に従来の課題はどのように変化するのでしょうか。

調査で見えてきた仕様を整理しました。

1. 自動更新：Nodeとアドオンの変化

EKS Auto Modeの最大のメリットは、これまで運用者の負担だったパッチ適用とコンポーネント管理の自動化です。

Nodeの自動更新サイクル

21日のサイクル: ノード生成から21日が経過すると更新対象
AMIの更新: AWS側でセキュリティパッチが適用された新しいイメージが出た時
クラスター更新: Kubernetes自体のバージョンアップ時

💡クラスタ更新について
クラスタの更新は標準のEKSと比べて簡単になりました。
しかし、更新の実行トリガーは依然として手動です。また、新バージョンのKubernetesで廃止されるAPIをアプリケーションが使っていないかといった互換性の検証は、従来通りユーザーの責任範囲となります。

Amazon EKS Auto Mode のノード自動更新を Deep Dive する ~ 長期実行ワークロードを正しく取り扱う

Readiness Probeの重要性について

Auto Modeの更新時は　新しいノードを立てる → 古いノードをDrainする　という手順を踏んでくれますが、Readiness Probe（疎通確認）が設定されていないと、新しいPodが準備できる前に古いPodが消され、サービス停止の原因になります。

今回は以下の設定で検証してみました。
commandでコンテナが起動して30秒間はアクセスできない状態にします。
この状態で、readinessProbeのありなしを比較します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        # 
        command: ["/bin/sh", "-c", "sleep 30; nginx -g 'daemon off;'"]
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5  # 5秒後からチェック開始
          periodSeconds: 5        # 5秒おきにチェック
          
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"
        ports:
        - containerPort: 80

readinessProbeなしの場合

$ kubectl apply -f nginx-app.yaml
deployment.apps/nginx-deployment configured

# applyした瞬間に古いPodは削除され始め、新しいPodはREADYになっているが30sまで通信できない
$ kubectl get pods
NAME                                READY   STATUS        RESTARTS   AGE
nginx-deployment-58df7544b7-5wbvz   1/1     Running       0          16s
nginx-deployment-58df7544b7-qz2l5   1/1     Running       0          7s
nginx-deployment-58df7544b7-qz2ph   1/1     Running       0          9s
nginx-deployment-7cdfccf8b6-6d7sl   1/1     Terminating   0          9m26s
nginx-deployment-7cdfccf8b6-hgf49   0/1     Error         0          8m13s
nginx-deployment-7cdfccf8b6-qkpzb   1/1     Terminating   0          8m46s

# アクセスはできず502が出ている
$ curl http://k8s-default-myalb-c2576b4980-732539010.ap-northeast-1.elb.amazonaws.com/
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

# 古いPodは消えたが、まだ通信はできない
$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-58df7544b7-5wbvz   1/1     Running   0          29s
nginx-deployment-58df7544b7-qz2l5   1/1     Running   0          20s
nginx-deployment-58df7544b7-qz2ph   1/1     Running   0          22s

readinessProbeがなしの場合では、コンテナを起動して30秒間は常に502エラーが起こりました。

readinessProbeありの場合

$ kubectl apply -f nginx-app.yaml
deployment.apps/nginx-deployment configured

# podが作成されるが30sまで通信ができないため、古いPodは消えない
$ kubectl get pods
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-6548dcc9d7-8fnbs   1/1     Running             0          77s
nginx-deployment-6548dcc9d7-gg5dc   1/1     Running             0          79s
nginx-deployment-6548dcc9d7-vzbfs   1/1     Running             0          86s
nginx-deployment-7cdfccf8b6-c5vsc   0/1     ContainerCreating   0          5s

# アクセスができる
$ curl http://k8s-default-myalb-c2576b4980-732539010.ap-northeast-1.elb.amazonaws.com/
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
.
.
.

# 30sから通信可能だが、5秒後から疎通確認するためまだ待機
$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6548dcc9d7-8fnbs   1/1     Running   0          106s
nginx-deployment-6548dcc9d7-gg5dc   1/1     Running   0          108s
nginx-deployment-6548dcc9d7-vzbfs   1/1     Running   0          115s
nginx-deployment-7cdfccf8b6-c5vsc   0/1     Running   0          34s

# 古いpodが一つ消え、新しいpodが作られる
$ kubectl get pods
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-6548dcc9d7-gg5dc   1/1     Running             0          113s
nginx-deployment-6548dcc9d7-vzbfs   1/1     Running             0          2m
nginx-deployment-7cdfccf8b6-c5vsc   1/1     Running             0          39s
nginx-deployment-7cdfccf8b6-qcjtd   0/1     ContainerCreating   0          1s

eadinessProbeがありの場合では、常に通信が可能であり、replicas: 3を守ってくれています。

今回はコンテナの停止時間を30秒間で設定していましたが、立ち上げに時間がかかったりなんらかのエラーが起きた時、サービスは止まり続けます。

標準のEKSでは、ノードの入れ替え（AMI更新など）は運用者がタイミングを制御できます。

しかし、Auto Modeでは21日周期の自動更新がデフォルトで組み込まれており、バックグラウンドでノードの入れ替えが常に行われます。

Readiness Probeを設定していない場合、この自動メンテナンスのたびに予期せぬサービスの切断が発生することになります。

運用の自動化を安全に享受するためには、Pod側でのヘルスチェック設定がこれまで以上に重要になるため、設定しておきましょう。

2. マネージド型アドオンの進化

VPC CNI・kube-proxy・CoreDNSだけでなく、Karpenter・EBS CSI・AWS Load Balancer Controllerの3つの主要コンポーネントが、Auto Modeでは初期状態からインストールされており、また、サービスの一部として管理されます。

メリット: クラスターの更新に合わせてAWSが検証済みのバージョンへ自動で引き上げます。Helmでの手動管理は不要です。
デメリット: Upgrade Insights でのステータス確認ができなくなる場合があるため、AWSのマネージドな挙動を信頼する形になります。また、カスタムが不可能となります。

⚠️注意ポイント
Auto Modeで管理されていないアドオンの更新は自己管理となります

EKS Auto Mode クラスターの Kubernetes バージョンを更新する

3. インスタンス選定の最適化（Karpenterとの統合）

Auto Modeは、内部的に Karpenter を利用してノードのプロビジョニングを行います。

ジャストサイズな選定 PodのCPU/メモリ要求を見て、最適なインスタンスタイプを自動選択する
コスト最適化 時間帯によってスポットインスタンスを活用するなど、その時々で最も安価な構成を維持する

# 最初はノードが1台、Podも1つのみ
$ kubectl get node
NAME                    STATUS   ROLES    AGE   VERSION
i-009871403763a5054     Ready    <none>   13h   v1.33.7-eks-ac2d5a0

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-97666ffd5-7dtv5    1/1     Running   0          13h

# レプリカ数を20に増やす
$ kubectl scale deployment nginx-deployment --replicas=20
deployment.apps/nginx-deployment scaled

# Podの状態を確認。多くが ContainerCreating または Pending になる
$ kubectl get pods
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-97666ffd5-2d4jq    0/1     ContainerCreating   0          21s
nginx-deployment-97666ffd5-42hfk    0/1     ContainerCreating   0          21s
nginx-deployment-97666ffd5-5wl6z    1/1     Running             0          21s
nginx-deployment-97666ffd5-7dtv5    1/1     Running             0          13h
nginx-deployment-97666ffd5-7hfvv    0/1     ContainerCreating   0          21s
.
.
.

# 数秒後、自動的に新しいノードが追加された
$ kubectl get node
NAME                    STATUS   ROLES    AGE   VERSION
i-009871403763a5054     Ready    <none>   13h   v1.33.7-eks-ac2d5a0
i-032ddbddd851a1831     Ready    <none>   14s   v1.33.7-eks-ac2d5a0

自前で実装するKarpenterと同じく、Podを増やした際Nodeも自動的に増えました。

また、Nodeの起動時間も標準のEKSと比べて早く、こちらもKarpenterと同じ挙動をしてくれています。

4. セキュリティについて

セキュリティグループ（SG）の考え方

NodeのSG
- デフォルトでは AWS 管理の SG が適用される。NodeClass でSGを指定し変更可能
Podの管理
- EKS NetworkPolicy を活用し、Pod単位で通信制御を行う

EKS 自動モードでの VPC ネットワーキングとロードバランシングの説明

Network Policy を試す

まず、Network Policy を有効化するためにVPC CNI configの更新します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

今回は以下の設定で検証してみました。

namespace: default のapp: nginx にアクセスできるのは、同じnamespace: default の Pod だけという制限をかけ、namespace: devからの通信を遮断します。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-default-only
  # このポリシーを適用するnamespace(この中のPodが制限対象になる)
  namespace: default
spec:
  podSelector:
    matchLabels:
	    # 制御の対象となるPodをラベルで指定
	    app: nginx
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
	        # 通信を許可するnamespaceを限定
          kubernetes.io/metadata.name: default
  policyTypes:
  # 受信(Ingress)通信に対してのみ制限を適用
  - Ingress

namespace: defaultとnamespace: dev 両方に同じ設定のPodをデプロイし、nginxPod(IP: 10.0.1.80)への通信がどうなるかを試します。

$ kubectl get pod --all-namespaces
NAMESPACE   NAME                                READY   STATUS    RESTARTS   AGE
default     nginx-deployment-58df7544b7-69f4q   1/1     Running   0          4h23m
default     ubuntu-default-7888d45b84-t7xq9     1/1     Running   0          4h22m
dev         ubuntu-default-7888d45b84-p557f     1/1     Running   0          4h22m

$ kubectl describe pods nginx-deployment-58df7544b7-69f4q                          
Name:             nginx-deployment-58df7544b7-69f4q
Namespace:        default
Priority:         0
Service Account:  default
Node:             i-00bf01008854abf08/10.0.1.12
Start Time:       Thu, 21 May 2026 12:32:09 +0900
Labels:           app=nginx
                  pod-template-hash=58df7544b7
Annotations:      <none>
Status:           Running
IP:               10.0.1.80

namespace: default からアクセスした場合

$ kubectl exec -n default ubuntu-default-7888d45b84-t7xq9 -- curl --max-time 5 10.0.1.80
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
  0      0   0      0   0      0      0      0                       100    896 100    896   0      0  1.05M      0                       100    896 100    896   0      0 988.7k      0                       100    896 100    896   0      0 907.6k      0                              0
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
・
・
・
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

namespace: defaultのPodからアクセスした場合、期待通り、HTMLの応答が返ってきます。

namespace: dev からアクセスした場合

$  kubectl exec -n dev ubuntu-default-7888d45b84-p557f -- curl --max-time 5 10.0.1.80
curl: (28) Connection timed out after 5002 milliseconds
command terminated with exit code 28

namespace: devのPodからアクセスした場合、正しくパケットがドロップされ、タイムアウトが発生しました。

EKS Auto Mode でネットワークポリシーを使用する

セキュリティグループでの設定ではなく、ネットワークポリシーでの運用となるため、慣れていないチームにはハードルが高いかもしれません。ですが、インフラ層を意識させず、Pod単位で設定が可能であるという利点もあります。

5. IAMと認証：Pod Identityが標準に

IAM周りは大幅に簡素化されています。

Cluster: Auto Modeを動作させるために以下のポリシーが必須
- AmazonEKSComputePolicy
- AmazonEKSBlockStoragePolicy
- AmazonEKSLoadBalancingPolicy
- AmazonEKSNetworkingPolicy
- AmazonEKSClusterPolicy

Node: 以下の最小権限のポリシーが設定されており、変更できない
- AmazonEKSWorkerNodeMinimalPolicy
- AmazonEC2ContainerRegistryPullOnly

Amazon Elastic Kubernetes Service に関する AWS マネージドポリシー

Pod: EKS Pod Identity がデフォルトで利用可能である
- 従来のような複雑なIRSA（IAM Roles for Service Accounts）の設定なしに、Podへ権限を付与できる

EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ

6. ロードバランサー（ALB/NLB）のフルマネージド化

Auto ModeにおけるLB管理は、従来と比べとても簡素化されました。

特に、NLBはService、ALBはIngressで管理できるようになりました。

また、Annotationsは引き続き使えますが、IngressClassParamsやIngressClassを使用した設定方法が主になります。

Auto Modeにより、LBのアドオン設定をtrueにすることで、ALB/NLBが自動で構築・削除されます。

NLB（L4）: Serviceリソースのspec.loadBalancerClass にeks.amazonaws.com/nlb を指定

apiVersion: v1
kind: Service
metadata:
  name: my-nlb
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
spec:
  type: LoadBalancer
  loadBalancerClass: eks.amazonaws.com/nlb
  ports:
  - port: 80
    targetPort: 8080
  selector:
	  # 任意のpodのラベル
    app: nginx

ALB（L7）: Ingressリソースのspec.ingressClassName にalb を指定

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-alb
spec:
	# 自分で作成したingressClassでも可能
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
	              # 任意のserviceの名前
                name: nginx-service
                port:
                  number: 80

Auto ModeのLB運用

デフォルトでIPモードとして動作します。
Nodeを介さずPodのIPに直接ルーティングするため、低遅延であり、Podの入れ替わりによるIP変化も、コントローラーが瞬時にターゲットグループへ反映してくれます。