Amazon EKS 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon EKS（Elastic Kubernetes Service） は、AWS が提供するフルマネージド Kubernetes コントロールプレーンサービスです。Kubernetes 標準エコシステム（Helm・Prometheus・Istio 等）を完全活用でき、マルチ AZ・自動フェイルオーバー・自動パッチ管理を提供します。本ドキュメントは、EKS の概念・アーキテクチャ・運用・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： EKS とは何か、Kubernetes との関係、AWS コンテナオプションの選択肢を学びたい方
• 開発者向け： アプリを EKS にデプロイし、CI/CD を構築したい方
• SRE / インフラ向け： クラスタ運用、スケーリング、セキュリティ、監視を深掘りしたい方
• 意思決定者向け： EKS vs ECS vs Fargate、投資判断・コスト・ポータビリティの比較

2026 年の EKS エコシステム

• EKS Auto Mode GA：コントロールプレーン・ノード自動管理（v1.28+）
• EKS Pod Identity GA：IRSA の簡素化・次世代認証
• Karpenter v1 安定版：ノード自動スケーリング（スポット 90% コスト削減）
• AI/ML ワークロード加速：GPU オーケストレーション、Inferentia2 対応
• Hybrid Nodes：AWS Outposts での EKS ノード運用
• Generative AI ワークロード標準化：Ray on EKS、Hugging Face Model Hub 統合
• GitOps 標準化：Argo CD / Flux との AWS 公式統合強化

目次

1. 概要
2. EKS が解決する課題
3. 主な特徴
4. アーキテクチャ
5. ノードタイプ・管理戦略
6. EKS Auto Mode（自動管理）
7. Karpenter（次世代オートスケーラ）
8. 主要ユースケース
9. ネットワーキング
10. ストレージ
11. サービスメッシュ
12. EKS Pod Identity と IRSA
13. ロギング・モニタリング・可視化
14. セキュリティ
15. EKS アドオン
16. デプロイメント戦略
17. ECS vs EKS vs Fargate
18. EKS Anywhere と EKS on Outposts
19. 他の類似ツールとの比較
20. クライアントとエコシステム
21. ベストプラクティス
22. トラブルシューティング
23. 2025-2026 最新動向
24. 学習リソース
25. 実装例・活用シーン
26. 導入ロードマップ
27. 実装チェックリスト
28. まとめ
29. 参考文献

概要

初心者向けメモ： EKS は「AWS が Kubernetes のコントロールプレーン（etcd・kube-apiserver・スケジューラ等）を管理するサービス」です。ノード（ワーカーマシン）は自分で管理するか、AWS の自動管理に任せるかを選べます。Kubernetes 標準エコシステムをそのまま使える点が ECS との大きな違いです。

定義

Amazon EKS は、AWS が提供する フルマネージド Kubernetes コントロールプレーンサービス です。以下を AWS が管理します。

• etcd：クラスタ状態（Key-Value Store）
• kube-apiserver：Kubernetes API（複数 AZ で冗長化）
• kube-scheduler：Pod のノード配置決定
• kube-controller-manager：Deployment・ReplicaSet・Service 等の制御

ユーザー（開発者・運用者）は以下を管理します。

• ワーカーノード（EC2・Fargate・EKS Auto Mode から選択）
• Pod・Deployment・Service 等のマニフェスト
• アドオン（CNI・ロギング・モニタリング等）

EKS の位置づけ

【図1】AWS コンテナサービスの位置づけ：

graph TD
    App[アプリケーション]
    
    subgraph Container Options
        ECS["<b>ECS</b><br/>AWS 独自<br/>シンプル・AWS最適化"]
        EKS["<b>EKS</b><br/>マネージド K8s<br/>標準・ポータブル"]
        Fargate["<b>Fargate</b><br/>サーバーレスコンテナ<br/>任意のプラットフォーム"]
    end
    
    App --> ECS
    App --> EKS
    App --> Fargate
    
    ECS --> EC2["EC2 インスタンス"]
    EKS --> EC2
    EKS --> FargateNode["Fargate"]
    EKS --> AutoMode["EKS Auto Mode"]

EKS が解決する課題

Kubernetes を自分で管理する場合の課題

EKS を選ぶべき理由

✅ Kubernetes 標準エコシステムを活用したい

• Helm・Prometheus・Istio・Argo CD・Karpenter 等の CNCF プロジェクトがそのまま使える
• ECS では代替実装か AWS 純正ツール（CloudFormation 等）が必要

✅ マルチクラウド・オンプレミス統合

• EKS Anywhere でオンプレミス Kubernetes
• EKS on Outposts で AWS Outposts 上の Kubernetes
• 同じマニフェスト・同じ運用パターンで GCP・Azure・オンプレと統合

✅ 高度なスケーリング・コスト最適化

• Karpenter で自動ノード選択・スポットインスタンス 90% コスト削減
• HPA（Horizontal Pod Autoscaler）・VPA で Pod・ノード自動スケール

✅ Pod 単位のセキュリティ・権限管理

• EKS Pod Identity で Pod に IAM ロール付与
• RBAC で Kubernetes ネイティブな権限制御

✅ 複雑なマイクロサービス・ML ワークロード

• サービスメッシュ（Istio・Linkerd）で mTLS・カナリアリリース
• Kubeflow・KServe で AI/ML パイプライン

主な特徴

アーキテクチャ

全体構成

【図2】EKS クラスタアーキテクチャ：

