2026年6月27日

AWS EKSでKubernetesを起動する方法｜EKS Auto Modeで最初のアプリを公開し、片付けるまで

VPS・クラウド

Amazon EKSでKubernetesを手早く起動するなら、ノードの用意やストレージ・ロードバランサーの部品をAWS側に任せる「EKS Auto Mode」でクラスターを作るのが近道です。eksctl のコマンド1つでクラスターができ、アプリをデプロイすると必要な分だけノードが自動で起動します。この記事では、Auto Modeでクラスターを起動し、サンプルのWebアプリを外部に公開して動作を確かめ、使い終わったら費用が残らないように片付けるまでを、つまずきやすい点と確認方法を添えて説明します。

ノードグループを自分で設計して構築する手順は別の記事で扱っているので、ここでは「まず動かして全体像をつかむ」ことに絞ります。EKSは機能追加や既定値の変更が多いサービスです。ここでの説明は執筆時点（2026年10月現在）の情報をもとにしていますが、コマンドのオプションやマニフェストの書き方は公式ドキュメントでも確認してください。

EKS Auto Modeとは何か

EKSのクラスターは、Kubernetesの管理部分（コントロールプレーン）をAWSが動かし、アプリのコンテナが動く「ノード」を利用者が用意する、という分担が基本でした。ノードのEC2を何台・どの種類で用意するか、ネットワークやストレージ用の部品（アドオン）をどう入れて更新するかを、利用者が決めて管理する必要があります。

Auto Modeでは、この部分の多くをAWSが引き受けます。

Podを動かすのに必要なノードを自動で起動し、不要になれば減らす
ノードのOSの更新や入れ替えをAWS側で行う
EBSボリュームの割り当て、ロードバランサーの作成、Podのネットワークといった部品が組み込まれている

その代わり、ノードの細かな設定の自由度は下がり、通常の料金に加えてAuto Mode分の料金がかかります。具体的な料金はAWSの料金ページで確認してください。仕組みを細かく制御したい場合は、マネージドノードグループを使う従来の構成が向いています。

用意するもの

手元のPCに次のツールを入れておきます。

AWS CLI：認証情報を設定済みで、aws sts get-caller-identity で自分のアカウントとユーザー（ロール）が表示されること
eksctl：Auto Modeに対応した版。古い版ではオプションが認識されないので、作業前に更新しておきます
kubectl：クラスターのKubernetesの版との差が1マイナーバージョン以内のもの

作業するIAMの主体には、EKS・EC2・VPC・IAM・CloudFormationを操作できる権限が必要です。eksctl は内部でCloudFormationのスタックを作り、クラスター用とノード用のIAMロールも作成します。権限が足りないと途中で止まり、スタックが中途半端に残ることがあります。

ステップ1：Auto Modeでクラスターを起動する

eksctl version
eksctl create cluster \
  --name demo-auto \
  --region ap-northeast-1 \
  --enable-auto-mode

VPCを指定しなければ、eksctl がパブリックとプライベートのサブネットを含むVPCを新しく作ります。完了までには十数分ほどかかります。途中で失敗した場合は、CloudFormationのコンソールで eksctl-demo-auto-... という名前のスタックのイベントを開くと、どのリソースで止まったかが分かります。多い原因は、IAMの権限不足と、VPCやElastic IPの数の上限（サービスクォータ）です。

完了すると、eksctl が kubeconfig（kubectlの接続先の設定）を書き込みます。別のPCから接続するときは次のコマンドで追加します。

aws eks update-kubeconfig --region ap-northeast-1 --name demo-auto
kubectl get nodes
kubectl get pods -A

ここで kubectl get nodes が何も返さなくても異常ではありません。Auto Modeは、動かすPodが無ければノードを起動しないからです。従来の構成に慣れていると「ノードが起動していない」と戸惑う点なので覚えておきます。接続そのものに失敗する（認証エラーになる）場合は、aws sts get-caller-identity で、クラスターを作ったのと同じIAMの主体で操作しているかを確認してください。

ステップ2：サンプルアプリをデプロイする

動作確認用に、nginxを2つ動かすDeploymentを作ります。

# app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: web
          image: public.ecr.aws/docker/library/nginx:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 250m
              memory: 256Mi

kubectl apply -f app.yaml
kubectl get pods -w

適用すると、Podはいったん Pending になり、Auto Modeがノードを起動するとスケジュールされて Running に変わります。ノードの起動を待つため、最初の1回は1〜数分かかります。kubectl get nodes を見ると、ノードが追加されているのが分かります。

resources.requests を書いているのは、Auto Modeがこの値をもとに必要なノードの大きさを決めるからです。書かないと、実際の使用量に対してノードの見積もりがずれやすくなります。

