EKS のクラスター構築完全手順（eksctl・コンソール・Auto Mode の使い分け）

EKS のクラスター構築は「eksctl で 20 分」が現代の最短ルート。だが本番運用するなら、VPC 設計・IAM・アドオン・IRSA・ロギングまで意識した手順をたどる必要がある。3 方式を比較しつつ、実務で詰まる論点を順に潰す。

---

1. 概要（端的に）

EKS のクラスターを立てる方法は実質 3 つに集約される。

• eksctl（CLI）— 最短かつ実務標準。CloudFormation を内部で組み立てて VPC・IAM・コントロールプレーン・ノードグループまで一気通貫で作る。
• マネジメントコンソール ＋ AWS CLI — GUI で 1 ステップずつ確認しながら進める。学習用・スクショ証跡が必要な現場向け。
• EKS Auto Mode — 2024 年末に GA、2026 年に主流化したマネージドモード。コンピューティング・ストレージ・ネットワーク（ロードバランサ含む）を AWS 側で自動運用する。

業務 IaC では Terraform（terraform-aws-modules/eks/aws）／AWS CDK も多用されるが、内部的には CloudFormation かネイティブ API を叩くだけなので、最初の理解は eksctl から入るのが速い。

---

2. 構築方式の比較（早見表）

EKS クラスター構築方式の比較

評価項目	eksctl 推奨	コンソール+CLI	EKS Auto Mode
セットアップ速度	約 15〜25 分	約 30〜60 分	約 10〜20 分
自動生成リソース	VPC・IAM・NodeGroup 一式	手動で個別作成	コンピュート・LB・ストレージ自動運用
IaC 化	ClusterConfig YAML	事後で取り直しが必要	Auto Mode 設定のみ少数
学習用途	◎	◎（内部理解に最適）	△（裏側が見えない）
本番運用	◎（標準的）	△（再現性が低い）	◎（運用負荷が最小）
コスト	コントロールプレーン $0.10/h + ノード代	同左	Auto Mode 管理料が上乗せ
カスタマイズ性	高（YAML 全て弄れる）	高	低（AWS の方針に従う）

---

3. 前提ツールの準備

EKS を CLI で扱うには 3 つのツールが要る。バージョン整合性に注意。

• AWS CLI v2 — 認証情報とリージョン設定
• kubectl — クラスター Kubernetes バージョンと**±1 マイナー以内**を維持
• eksctl — 0.215.0 以降推奨（古いと最新 K8s バージョンが選べない）

# eksctl インストール（macOS の例。公式リリースページ参照）
# github.com/eksctl-io/eksctl/releases から OS/Arch に合わせたバイナリを取得
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

# Linux なら公式の tar.gz を /tmp に展開し /usr/local/bin へ配置
# Windows なら choco install eksctl

# 確認
aws --version
kubectl version --client
eksctl version

認証情報

最小構成では aws configure で IAM ユーザーの Access Key を入れるが、現場では IAM Identity Center（旧 SSO）＋一時クレデンシャルを推奨。永続キーをローカルに置かない運用が今は標準。

---

4. eksctl による最短構築（推奨）

4-1. ワンライナーで最小クラスター

eksctl create cluster \
  --name demo-cluster \
  --region ap-northeast-1 \
  --version 1.30 \
  --nodegroup-name workers \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 2 \
  --nodes-max 4 \
  --managed

内部で CloudFormation スタックが 2 つ走る：

1. eksctl-<name>-cluster — VPC（3 AZ × public/private サブネット）・IGW・NAT GW・IAM・コントロールプレーン
2. eksctl-<name>-nodegroup-<ng> — マネージドノードグループ（Auto Scaling Group + EC2）

初回で 15〜20 分。途中で止めると VPC が中途半端に残るので、完了するまで Ctrl+C しないこと。

4-2. ClusterConfig YAML で IaC 化（実務標準）

ワンライナーは検証用。実務では YAML をリポジトリ管理する。

# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: prod-cluster
  region: ap-northeast-1
  version: "1.30"

vpc:
  cidr: 10.20.0.0/16
  nat:
    gateway: HighlyAvailable  # 3 AZ にそれぞれ NAT GW