graph TB
    subgraph AWS Managed["AWS 管理（マネージドコントロールプレーン）"]
        AP["kube-apiserver"]
        Sched["kube-scheduler"]
        CM["kube-controller-manager"]
        ETCD["etcd（暗号化）"]
        CAM["cloud-controller-manager"]
    end
    
    subgraph VPC["AWS VPC（ユーザー管理）"]
        subgraph PublicNet["Public Subnet"]
            NAT["NAT Gateway"]
        end
        
        subgraph PrivateNet["Private Subnet"]
            subgraph NG["マネージドノードグループ"]
                Node1["EC2 Node 1<br/>kubelet"]
                Node2["EC2 Node 2<br/>kubelet"]
            end
            
            subgraph SM["セルフマネージドノード"]
                Node3["EC2 Node 3<br/>kubelet"]
            end
            
            subgraph FGW["Fargate"]
                Pod1["Fargate Pod"]
            end
            
            CNI["Amazon VPC CNI<br/>Pod ネットワーク"]
        end
    end
    
    subgraph AddOns["EKS アドオン"]
        VPCCNI["VPC CNI"]
        CoreDNS["CoreDNS"]
        KubeProxy["kube-proxy"]
        EBS["EBS CSI Driver"]
    end
    
    AP --> Node1
    AP --> Node2
    AP --> Node3
    Sched --> Node1
    CM --> Node1
    ETCD --> AP
    CAM --> AWS Managed
    
    Node1 --> CNI
    Node2 --> CNI
    Node3 --> CNI
    FGW --> CNI
    
    AddOns --> VPC

コンポーネント詳細

Control Plane（AWS 管理）:

• kube-apiserver：Kubernetes API 公開・認証・認可
• etcd：クラスタ状態保存・暗号化・定期バックアップ
• kube-scheduler：Pod をノードに割り当て
• kube-controller-manager：Deployment・ReplicaSet・Service 等を制御
• cloud-controller-manager：AWS 連携（LB・Route53・Node 管理）

Data Plane（ユーザー選択）:

• EC2 マネージドノードグループ：AWS が AMI・パッチ・ローリングアップデート管理
• セルフマネージドノード：完全カスタマイズ・AMI 自作可能
• AWS Fargate：サーバーレス・Pod 単位で自動スケール
• EKS Auto Mode：完全自動（Karpenter ベース）

ノードタイプ・管理戦略

1. マネージドノードグループ（推奨）

AWS が以下を自動管理：

• ノード AMI の最新化
• セキュリティパッチの自動適用
• ローリングアップデート

設定例：

# eksctl で作成
cat > cluster.yaml << 'EOF'
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

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

availabilityZones: ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]

managedNodeGroups:
  - name: general
    instanceType: m6i.large
    minSize: 2
    maxSize: 20
    desiredCapacity: 3
    privateNetworking: true
    iam:
      attachPolicyARNs:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
    tags:
      Environment: production
      Team: platform

  - name: gpu-workloads
    instanceType: g4dn.xlarge
    minSize: 0
    maxSize: 5
    desiredCapacity: 0
    taints:
      - key: nvidia.com/gpu
        value: "true"
        effect: NoSchedule
    labels:
      workload: gpu

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

eksctl create cluster -f cluster.yaml

メリット：

• ✅ AWS が大部分を管理
• ✅ セキュリティパッチ自動
• ✅ 最小限の運用負荷

デメリット：

• ❌ カスタマイズ限定的

2. セルフマネージドノード

ユーザーが EC2 Auto Scaling Group を完全管理。

メリット：

• ✅ 完全なカスタマイズ可能（AMI・プリインストール等）
• ✅ 既存インフラ統合

デメリット：

• ❌ パッチ管理・ローリングアップデートを自分で実装
• ❌ 運用負荷高い

3. AWS Fargate（サーバーレス）

Pod 単位で AWS が完全管理。

特徴：

• Pod ごとに隔離された実行環境
• ノード管理不要
• Pod 起動時間：30-60 秒（EC2 より遅い）

メリット：

• ✅ ノード管理ゼロ
• ✅ リソースの完全隔離

デメリット：

• ❌ 起動遅い（定常的なワークロードに不向き）
• ❌ コスト高い
• ❌ Pod の長期動作に非効率

使用例：

# バッチジョブ・CI/CD ワーカーに向く
apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  template:
    metadata:
      labels:
        runOnFargate: "true"
    spec:
      containers:
      - name: processor
        image: myapp:latest
        resources:
          requests:
            memory: "512Mi"
            cpu: "256m"
      restartPolicy: Never

Fargate Profile 設定：

eksctl create fargateprofile \
  --cluster my-cluster \
  --name batch-profile \
  --namespace batch \
  --labels runOnFargate=true

4. EKS Auto Mode（完全自動管理）

重要：v1.28+ での最新機能。コントロールプレーン・ノード・CNI・ストレージを AWS が完全自動管理。

特徴：

• Karpenter ベースの自動ノード選択
• Pod の要求に応じた自動スケール
• VPC CNI・EBS CSI 自動設定
• ECS に近いシンプルさで Kubernetes 使用可能

メリット：

• ✅ ノード管理ゼロ（ECS レベルのシンプルさ）
• ✅ Pod 要求に自動でノード選択・起動
• ✅ スポットインスタンス自動活用
• ✅ 最新機能を自動で取得

デメリット：

• ❌ カスタマイズ限定的
• ❌ 新しい機能（安定性検証必要）

設定例：

aws eks create-cluster \
  --name auto-cluster \
  --kubernetes-version 1.30 \
  --compute-config enabled=true,nodeRoleArn=arn:aws:iam::ACCOUNT:role/eks-node-role \
  --kubernetes-network-config ipFamily=ipv4 \
  --region ap-northeast-1

# クラスタの自動起動確認
aws eks describe-cluster --name auto-cluster --query 'cluster.computeConfig'

5. Karpenter（次世代オートスケーラ）

v1 GA：次世代ノード自動管理ツール。従来 Cluster Autoscaler の欠点を解決。

従来型 Cluster Autoscaler の問題

Karpenter インストール

# Helm で Karpenter インストール
helm repo add karpenter https://charts.karpenter.sh
helm repo update

helm install karpenter karpenter/karpenter \
  --namespace karpenter \
  --create-namespace \
  --set settings.clusterName=my-cluster \
  --set settings.aws.defaultInstanceProfile=KarpenterNodeInstanceProfile \
  --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=arn:aws:iam::ACCOUNT:role/KarpenterControllerRole

