ひとことで言うと
マネージドKubernetesです。GenAIの文脈での役どころはECSのEC2起動タイプとほぼ重なりますが、Kubernetes標準のツール群（Helm・Karpenter・GPU Operator等）をそのまま持ち込める点が違います。GPUだけでなくInferentia・Trainiumのノードもサポート対象です。
要するに、標準規格の工場です。ECSはAWS専用のライン、EKSは業界標準のライン（Kubernetes）。標準規格のぶん、外部のML運用ツール（Kubeflow・Ray等）をそのまま持ち込めます。
その代わり、標準規格を動かすための設定（デバイスプラグイン・ドライバのインストール）は自分たちで面倒を見る場面が増えます。
なぜ生まれたか
自前のGenAIモデルをコンテナでGPU推論・学習させたい要求はECSと同じですが、すでにKubernetesで運用基盤を持つ組織や、OSSのML運用ツール（分散学習・推論のオーケストレーションツール）を前提に設計したいケースでは、AWS専用のオーケストレーションであるECSでは足りません。
EKSはこの隙間を、Kubernetes互換を保ったまま、GPU・Inferentia・Trainiumインスタンス向けに事前構成済みのAMI（EKS-optimized accelerated AMI）を提供することで埋めています。ドライバ・CUDAツールキット・コンテナランタイムがあらかじめ組み込まれているため、Kubernetesのノードとして参加させるだけでアクセラレータが使える状態になります。
| ECSでは足りない要求 | EKSが埋める形 |
|---|---|
| Kubernetes標準ツール（Helm・Kubeflow等）の活用 | Kubernetes互換のオーケストレーション |
| Inferentia/Trainium向けの学習・推論 | Neuron向け最適化AMI |
| マルチクラウド前提の運用ノウハウ | AWS専用でないKubernetes API |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| GPUノードでの自前モデル推論・学習 | AL2023/Bottlerocketの NVIDIA向け最適化AMIでノードグループを構成する | D2 |
| Inferentia/Trainiumでの推論・学習 | Neuron向け最適化AMI（aws-neuronx-dkms等を内蔵）でノードを構成する | D2・D4 |
| Kubernetesネイティブなオートスケール | Karpenterと組み合わせ、GPUノードプールを需要に応じて増減させる | D4 |
| OSSのMLオーケストレーション | Kubeflow・Ray等、Kubernetes前提のツールをそのまま載せる | D2 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 「Kubernetesの運用ノウハウ・ツールを活かしてGenAIモデルをGPUで動かしたい」 | Kubernetesエコシステム前提 → EKS＋GPU最適化AMI | ECS（AWSネイティブで完結し、Kubernetesツールは持ち込めない） |
| GPUノードでNVIDIA GPU Operatorを併用したい | ドライバの二重管理を避ける → EKS-optimized AMI側のドライバインストールを無効化し、Operatorに一本化（もしくは逆） | 両方が個別にドライバをインストールし競合する構成をそのまま使う |
| 古いP2インスタンスでGPU推論を続けたい | P2は非対応 → サポート対象インスタンスタイプへの移行が必要 | P2をそのままEKSクラスタに参加させようとする（NVIDIAドライバ470以前が必要でEKSは非対応） |
Amazon EC2 P2インスタンスはAmazon EKSでサポートされていません。P2が要求する古いNVIDIAドライババージョン（470以前）が理由で、公式に非対応と明記されています。GenAIの学習・推論コストを抑えるためにレガシーなGPUインスタンスを使い回そうとするシナリオでは、この非対応が引っかけとして機能します。
実務でどう使うか
- EKS-optimized accelerated AMIには、GPU向け（NVIDIA）とアクセラレータ向け（Neuron/Inferentia・Trainium）の2系統がある。 モデルの実行先ハードウェアに応じて選ぶAMIが変わります
- NVIDIA GPU OperatorとEKS-optimized AMIを併用する場合、ドライバとツールキットのインストールをどちらか一方に一本化する必要があります。 両方が個別にインストールを試みると競合します
- NVIDIA Kubernetesデバイスプラグイン・DRAドライバはAL2023 NVIDIA AMIには含まれていません。 別途インストールが必要で、Bottlerocket側は構成が異なります。AMIの種類ごとに「何が最初から入っていて、何を自分で足すか」が違う点に注意します
- 新しいGPU世代（G7）は最新のEKS-optimized AMIでもドライババージョンが対応していないことがあります。 最新世代のインスタンスを使う場合はカスタムAMIのビルドが必要になる場合があります
| AMI系統 | 対応ハードウェア |
|---|---|
| AL2023 / Bottlerocket NVIDIA | GPU（p3・p4d・p5・g4dn・g5・g6等） |
| AL2023 / Bottlerocket Neuron | Inferentia・Trainium |
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon ECS（EC2起動タイプ） | どちらもGPUインスタンスでコンテナを動かせる。Kubernetes標準ツール・マルチクラウド前提ならEKS、AWSネイティブな構成で完結するならECS |
| SageMaker AI（HyperPod等） | SageMaker AIはMLライフサイクル管理までカバーするマネージドサービス。EKSはオーケストレーション基盤であり、その上のML運用は自分たちで組む |
| AWS Fargate | FargateにGPUという選択肢はそもそも存在しない。GPUが要件に出た時点でEKS（またはECSのEC2起動タイプ）に絞られる |
| Amazon Bedrock | Bedrockは基盤モデルを借りる。EKSは自前のモデル・自前の推論スタックをKubernetes上で建てる選択で、要件が「独自モデル・独自の運用ツール」であるほどEKS側に寄る |
想起チェック
Q1. GenAIモデルの推論をGPUで、かつKubernetesの運用資産を活かして動かしたいときの選択肢は？
Amazon EKS＋EKS-optimized accelerated AMIです。ECSはAWSネイティブなオーケストレーションでKubernetesツールを持ち込めないため、Kubernetesエコシステムが前提条件になっているシナリオではEKSが正解に寄ります。
Q2. P2インスタンスでEKSのGPUワークロードを組もうとするとどうなるか？
サポートされていません。 P2が要求する古いNVIDIAドライバ（470以前）にEKSが対応していないためです。GPUインスタンスは現行世代への移行が前提になります。