iam:
  withOIDC: true  # IRSA 用に必須

managedNodeGroups:
  - name: app-workers
    instanceType: t3.large
    desiredCapacity: 3
    minSize: 3
    maxSize: 10
    privateNetworking: true
    volumeSize: 50
    volumeType: gp3
    labels:
      role: app
    tags:
      Project: demo
    iam:
      withAddonPolicies:
        autoScaler: true
        externalDNS: true
        certManager: true
        albIngress: true
        cloudWatch: true

cloudWatch:
  clusterLogging:
    enableTypes: ["api", "audit", "authenticator", "controllerManager", "scheduler"]

addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy
  - name: aws-ebs-csi-driver

eksctl create cluster -f cluster.yaml

4-3. ノード構成の選択：Managed / Self-managed / Fargate

ノードの選択肢は 3 つ。

EKS ノード種別の使い分け

評価項目	Managed Node Group 推奨	Self-managed Nodes	Fargate Profile
運用主体	AWS マネージド	利用者	AWS（完全サーバーレス）
AMI 更新	ボタン 1 つ	自前で運用	不要
コスト	EC2 料金そのまま	同左 + 運用工数	タスク単位課金（やや割高）
カスタム AMI	Launch Template 経由で可	完全自由	不可
Spot	対応	対応（自前）	非対応
DaemonSet	動作	動作	動作不可（重要）
Pod 起動時間	数秒	数秒	60〜90 秒

---

5. EKS Auto Mode（2026 年の主流化トレンド）

Auto Mode は コンピュート・ストレージ・ネットワーク・ロードバランサ・OS アップデートを AWS が自動運用するモード。Karpenter 相当のオートスケーラを AWS 側で組み込み、利用者は「Pod を投げるだけ」に近づく。

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

---

6. クラスター作成後の必須作業

6-1. kubectl の接続設定

aws eks update-kubeconfig --region ap-northeast-1 --name prod-cluster
kubectl get nodes
kubectl get pods -A

~/.kube/config に新しいコンテキストが追加される。複数クラスターを跨ぐなら kubectx / kubens を併用すると事故が減る。

6-2. アドオンの導入

EKS Add-ons は AWS が動作検証済のマネージド K8s アドオン。バージョン整合性を AWS 側が保証してくれるので、自前で kubectl apply するより遥かにラク。

アドオン	役割	必須度
VPC CNI	Pod ネットワーキング（ENI ベース）	必須（既定で入る）
CoreDNS	クラスター内 DNS	必須
kube-proxy	Service 通信のルーティング	必須
EBS CSI Driver	PersistentVolume 用	永続化するなら必須
EFS CSI Driver	共有 FS 用	共有が必要なら
AWS Load Balancer Controller	ALB/NLB Ingress	Web 公開なら必須
Pod Identity Agent	IRSA の後継認証経路	新規は推奨

6-3. IRSA / Pod Identity の設定

Pod から S3 や DynamoDB を叩く場合、Pod 単位で IAM ロールを割り当てる。

eksctl create iamserviceaccount \
  --cluster prod-cluster \
  --namespace default \
  --name app-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve

これでネームスペース default の ServiceAccount app-sa を使う Pod に S3 ReadOnly 権限が伝播する。EC2 インスタンスプロファイルに乗せて「全ノード全 Pod が同じ権限」という旧構成は最小権限違反なので避ける。

---

7. クラスター削除（後片付け）

検証クラスターを残すと、コントロールプレーン代（$0.10/h ≒ 月 ¥10,500）＋ ノード EC2 ＋ NAT GW 代で**月 2 万円〜**が垂れ流される。検証後の削除を忘れない。

eksctl delete cluster --name prod-cluster --region ap-northeast-1

eksctl が自動で立てた CloudFormation スタックは消えるが、手動で作った LB・PVC・ENI が残ると VPC 削除に失敗するパターンが頻発する。削除前に：

1. kubectl delete svc --all で LoadBalancer 型 Service を削除（ALB/NLB が消える）
2. kubectl delete pvc --all で PVC を削除（EBS が消える）
3. kubectl delete ingress --all（ALB Ingress が消える）
4. その後に eksctl delete cluster

---

8. よくある詰まりポイント