NodePool 設定

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  # スケジューリング要件
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]  # スポットを優先
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["t3.medium", "t3.large", "t3a.medium", "t3a.large", "m5.large", "m5a.large"]
        - key: kubernetes.io/label/karpenter.sh/do-not-consolidate
          operator: DoesNotExist
      nodeClassRef:
        name: default
  
  # リソース制限
  limits:
    cpu: "1000"
    memory: 1000Gi
  
  # ノード統合・削除ポリシー
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s
    expireAfter: 2592000s  # 30 日で再起動
    budgets:
      - nodes: "10%"  # 最大 10% の一度に削除

---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  role: "KarpenterNodeRole"
  subnetSelector:
    karpenter.sh/discovery: "true"
  securityGroupSelector:
    karpenter.sh/discovery: "true"
  tags:
    Environment: production

Karpenter のメリット

✅ スポットインスタンス活用で最大 90% コスト削減

• 例：3 ノード × 24h × 30 日
• オンデマンド：$2,000/月
• スポット（90% 削減）：$200/月

✅ Pod 要求に最適なインスタンス自動選択

• Pod に CPU 要求があると、Karpenter が自動で最適なインスタンスを検索・起動

✅ ノード統合（Consolidation）で無駄削減

• 複数ノードに分散した Pod を自動で 1 ノードに集約

EKS Auto Mode（自動管理）

v1.28+ での革新的な機能。ノードプロビジョニング・CNI・ストレージを AWS が自動管理。

EKS Auto Mode vs 従来型 EKS の比較

Auto Mode 設定例

# 1. クラスタ作成時に有効化
aws eks create-cluster \
  --name auto-cluster \
  --kubernetes-version 1.30 \
  --compute-config enabled=true \
  --kubernetes-network-config ipFamily=ipv4 \
  --role-arn arn:aws:iam::ACCOUNT:role/eks-service-role \
  --region ap-northeast-1

# 2. kubeconfig 更新
aws eks update-kubeconfig \
  --name auto-cluster \
  --region ap-northeast-1

# 3. Pod デプロイ（ノード管理は自動）
kubectl apply -f deployment.yaml
# → AWS が自動でノード起動・配置

Auto Mode でのメリット

✅ 完全な自動管理

• マネージドノード・Karpenter・EBS CSI すべて AWS が管理

✅ ECS に近いシンプルさ

• 開発者は Pod デプロイに集中、ノード管理は意識不要

✅ 最新機能の自動適用

• AWS が随時最新のインスタンスタイプ・スケーリング戦略を自動適用

Auto Mode での制限

❌ ノード選択の細かいカスタマイズ不可

• 特定インスタンスタイプ指定が限定的

❌ セルフマネージドノード使用不可

• 既存 EC2 インスタンスの統合ができない

Karpenter（次世代オートスケーラ）

従来型 Cluster Autoscaler との比較

graph TD
    subgraph TraditionalCA["Cluster Autoscaler（従来）"]
        CALogic["固定順序のインスタンスタイプリスト<br/>グリーディに選択<br/>スポット・オンデマンド管理複雑"]
    end
    
    subgraph Karpenter["Karpenter（次世代）"]
        KarpLogic["Pod 要件から最適インスタンス動的選択<br/>スポット・オンデマンド自動最適化<br/>ノード統合で無駄排除"]
    end
    
    CALogic --> Cost1["コスト：中"]
    KarpLogic --> Cost2["コスト：低（最大 90% 削減）"]

Karpenter NodePool 詳細設定

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: compute
spec:
  # Pod スケジューリング要件
  template:
    metadata:
      labels:
        workload: general
    spec:
      # 要件マッチング
      requirements:
        # アーキテクチャ
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        
        # キャパシティタイプ（スポット優先）
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        
        # インスタンスファミリ（汎用・メモリ最適）
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - "t3.medium", "t3.large", "t3.xlarge"
            - "t3a.medium", "t3a.large", "t3a.xlarge"
            - "m5.large", "m5.xlarge", "m5.2xlarge"
            - "m6i.large", "m6i.xlarge"
            - "r5.large", "r5.xlarge"
        
        # ネットワークパフォーマンス
        - key: karpenter.k8s.aws/instance-network-bandwidth
          operator: Gt
          values: ["100Mi"]
        
        # 世代（新しい世代を優先）
        - key: karpenter.k8s.aws/instance-generation
          operator: Gte
          values: ["5"]
      
      # ノードクラス参照
      nodeClassRef:
        name: default
      
      # タaint 設定（特定 Pod のみ）
      taints:
        - key: workload
          value: general
          effect: NoSchedule
  
  # リソース制限
  limits:
    cpu: "1000"
    memory: 1000Gi
    resources:
      aws.amazon.com/spot: "500"
  
  # ノード破棄・統合ポリシー
  disruption:
    # 低利用ノードを統合
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s
    expireAfter: 2592000s  # 30 日でリセット
    budgets:
      - nodes: "10%"
      - duration: "5m"
        reasons:
          - "Drifted"
  
  # ウェイト管理（優先度）
  weight: 100

---
# GPU ワークロード向け NodePool
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]  # GPU はスポット不安定
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["g4dn.xlarge", "g4dn.2xlarge", "g4dn.12xlarge"]
        - key: karpenter.k8s.aws/instance-gpu-name
          operator: In
          values: ["nvidia-tesla-t4"]
        - key: karpenter.k8s.aws/instance-gpu-count
          operator: Gte
          values: ["1"]
      nodeClassRef:
        name: gpu
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
  
  limits:
    aws.amazon.com/nvidia-tesla-t4: "100"
  
  weight: 50  # 低優先度（汎用が埋まった後に使用）

---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  role: "KarpenterNodeRole"
  subnetSelector:
    karpenter.sh/discovery: "true"
  securityGroupSelector:
    karpenter.sh/discovery: "true"
  userData: |
    #!/bin/bash
    echo "Node initialization"
  tags:
    Environment: production
    ManagedBy: karpenter

---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: gpu
spec:
  amiFamily: AL2_NVIDIA
  role: "KarpenterNodeRole"
  subnetSelector:
    karpenter.sh/discovery: "true"
  securityGroupSelector:
    karpenter.sh/discovery: "true"
  tags:
    Environment: production
    Workload: gpu

