この記事の概要
- EKS Auto Modeはノード管理・GPU Operator設定・OSパッチ適用をすべてAWSが自動化。Karpenter手動設定が不要になる
- Graviton5(M9gインスタンス)はGraviton4比で最大25%高性能・ML推論35%高速化。AIワークロードのコスト対性能が大幅改善
- GPU推論PodはリソースリクエストにGPU数を指定するだけでプロビジョニングが自動完結する
背景・概要
re:Invent 2025でAWSが発表したEKS Auto Modeは、「Kubernetesのノード管理をどこまでマネージドにできるか」というエンジニアの長年の課題に真正面から答えた機能です。
これまでEKSでGPUクラスターを運用しようとすると、Karpenterのインストール・NodePoolとEC2NodeClassの設定・NVIDIA GPU Operatorのデプロイと設定・ノードOSのセキュリティパッチ管理など、コア業務とは別の「インフラの面倒みる仕事」が積み重なっていました。
EKS Auto Modeはこれらをすべてマネージドにします。
同時期に登場したGraviton5(M9gインスタンス)と組み合わせることで、AIワークロードの運用工数とコストを同時に削減できる構成が現実的になりました。
詳細解説
EKS Auto Mode とは何か
EKS Auto Modeは、クラスターのノードライフサイクル全体をAWSが管理するモードです。
従来のEKSとの最大の違いは、以下のコンポーネントがすべて内包されている点です。
| 機能 | 従来のEKS(セルフ管理) | EKS Auto Mode |
|---|---|---|
| ノードプロビジョニング | Karpenter or Managed Node Group | 自動(不要) |
| GPU Operator | 手動インストール | 自動 |
| EBS CSIドライバー | 手動インストール | 自動 |
| OSセキュリティパッチ | ユーザー責任 | AWSが自動適用 |
| CoreDNS / kube-proxy | 手動設定 | 自動 |
| Network Policy | 別途設定 | 内蔵 |
GPUワークロードに特に効いてくるのがSOCI(Seekable OCI)の自動有効化です。
vLLMやPyTorchのコンテナイメージはサイズが大きく、ノードの起動からPod稼働まで時間がかかるのが課題でした。
EKS Auto ModeはP系・Trainium系インスタンスでSOCIを自動有効化し、コンテナイメージのpull時間を最大60%短縮します。
コールドスタートが遅いAI推論サービスには直接効いてくる改善です。
対応リージョンは全商用EKSリージョン・AWS GovCloud・Local Zonesと幅広く展開されています。
Karpenter との比較:どちらを選ぶか
「Karpenterを使っているけど、Auto Modeに移行すべき?」という疑問を持つエンジニアは多いと思います。
正直に言うと「どちらが優れているか」ではなく「何を優先するか」で決まります。
| 項目 | Karpenter | EKS Auto Mode |
|---|---|---|
| 設定の複雑さ | 中(NodePool/EC2NodeClass要設定) | 低(マネージド) |
| カスタマイズ性 | 高 | 中 |
| GPU対応 | 手動設定必要 | 自動 |
| OS管理 | ユーザー | AWS |
| 向いているケース | 細かく制御したい | 運用工数を下げたい |
社内のプラットフォームチームがKubernetesを深く理解していて、スポットインスタンスの細かい制御やカスタムAMIが必要なケースではKarpenterが引き続き有力です。
一方で、「GPUクラスターを素早く立ち上げて、できるだけAWSに任せたい」というMLOpsチームや小〜中規模のAIプロダクトチームにはEKS Auto Modeが刺さります。
Graviton5(M9g)の実力
Graviton5はAWSの第5世代Armプロセッサで、M9gインスタンスとして提供されています。
前世代Graviton4との比較で注目すべき数字はこちらです。
- 汎用パフォーマンス: 最大25%向上
- ML推論速度: 最大35%高速化
- アーキテクチャ: 192コア/チップ、キャッシュ容量5倍増
実際のユーザー事例も出ています。
- Atlassian: Jira on Graviton5で30%高性能・20%低レイテンシを達成
- SAP: HANA Cloud OLTPクエリが35〜60%高速化
- Honeycomb: 36%高スループット/コアを実現
MLのトレーニングよりも推論フェーズ(本番デプロイ後の継続稼働)でGraviton5を活用すると、コスト削減効果が大きいです。
推論はGPU必須のモデルばかりではなく、軽量モデルや埋め込み生成などCPUで十分なケースも多いからです。
EKS Auto Mode のアーキテクチャ
sequenceDiagram
participant Dev as 開発者
participant K8s as Kubernetes API
participant AM as EKS Auto Mode<br/>コントローラー
participant EC2 as EC2 (GPU/Graviton5)
participant Pod as Pod
Dev->>K8s: GPU Pod マニフェスト apply
K8s->>AM: スケジューリング不可(ノード不足)を検知
AM->>EC2: GPU対応ノード自動プロビジョニング<br/>(GPU Driver・Device Plugin自動設定)
EC2-->>AM: ノード Ready
AM->>Pod: Pod をノードにスケジュール
Pod-->>Dev: 推論エンドポイント起動完了
Note over AM,EC2: OSパッチ・ノードアップグレードも<br/>EKS Auto Modeが自動管理
具体的な使い方
EKS Auto Modeでのクラスター作成は驚くほどシンプルです。
# EKS Auto Mode でクラスター作成
eksctl create cluster \
--name ai-cluster \
--region ap-northeast-1 \
--auto-mode
# これだけ完了!
# Karpenter・CoreDNS・kube-proxy・GPU Operatorの設定が自動
GPUワークロードのデプロイも通常のKubernetesマニフェストと変わりません。
nvidia.com/gpu リソースを指定すれば、EKS Auto Modeが自動でGPUノードをプロビジョニングしてくれます。
# GPU推論Podのマニフェスト(EKS Auto Modeで自動スケジューリング)
apiVersion: v1
kind: Pod
metadata:
name: vllm-inference
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
resources:
limits:
nvidia.com/gpu: "1"
command: ["python", "-m", "vllm.entrypoints.openai.api_server",
"--model", "meta-llama/Meta-Llama-3-8B-Instruct"]
# EKS Auto Modeが自動でGPUノードをプロビジョニング
# GPU DriverやDevice Pluginの設定は一切不要
実務での活用方法
AIプロダクトの推論基盤構築
vLLMやText Embeddings Inferenceを使った推論サービスをEKS上に構築する場合、EKS Auto Modeが特に力を発揮します。
モデルのサイズが大きくなるほどコンテナイメージも肥大化しますが、SOCIによる並列プルで起動時間のボトルネックを解消できます。
実践的な構成例として、GPU推論にはP系インスタンス(EKS Auto Modeで自動管理)、埋め込みやリランカーなど軽量モデルにはM9g(Graviton5) という使い分けが効果的です。
GPU費用を最小化しながら処理能力を確保できます。
既存Karpenterクラスターからの移行検討
既存クラスターを移行する場合は段階的なアプローチが現実的です。
まず新しいAIワークロード用の名前空間やクラスターだけEKS Auto Modeで立ち上げ、運用感を確認してから既存クラスターの移行を検討するのがリスクが低い進め方です。
Karpenterで高度にチューニングしたスポット活用設定がある場合は、Auto Modeへの移行でその設定が失われることに注意してください。
コスト最適化より運用工数の削減を優先するプロジェクトでAutoModeを選ぶとミスマッチが少ないです。
まとめ
EKS Auto Mode × Graviton5の組み合わせは、AIワークロードの「動かす」コストを下げるための実践的な選択肢として注目に値します。
- EKS Auto ModeはGPU管理・ノードライフサイクル・セキュリティパッチをフルマネージドにし、インフラの運用工数を大幅削減
- Graviton5(M9g)はML推論35%高速化で、GPUが不要なAIタスクのコスト対性能を改善
- 導入判断の基準は「カスタマイズ性より運用楽さを優先するか」
re:Invent 2025の発表内容は公式ドキュメントおよびAWS Blogで継続的に詳細が公開されています。
新機能の動向はEKS公式ドキュメントとAWS Containers Blogを定期チェックすることをお勧めします。
この記事はre:Invent 2025発表情報をもとに執筆しています。
サービスの詳細仕様はAWS公式ドキュメントで最新情報を確認してください。

コメント