Pending のまま進まないときは、kubectl describe pod <Pod名> の末尾の Events を見ます。要求したCPUやメモリが大きすぎる、イメージの名前を間違えて取得に失敗している（ImagePullBackOff）、といった原因がここに表示されます。

ステップ3：ロードバランサーで外部に公開する

Auto Modeには、Serviceからネットワークロードバランサー（NLB）を作る機能が組み込まれています。

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: hello
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  type: LoadBalancer
  loadBalancerClass: eks.amazonaws.com/nlb
  selector:
    app: hello
  ports:
    - port: 80
      targetPort: 80

kubectl apply -f service.yaml
kubectl get svc hello

EXTERNAL-IP の欄にロードバランサーのDNS名が表示されたら、数分待ってからブラウザか curl http://<DNS名>/ でアクセスし、nginxのページが返ることを確認します。

loadBalancerClass は、どのコントローラーにロードバランサーを作らせるかの指定です。Auto Modeの組み込み機能を使う場合はこの値を指定します。別途 AWS Load Balancer Controller を入れている環境では、どちらが処理するかが変わるので、指定の意味を確認してから使ってください。DNS名がいつまでも表示されない場合は、kubectl describe svc hello のイベントを見ます。既存のVPCを使っている場合は、パブリックサブネットに kubernetes.io/role/elb のタグが付いていないと、ロードバランサーを置く場所が見つからずに失敗します。

HTTPSでドメインを付けて公開する場合は、Ingressを使ってALB（アプリケーションロードバランサー）を作り、証明書をACMで管理する構成が一般的です。Auto ModeでIngressを使うには IngressClass などの追加の設定が必要なので、公式ドキュメントの手順に従ってください。

ステップ4：データを保存するアプリの場合

データベースのように再起動してもデータを残したいアプリでは、EBSボリュームを使います。Auto Modeでは組み込みのEBSドライバーを使うStorageClassを作り、PersistentVolumeClaimから使います。

# storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: auto-ebs-sc
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
  encrypted: "true"

volumeBindingMode: WaitForFirstConsumer は、Podの置き場所が決まってから同じアベイラビリティーゾーンにボリュームを作るための指定です。EBSはゾーンをまたいで使えないため、この指定が無いとPodとボリュームのゾーンが食い違って起動できないことがあります。

WordPressを載せる場合は、データベースはクラスターの外のAmazon RDSに置くほうが、バックアップや障害時の切り替えをAWSに任せられて運用が軽くなります。複数のPodでアップロードファイルを共有するには、EBSではなくEFSかS3を使う構成が必要です。1台で足りるWordPressなら、EKSよりEC2やLightsailのほうが手間も費用も少なく済みます。

Auto Modeで気をつけること

ノードは定期的に入れ替わる：OSの更新などのため、ノードは一定期間で作り直されます。Podが1つだけだと入れ替えのたびに止まるので、replicas を2以上にし、必要に応じて PodDisruptionBudget で同時に止まる数を制限します。
停止ボタンは無い：EKSのコントロールプレーンは一時停止できず、クラスターがある限り料金がかかります。検証用のクラスターは、使わない間は削除しておくのが無難です。
権限の締め出しに注意：クラスターを作ったIAMの主体には管理者権限が付きます。そのユーザーを削除すると誰も操作できなくなるおそれがあるため、チームで使う場合はアクセスエントリーで別の管理者も登録しておきます。

ステップ5：片付ける

削除の順番が大事です。LoadBalancerのServiceが作ったNLBは、Kubernetes側のコントローラーが管理しています。クラスターだけを先に消すと、NLBがAWS上に残って料金がかかり続けることがあります。

kubectl delete -f service.yaml
kubectl delete -f app.yaml
kubectl get svc -A   # LoadBalancer が残っていないか確認
eksctl delete cluster --name demo-auto --region ap-northeast-1

PersistentVolumeClaimを使った場合は、StorageClassの回収ポリシーによってはEBSボリュームがクラスター削除後も残ります。必要なデータは削除前にスナップショットなどで退避し、削除後にEC2コンソールのロードバランサーとボリューム、CloudFormationのスタックが残っていないかを確認してください。

まとめ

EKS Auto Modeなら、eksctl create cluster --enable-auto-mode でノードや主要な部品の管理をAWSに任せた状態でクラスターを起動できる。
直後に kubectl get nodes が空でも正常。Podをデプロイすると必要なノードが起動する。
Podの resources.requests を書き、外部公開はServiceの loadBalancerClass でNLBを作る。止まったときは kubectl describe のイベントを見る。
ノードは定期的に入れ替わるので、Podは2つ以上にしておく。
片付けはServiceを先に消してからクラスターを削除し、残ったロードバランサーやボリュームを確認する。