Karpenter Pod リクエスト例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-inference
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ml-inference
  template:
    metadata:
      labels:
        app: ml-inference
    spec:
      # GPU NodePool を指定
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              preference:
                matchExpressions:
                  - key: node.kubernetes.io/instance-type
                    operator: In
                    values: ["g4dn.xlarge"]
      
      # GPU ノードへのスケジュール
      tolerations:
        - key: nvidia.com/gpu
          operator: Equal
          value: "true"
          effect: NoSchedule
      
      containers:
      - name: inference
        image: ml-model:latest
        resources:
          requests:
            nvidia.com/gpu: 1
            memory: "8Gi"
            cpu: "2"
          limits:
            nvidia.com/gpu: 1
            memory: "8Gi"

主要ユースケース

初心者向けメモ： EKS は「何にでも使える」のではなく、「複数チーム・大規模・長期運用・複雑な要件」という条件が揃うと強烈に効きます。ここでは実務で頻出する 10+ のユースケースを整理します。

1. マイクロサービスアーキテクチャ

数十〜数千のサービスを独立デプロイ・スケール・運用。

典型構成：

• API Gateway → ALB Ingress → Service Mesh (Istio) → Deployment × N
• ↓
• RDS / Redis / DynamoDB

EKS を選ぶ理由：

• ✅ Namespace での完全なサービス分離
• ✅ Istio で mTLS・カナリア・リトライを自動化
• ✅ Karpenter でコスト最適化
• ✅ GitOps（Argo CD）で完全なバージョン管理

実装例： Shopify、Uber、Netflix、メルカリ

2. AI/ML 学習・推論基盤

大規模分散学習・リアルタイム推論・パイプライン実行。

典型構成：

データソース (S3 / DynamoDB) 
    → Kubeflow / Argo Workflows
    → 学習：PyTorch / TensorFlow（GPU 複数ノード）
    → モデルレジストリ
    → 推論：KServe / TensorFlow Serving
    → A/B テスト・カナリア

EKS を選ぶ理由：

• ✅ GPU ノード（g4dn・p3・p4）の自動管理
• ✅ Kubeflow で ML パイプライン標準化
• ✅ Karpenter で GPU ノードの効率活用
• ✅ Ray on Kubernetes で分散計算

実装例： OpenAI、Hugging Face、トヨタ、NTT

3. バッチ処理・大規模データパイプライン

日次集計・ETL・機械学習パイプライン・シミュレーション。

メトリクス：

# 毎日 10TB データを処理
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-etl
spec:
  schedule: "0 3 * * *"  # 毎日 3:00 AM
  jobTemplate:
    spec:
      parallelism: 50  # 50 Pod 並列実行
      completions: 50
      backoffLimit: 3
      template:
        spec:
          containers:
          - name: processor
            image: etl-processor:latest
            resources:
              requests:
                cpu: "4"
                memory: "16Gi"
          restartPolicy: OnFailure

EKS を選ぶ理由：

• ✅ Karpenter が自動でワーカーノード起動
• ✅ Argo Workflows で複雑な DAG 実行
• ✅ Volcano で batch スケジューラ最適化

4. SaaS・マルチテナント運用

複数顧客のワークロードを 1 クラスタで隔離。

隔離戦略：

Namespace ベース（軽量）
    → tenant-acme
    → tenant-globex
    → tenant-initech

vcluster（仮想クラスタ）
    → 各顧客が完全な Kubernetes 環境を持つ

クラスタ分割（最強隔離）
    → 顧客ごとに独立クラスタ

実装例： Supabase、Render、Vercel

5. CI/CD パイプライン・ビルド基盤

Jenkins / GitLab CI / GitHub Actions のワーカー。

構成：

# Tekton Pipeline で ビルド・テスト・デプロイ自動化
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-pipeline
spec:
  tasks:
    - name: build
      taskRef:
        name: kaniko
      workspaces:
        - name: source
    - name: test
      taskRef:
        name: run-tests
    - name: deploy
      taskRef:
        name: deploy-to-eks

6. ストリーム処理・リアルタイムデータ

Kafka / Kinesis からのリアルタイムデータ処理。

例：

• Flink / Spark Streaming で実時間集計
• WebSocket で低遅延ライブアップデート
• MQTT→ Kafka→ Kubernetes での IoT データ処理

7. ハイブリッド・マルチクラウド統合

オンプレ・AWS・GCP・Azure での統一 Kubernetes 基盤。

ツール：

• EKS Anywhere：オンプレミス上の EKS
• EKS on Outposts：AWS Outposts 上の EKS
• Rancher：複数クラスタ管理
• Karmada：マルチクラスタ制御プレーン

8. IoT・エッジコンピューティング

数百〜数千のエッジ拠点での軽量 Kubernetes。

ツール：

• k3s（Rancher）：超軽量、ARM 対応
• k0s：最小限の Kubernetes
• KubeEdge：Edge 特化

9. 監視・ログ・トレーシング基盤

Prometheus・Loki・Tempo の大規模運用。

構成：

• アプリメトリクス → Prometheus → Grafana
• アプリログ → Loki → Grafana
• 分散トレース → Tempo → Grafana
• プロファイル → Pyroscope → Grafana

10. Platform Engineering（内部開発者プラットフォーム）

開発者が Kubernetes を意識しない抽象化プラットフォーム。

ツール：

• Backstage（Spotify）：Developer Portal
• Port：Service Catalog
• Humanitec：デプロイ自動化

11. 動画配信・ストリーミング

大規模 VOD・ライブストリーミング基盤。

特徴：

• HPA で動的スケール
• 地理的分散（複数 AZ）
• CDN 連携（CloudFront）

12. 金融・企業システムの現代化

レガシーアプリケーションの段階的 Kubernetes 移行。

戦略：

• Strangler Fig パターンで段階的移行
• 既存 DB（RDS）との統合
• 監査・コンプライアンス・ログ管理

ネットワーキング

Amazon VPC CNI

Pod に VPC IP を直接割当（AWS 特化）。

# CNI アドオン自動設定
apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  env:
    WARM_IP_TARGET: "5"  # 事前割当 IP 数
    MINIMUM_IP_TARGET: "10"
    WARMIP_POOL_SIZE: "5"