• unable to get nodes で kubectl がタイムアウト — aws eks update-kubeconfig を実行していない、または IAM 認証で aws-auth ConfigMap が壊れた。eksctl get iamidentitymapping で確認。
• NAT GW 代が想定外に膨らむ — nat.gateway: HighlyAvailable で 3 AZ 全てに NAT GW を立てると、ベース料金だけで月 100 USD 超。検証は Single で十分。
• InsufficientFreeAddressesInSubnet — VPC CNI が Pod 1 個に ENI 1 個（小さい IP 1 個）を消費するため、/24 サブネットだとすぐ枯渇する。本番は /22 以上、可能なら IPv6 デュアルスタックまたは Prefix Delegation を有効化。
• coredns Pod が Pending のまま — ノードが Fargate のみ構成で、CoreDNS が Fargate にスケジュールされる設定になっていない。fargateProfiles に kube-system を含める。
• クラスター作成者だけが kubectl 出来る — 初期は作成 IAM プリンシパルしか system:masters を持たない。チームで触るなら早めに aws-auth ConfigMap か アクセスエントリ（Access Entries） に追加。

---

9. ベストプラクティス

• クラスターは IaC で再現可能にする — cluster.yaml をリポジトリ管理し、レビュー対象にする。コンソールクリックでの構築は禁止運用が現代の標準。
• VPC は専用に切る — 既存 VPC への相乗りは IP レンジ枯渇・タグ衝突のリスクが高い。EKS は専用 VPC を新規で切る。
• コントロールプレーン ログを全種類有効化 — api / audit / authenticator / controllerManager / scheduler の 5 種を CloudWatch Logs に流す。トラブル時に「ログが無い」が一番痛い。
• OIDC / Pod Identity を最初から ON — 後付けは面倒。
• マネージドアドオンを使う — kubectl apply -f で野良 manifest を当てない。AWS の整合性保証から外れる。
• ノードグループは複数に分ける — app / system / batch で別グループにしておくと taint/toleration によるワークロード分離が楽。
• クラスター名にプロジェクト＋環境を含める — myapp-prod / myapp-stg。複数アカウント運用で誤接続を防ぐ。
• アップグレード戦略を最初に決める — K8s は約 1 年で EOL。Blue/Green クラスター切替 or インプレース、どちらで運用するかを構築時点で合意しておく。

---

10. 関連用語

• EKS — マネージド Kubernetes 本体
• ECS — もう一つのコンテナオーケストレータ
• Fargate — サーバーレスのコンテナ実行基盤
• ECR — コンテナイメージレジストリ
• VPC — EKS のネットワーク基盤
• サブネット — Pod/Node が配置されるネットワーク
• IAM Role — IRSA / Pod Identity で利用
• ALB — Ingress でよく使われる L7 LB
• CloudFormation — eksctl の裏側
• CDK — IaC で EKS を組む別解

---

11. 関連サイト

AWS 公式

• Create an Amazon EKS cluster（公式ユーザーガイド）
• Get started with Amazon EKS – eksctl
• Get started with Amazon EKS – AWS Management Console and AWS CLI
• Set up to use Amazon EKS

参考記事

• DEV Community：Amazon EKS Clusters Setup – Step by Step Instructions
• DevOpsCube：How to Create AWS EKS Cluster Using eksctl
• Medium（Dr. Ernesto Lee, 2026-04）：EKS Auto Mode と eksctl で 20 分構築

---

---

🎓 試験での出題傾向

試験	重要度	主な出題パターン
CLF	中	EKS と ECS の違い、マネージド範囲（コントロールプレーン責任分界）
SAA	高	VPC 設計（サブネット数・NAT GW 配置）、ノードグループ種別、IRSA
DVA	中	Pod から AWS API を叩く設計（IRSA / Pod Identity）、ECR 連携
SOA	中	クラスターロギング、アドオン管理、アップグレード戦略

特に SAA では「Pod に最小権限の IAM をどう渡すか」を問う出題が定番（答え＝IRSA / Pod Identity）。EC2 インスタンスプロファイル経由は誤答として狙われる。CLF レベルでは「EKS は Kubernetes、ECS は AWS 独自」の責任分界点を押さえれば十分。

---