メリット：

• ✅ AWS VPC と完全統合
• ✅ EC2 セキュリティグループ直接使用（Pod レベル）
• ✅ AWS Load Balancer との統合

Calico・Cilium

クラウド非依存のネットワークポリシー・セキュリティ。

# Calico NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            app: allowed-client

AWS Load Balancer Controller

Ingress から ALB・NLB を自動プロビジョニング。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/group.name: production-alb
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Security Groups for Pods

Pod に直接セキュリティグループを付与（きめ細かいネットワーク制御）。

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  annotations:
    vpc.amazonaws.com/eni-sg: sg-0123456789abcdef0
spec:
  containers:
  - name: app
    image: myapp:latest

ストレージ

EBS CSI Driver

Kubernetes PersistentVolume として EBS を使用。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-volume
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: ebs

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: db-app
spec:
  template:
    spec:
      containers:
      - name: db
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: ebs-volume

EFS CSI Driver

複数 Pod / ノードから共有可能なストレージ。

# EFS マウント
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 1000Gi
  accessModes:
    - ReadWriteMany
  driver: efs.csi.aws.com
  volumeHandle: fs-0123456789abcdef0

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  volumeName: efs-pv

FSx CSI Driver

高性能ファイルシステム（Windows / Lustre）。

サービスメッシュ

Istio

マイクロサービス通信の高度な制御・観測。

# インストール
istioctl install --set profile=production -y

# サイドカーインジェクション自動化
kubectl label namespace production istio-injection=enabled

機能：

• ✅ mTLS 自動化
• ✅ カナリアリリース
• ✅ サーキットブレーカ
• ✅ 分散トレーシング統合

# カナリアリリース（10% トラフィック新版に）
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-service
spec:
  hosts:
  - api.example.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: api-service
        subset: v1
      weight: 90
    - destination:
        host: api-service
        subset: v2
      weight: 10

Linkerd

軽量で実用的なサービスメッシュ（Istio より簡単）。

EKS Pod Identity と IRSA

EKS Pod Identity（新世代：推奨）

Pod に IAM ロール を直接付与（IRSA の簡素化版）。

# Pod Identity 関連付け
eksctl create podidentity \
  --cluster my-cluster \
  --namespace production \
  --service-account my-app \
  --role-name MyAppRole \
  --role-policy-arns arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess

メリット：

• ✅ OIDC プロバイダーセットアップ不要
• ✅ シンプルな設定
• ✅ AWS が推奨する新世代方式

IRSA（従来型：互換性）

IAM Roles for Service Accounts（従来の Pod 認証）。

# OIDC プロバイダーセットアップ
eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster \
  --approve

# Service Account に IAM ロール付与
eksctl create iamserviceaccount \
  --name my-app-sa \
  --namespace production \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

# Pod で Service Account 使用
kubectl apply -f - << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  template:
    spec:
      serviceAccountName: my-app-sa  # IRSA で権限付与
      containers:
      - name: app
        image: my-app:latest
EOF

ロギング・モニタリング・可視化

CloudWatch Container Insights

AWS ネイティブの監視・ログ統合。

# インストール
eksctl create addon \
  --cluster my-cluster \
  --name amazon-cloudwatch-observability

# CloudWatch Logs でログ確認
aws logs tail /aws/eks/my-cluster/application --follow

Prometheus + Grafana

業界標準のオープンソース監視。

# Prometheus インストール
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

OpenTelemetry

標準化された観測性（メトリクス・ログ・トレース）。

# OpenTelemetry Collector デプロイ
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: otel-collector
  namespace: monitoring
spec:
  template:
    spec:
      containers:
      - name: otel-collector
        image: otel/opentelemetry-collector-k8s:latest
        ports:
        - containerPort: 4317  # gRPC
        - containerPort: 4318  # HTTP

Loki + Promtail

Prometheus ライクなログアグリゲーション。

# Loki ロールアウト
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: my-stack
  namespace: loki
spec:
  size: 1x.small
  storage:
    schemas:
    - from: 2020-12-01
      store: tsdb
      object_store: s3
      index:
        prefix: index_
        period: 24h

セキュリティ

RBAC（Role-Based Access Control）

Kubernetes ネイティブなアクセス制御。

# 読み取り専用ロール
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# ロールバインディング
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: User
  name: developer@example.com

Pod Security Admission

Pod のセキュリティポリシー強制。

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted

OPA / Kyverno

ポリシー as Code（セキュリティ・ガバナンス強制）。

# Kyverno - イメージレジストリホワイトリスト
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-registry
spec:
  validationFailureAction: audit
  rules:
  - name: validate-registry
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Images must be from approved registry"
      pattern:
        spec:
          containers:
          - image: myregistry.azurecr.io/*

Secrets Manager 統合

AWS Secrets Manager のシークレット自動同期。

# ExternalSecrets で自動同期
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets
    kind: SecretStore
  target:
    name: db-secret
    creationPolicy: Owner
  data:
  - secretKey: username
    remoteRef:
      key: prod/rds/username
  - secretKey: password
    remoteRef:
      key: prod/rds/password

EKS アドオン

AWS が提供・管理する拡張機能。

# アドオン一覧確認
aws eks describe-addon-versions --query 'addons[].addonName'

# アドオン有効化
eksctl create addon \
  --cluster my-cluster \
  --name aws-ebs-csi-driver \
  --service-account-role-arn arn:aws:iam::ACCOUNT:role/EBSCSIRole

デプロイメント戦略

GitOps（Argo CD / Flux）

Git リポジトリを single source of truth にした デプロイ自動化。

# Argo CD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-configs
    targetRevision: main
    path: api-service/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Helm

Kubernetes パッケージマネージャ。

# インストール
helm repo add myrepo https://charts.example.com
helm install my-release myrepo/my-chart \
  --namespace production \
  --values values-prod.yaml

Kustomize

宣言的な YAML パッチ管理。

kustomization.yaml
├── base/
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml  # dev 用カスタマイズ
    └── prod/
        └── kustomization.yaml  # prod 用カスタマイズ

ECS vs EKS vs Fargate

初心者向けメモ： 「AWS ならどれを選ぶべき？」という判断フローをまとめました。

graph TD
    Start["AWS でコンテナ運用"]
    
    Start --> Q1{"Kubernetes 標準<br/>エコシステムが必要？"}
    
    Q1 -->|Yes| Q2{"ノード管理を<br/>自分でしたい？"}
    Q1 -->|No| Q3{"運用シンプルさ<br/>最優先？"}
    
    Q2 -->|Yes| Rec1["EKS + <br/>Karpenter<br/>◎ 最大の自由度"]
    Q2 -->|No| Rec2["EKS Auto Mode<br/>◎ 自動管理"]
    
    Q3 -->|Yes| Rec3["ECS<br/>◎ シンプル・<br/>AWS 最適化"]
    Q3 -->|No| Rec4["EKS<br/>◎ 標準"]

詳細比較表：

選定ガイド

ECS 選択：

• AWS 完全専業・他クラウド進出予定なし
• 運用シンプルさ最優先
• チームの Kubernetes 知識がない

EKS 選択： ✅ 推奨

• Kubernetes エコシステム活用したい
• マイクロサービス・ML ワークロード
• 複数チーム・大規模運用
• マルチクラウド・ハイブリッド化予定

Fargate 選択：

• バッチジョブ・一時的ワークロード
• 開発環境・検証環境
• ノード管理ゼロを優先

EKS Anywhere と EKS on Outposts

EKS Anywhere（オンプレミス Kubernetes）

AWS Outposts なしでオンプレミス上で完全な EKS を実行。

# EKS Anywhere クラスタ作成（オンプレミス上）
eksctl anywhere create cluster --config cluster.yaml

# AWS との同期
eksctl anywhere connect cluster --name my-cluster

メリット：

• ✅ AWS コンソールから統一管理
• ✅ 同じ Kubernetes バージョン・パッチ
• ✅ オンプレ・AWS を統一プラットフォームで運用

EKS on Outposts（AWS Outposts 上の EKS）

AWS Outposts（オンプレミス上の AWS ハードウェア）で EKS 実行。

対象：

• AWS Outposts 契約済み
• オンプレミスでマネージド Kubernetes が必要

他の類似ツールとの比較

Google Kubernetes Engine（GKE）

Azure Kubernetes Service（AKS）

Rancher（オンプレ・マルチクラウド管理）

• 複数の Kubernetes クラスタを統一管理
• EKS・GKE・AKS 混合環境対応
• エンタープライズ機能（RBAC・監査等）

OpenShift（Red Hat エンタープライズ K8s）

• Red Hat サポート・エンタープライズ対応
• より厳格なセキュリティ・ガバナンス
• 高額（$$）

Self-managed Kubernetes

• 完全な自由度・カスタマイズ
• 運用負荷最大
• コスト不確定（インフラ・人員）

クライアントとエコシステム

kubectl

Kubernetes API と通信するコマンドラインツール。

# クラスタ切り替え
kubectl config use-context arn:aws:eks:ap-northeast-1:ACCOUNT:cluster/my-cluster

# Pod 一覧
kubectl get pods -n production

# ログ表示
kubectl logs deployment/my-app -n production

# リソース確認
kubectl top nodes
kubectl top pods

eksctl

AWS がサポートする EKS クラスタ管理ツール。

# クラスタ作成
eksctl create cluster \
  --name my-cluster \
  --region ap-northeast-1 \
  --nodegroup-name general \
  --node-type m5.large \
  --nodes 3

# ノードグループ追加
eksctl create nodegroup \
  --cluster my-cluster \
  --name gpu \
  --node-type g4dn.xlarge

Helm

Kubernetes パッケージマネージャ。

# Helm チャートの検索・インストール
helm search repo prometheus
helm install prometheus prometheus-community/kube-prometheus-stack

Argo CD

GitOps ベースの継続デリバリ。

# インストール
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --namespace argocd

Karpenter

ノード自動スケーラ（前述）。

AWS Controllers for Kubernetes（ACK）

Kubernetes API で AWS リソースを管理。

# RDS インスタンスを K8s で管理
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: my-db
spec:
  allocatedStorage: 100
  engine: postgres
  masterUsername: admin
  masterUserPassword:
    name: db-password
    key: password

ベストプラクティス

1. マネージドノードグループを最初は選択

運用負荷を減らすため、セルフマネージドは後で必要になってから。

# ✅ Good
managedNodeGroups:
  - name: default
    instanceType: m5.large
    minSize: 2
    maxSize: 20

# ❌ Avoid（最初は）
# セルフマネージド EC2 Auto Scaling Group

2. 複数 AZ・複数ノードグループ

高可用性・耐障害性確保。

availabilityZones: ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]

managedNodeGroups:
  - name: general  # 汎用
  - name: memory-optimized  # メモリ最適
  - name: compute-optimized  # 計算最適

3. Karpenter for cost optimization

スポット活用で 90% コスト削減。

apiVersion: karpenter.sh/v1beta1
kind: NodePool
spec:
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot", "on-demand"]  # スポット優先

4. RBAC・Pod Identity で最小権限

ノード全体に権限を与えるのではなく、Pod 単位で制限。

❌ Bad
eksctl create iamserviceaccount \
  --attach-policy-arn arn:aws:iam::aws:policy/AdministratorAccess

✅ Good
eksctl create iamserviceaccount \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess

5. CloudWatch Insights + Prometheus + Grafana

多層監視・ログ・メトリクス統合。

# CloudWatch
eksctl create addon --name amazon-cloudwatch-observability

# Prometheus + Grafana
helm install prometheus prometheus-community/kube-prometheus-stack

6. GitOps（Argo CD / Flux）

すべての設定を Git で管理。

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    repoURL: https://github.com/myorg/k8s-configs
    targetRevision: main

7. NetworkPolicy で通信制御

Pod 間通信をホワイトリスト化。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress

8. PodDisruptionBudget で高可用性

ローリングアップデート中の Pod 削除を制限。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

9. リソースリクエスト・リミット設定

Pod がリソースを適切に宣言（スケジューラが最適化）。

containers:
- name: app
  resources:
    requests:
      memory: "512Mi"
      cpu: "250m"
    limits:
      memory: "1Gi"
      cpu: "500m"

10. クラスタ分離（dev / stg / prod）

環境ごとに別クラスタ（Namespace 分離は不完全）。

dev-cluster
  ↓ GitOps promote
stg-cluster
  ↓ GitOps promote
prod-cluster

トラブルシューティング

Pod が Pending 状態

原因：ノード不足 / リソース不足 / スケジューラがマッチするノードがない。

# Pod 詳細確認
kubectl describe pod my-pod -n production
# → Events セクションでブロック理由確認

# ノード確認
kubectl get nodes
kubectl top nodes

# Karpenter ログ
kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter

Pod が CrashLoopBackOff

原因：コンテナが起動直後に終了。

# ログ確認
kubectl logs my-pod -n production
kubectl logs my-pod -n production --previous  # 前回ログ

# 再度確認
kubectl describe pod my-pod

ノードが NotReady

原因：ノード接続喪失 / kubelet 障害 / リソース枯渇。

# ノード詳細
kubectl describe node my-node
# → Status / Conditions セクション確認

# ノード再起動（グレースフル）
kubectl drain my-node --ignore-daemonsets
# → Pod を別ノードに退避
# → ノード再起動
kubectl uncordon my-node

Ingress が動作しない

原因：AWS Load Balancer Controller がない / 設定誤り。

# AWS Load Balancer Controller 確認
helm list -n karpenter  # インストール確認

# Ingress リソース確認
kubectl get ingress
kubectl describe ingress my-ingress

# ALB ログ確認
aws logs tail /aws/elasticloadbalancing/app/my-alb/...

IRSA / Pod Identity 動作しない

原因：IAM ロール未紐付け / Kubernetes Service Account 誤り。

# Service Account 確認
kubectl describe sa my-sa -n production
# → eks.amazonaws.com/role-arn アノテーション確認

# IAM ロール確認
aws iam get-role --role-name my-role

# Pod から AWS API 呼び出し確認
kubectl run debug --image=awscli -- sts get-caller-identity

2025-2026 最新動向

1. EKS Auto Mode GA（v1.28+）★2026年

コントロールプレーン・ノード・CNI・ストレージを AWS が完全自動管理

特性：
  ✅ Karpenter ベースの自動ノード選択
  ✅ Pod 要求に応じた自動スケール
  ✅ VPC CNI・EBS CSI 自動設定
  ✅ ECS に近いシンプルさで Kubernetes 使用
  ✅ 最新機能を自動で取得

メリット：
  → ノード管理ゼロ
  → スポットインスタンス自動活用
  → Pod Identity 自動統合

デメリット：
  → カスタマイズ限定的

利用への移行： マネージドノードグループ → Auto Mode（kubectl applyで完結）

2. EKS Pod Identity GA（2025-2026）★推奨

IRSA をシンプル化した次世代 Pod 認証

従来：Service Account → OIDC → IAM ロール（複雑）
新規：Pod Identity Agent が自動処理

メリット：
  → AWS SDK の認証情報自動注入
  → OIDC プロバイダー設定不要
  → よりシンプル・より安全

EKS Auto Mode では自動統合（エージェント不要）

3. Karpenter v1 安定版（2025年GA）

ノード自動スケーリングの業界標準。最大 90% コスト削減

特徴：
  ✅ スポット・オンデマンド動的選択
  ✅ 要件に最適なインスタンスタイプ自動選択
  ✅ Consolidation（ノード統合・削除）
  ✅ 10-60秒で起動・効率的

Cluster Autoscaler との差：
  → グリーディな固定順序 → 動的最適選択
  → 複雑な設定 → シンプルな NodePool CRD

4. CloudWatch Logs 統合（2026年2月アップデート）

EKS Auto Mode の管理コンポーネント（Karpenter・VPC CNI）ログを CloudWatch に統合。

• 可視化：
• ✅ Karpenter の Pod スケジューリング決定
• ✅ VPC CNI の IP 割り当て詳細
• ✅ リアルタイムトラブルシューティング

5. Generative AI ワークロード標準化（2026年）

LLM 学習・推論・ファインチューニング最適化

統合：
  ✅ Ray on EKS（分散推論・トレーニング）
  ✅ Hugging Face Model Hub
  ✅ GPU オーケストレーション自動化
  ✅ Inferentia2 / Trainium スケジューリング

例：
  - Claude・Llama 推論サービス
  - 社内モデルのファインチューニング
  - GenAI エージェント基盤

6. Hybrid Nodes（Outposts 統合）

AWS Outposts 上で EKS 完全運用。

• 利用形態：
• → AWS Outposts ハードウェア上の EKS クラスタ
• → AWS API 互換性維持
• → オンプレ・AWS 統一プラットフォーム実現

7. GitOps 標準化（2026年）

Argo CD・Flux との AWS 公式統合強化。

• 機能：
• ✅ ArgoCD の AWS 認証ネイティブ対応
• ✅ AWS CodeCommit との連携簡素化
• ✅ GitOps ワークフロー統一

学習リソース

公式ドキュメント

• AWS EKS User Guide
• EKS Best Practices Guide
• Kubernetes Official Docs

トレーニング・認定資格

• AWS 認定： Solutions Architect Pro（EKS 出題範囲）
• Linux Foundation： CKA（Certified Kubernetes Administrator）
• CKAD（Certified Kubernetes Application Developer）

コミュニティ・リソース

• EKS Workshop - ハンズオン
• Karpenter Documentation - ノード自動スケーリング
• Argo CD - GitOps

実装例・活用シーン

シーン 1：マイクロサービス SaaS

EKS クラスタ（prod-1）
├── Namespace: tenant-acme
│   ├── api-service
│   ├── web-ui
│   └── backend-worker
├── Namespace: tenant-globex
│   ├── api-service
│   ├── web-ui
│   └── backend-worker
├── Istio（ServiceMesh）
│   ├── mTLS 自動化
│   ├── カナリアリリース
│   └── 分散トレーシング
└── Monitoring
    ├── Prometheus
    ├── Grafana
    └── Tempo

シーン 2：ML 推論プラットフォーム

EKS + GPU ノードグループ
├── KServe（モデルサービング）
├── Ray on Kubernetes（推論並列化）
├── 負荷テスト（k6）
└── A/B テスト・カナリア制御

シーン 3：全社デジタル基盤

EKS Anywhere（オンプレミス）←→ EKS（AWS）
├── Karmada（マルチクラスタ管理）
├── Rancher（管理画面）
├── Argo CD（GitOps）
└── Vault（シークレット管理）

導入ロードマップ

Phase 1（1-3 ヶ月）：学習・検証

1. Kubernetes 基礎学習（Pod・Service・Deployment）
2. EKS ハンズオン（EKS Workshop）
3. テストクラスタ構築（eksctl で 1-2 クラスタ）
4. IRSA / Pod Identity 動作確認

Phase 2（3-6 ヶ月）：開発環境構築

1. dev クラスタ本番化（マネージドノードグループ）
2. CloudWatch / Prometheus 監視セットアップ
3. GitOps（Argo CD）導入
4. Karpenter 試験導入

Phase 3（6-12 ヶ月）：本番運用開始

1. stg → prod クラスタ段階的移行
2. セキュリティ強化（RBAC・NetworkPolicy・OPA）
3. 高可用性設計（複数 AZ・PDB・リソース管理）
4. コスト最適化（Karpenter・スポット・予約インスタンス）

Phase 4（12+ヶ月）：高度な運用

1. EKS Auto Mode への段階的移行
2. マルチクラスタ・マルチリージョン展開
3. Platform Engineering（Internal Developer Platform）確立
4. AI/ML ワークロード標準化

実装チェックリスト

クラスタセットアップ

• ✅ クラスタ作成（マネージドノードグループ）
• ✅ ノードグループは複数 AZ
• ✅ OIDC プロバイダーセットアップ（Pod Identity 準備）
• ✅ CloudWatch Container Insights 有効化
• ✅ Karpenter インストール（オプション）

ネットワーク・セキュリティ

• ✅ VPC CNI 設定
• ✅ Security Groups for Pods（オプション）
• ✅ NetworkPolicy でホワイトリスト通信制御
• ✅ RBAC ロール・ロールバインディング設定
• ✅ Pod Security Admission 有効化

ストレージ・データベース

• ✅ EBS CSI Driver アドオン
• ✅ EFS CSI Driver アドオン（共有ストレージ必要時）
• ✅ RDS / DynamoDB 外部統合

監視・ログ・トレーシング

• ✅ Prometheus インストール
• ✅ Grafana ダッシュボード作成
• ✅ Loki でログ集約（CloudWatch でも可）
• ✅ Tempo で分散トレーシング（オプション）
• ✅ CloudWatch Logs でアプリログ

デプロイメント・運用

• ✅ Helm チャート活用
• ✅ Argo CD / Flux で GitOps 構築
• ✅ Kustomize で環境別設定管理
• ✅ Pod リソースリクエスト・リミット設定
• ✅ HPA（Horizontal Pod Autoscaler）設定
• ✅ PodDisruptionBudget 設定（本番ワークロード）

セキュリティ・コンプライアンス

• ✅ IAM ロール・ポリシーの最小権限化
• ✅ Pod Identity / IRSA で Pod 認証
• ✅ Secrets Manager / Vault 統合
• ✅ 監査ログ有効化
• ✅ OPA / Kyverno でポリシー強制

まとめ

Amazon EKS は 「Kubernetes 標準エコシステムを完全活用し、AWS の管理サービスとシームレスに統合した、企業級のコンテナプラットフォーム」 です。

EKS を選ぶべき 3 つの理由

1. Kubernetes 標準エコシステム

   • Helm・Prometheus・Grafana・Istio・Argo CD・Karpenter がそのまま動作
   • ポータビリティ（マルチクラウド・オンプレミス対応）

2. AWS ネイティブな統合

   • VPC・IAM・RDS・DynamoDB・CloudWatch との完全統合
   • EKS Pod Identity で Pod 単位のセキュリティ

3. 高度なスケーリング・コスト最適化

   • Karpenter で 90% コスト削減
   • HPA・VPA で動的スケーリング
   • EKS Auto Mode で完全自動管理

導入時の重要ポイント

✅ 段階的導入：dev → stg → prod で段階的に移行

✅ チーム体制：Kubernetes 知識を持つメンバーの確保

✅ 監視・ログ設計：最初から CloudWatch / Prometheus を組み込む

✅ セキュリティ第一：RBAC・NetworkPolicy・Pod Identity を最初から設定

✅ コスト管理：Karpenter・スポットインスタンスで継続的に最適化

EKS vs 他サービス

EKS は AWS のコンテナプラットフォームの最高峰であり、大規模・複雑・長期運用されるシステムに最適な選択肢です。

参考文献

AWS 公式ドキュメント

1. AWS EKS User Guide
2. EKS Auto Mode Documentation ★2026年
3. EKS Pod Identity Guide
4. EKS Best Practices Guide
5. AWS EKS Pricing
6. Karpenter on EKS
7. AWS EKS Security

Kubernetes・CNCF 公式

8. Kubernetes Official Documentation
9. Kubernetes Release Notes
10. Helm - パッケージマネージャ
11. Karpenter Official - ノード自動スケーリング
12. Argo CD - GitOps
13. Istio - サービスメッシュ
14. Prometheus - メトリクス収集
15. Grafana - ダッシュボード

学習リソース・ハンズオン

16. EKS Workshop - AWS 公式ハンズオン
17. Linux Foundation - CKA - 認定試験
18. Kubernetes by Example - 実装例
19. CNCF Cloud Native Roadmap
20. 12 Factor App - アプリ設計原則

ブログ・最新ニュース

21. AWS Containers Blog - EKS 最新情報
22. AWS Architecture Blog
23. CNCF Blog

最終更新：2026-04-26 バージョン：v2.4（Auto Mode・Pod Identity・Karpenter v1 GA対応） 著者：Claude (Anthropic) — i のメモ拡充プロジェクト