はじめに
2026 年 5 月 5 日、AWS は Amazon EC2 Instance Store CSI ドライバーを Amazon EKS アドオンとして正式に GA（一般提供開始）しました。
これまで、EKS 上で Instance Store を使うにはドライバーを手動で管理する必要がありました。今回のアドオン化でその手間が変わります。
本記事では「何が変わったのか」「どんな制約があるのか」「実際にどう使うのか」を順に整理します。低レイテンシなローカルストレージを EKS 上で活用したいエンジニアを対象にしています。
何が変わったのか
EKS 上で Instance Store を Kubernetes から利用するには、これまで CSI ドライバーを自前でインストール・設定・管理する必要がありました。今回のアップデートで何が変わったのかを整理します。
| 項目 | Before | After |
|---|---|---|
| ドライバーのインストール | マニフェストを手動で適用 | EKS コンソール / AWS CLI から追加 |
| バージョン管理 | 自前で互換性を確認・適用 | AWS が管理（最新版と 1 つ前のバージョンをサポート） |
| セキュリティパッチ | 手動で対応 | 最新版の修正を前バージョンにもバックポート |
| EKS バージョンアップ時の対応 | ドライバーの互換性を都度確認 | アドオンとして追従 |
従来の課題
CSI ドライバーを自己管理する場合、インストール時のマニフェスト管理に加え、EKS バージョンアップのたびにドライバーの互換性確認とアップグレード作業が必要でした。
EKS アドオン化による変化
EKS アドオンとして提供されたことで、インストールはコンソールまたは AWS CLI から数ステップで完了します。最新版とその一つ前のバージョンが AWS によってサポートされ、脆弱性修正は前バージョンにもバックポートされます。本機能はすべての商用リージョンで利用可能です。
ドライバーを理解する
EC2 Instance Store とは
EC2 Instance Store は、ホストコンピューターに物理的に接続されたブロックストレージです。ネットワーク越しにアクセスする EBS とは異なり、ホストに直結しているため低レイテンシ・高スループットが得られます。一方で、インスタンスが停止・終了するとデータは失われるエフェメラルなストレージです。
CSI ドライバーの役割
CSI（Container Storage Interface）は、Kubernetes がさまざまなストレージシステムと連携するための標準インターフェースです。EC2 Instance Store CSI ドライバーはこの仕様に準拠したプラグインで、NVMe デバイスの検出・フォーマット・マウントを自動化します。Pod からは標準の PVC 経由でストレージにアクセスできます。EBS CSI ドライバーと異なり、AWS API を呼び出さずローカルの Linux 操作で NVMe デバイスと直接やり取りするため、IAM ロールは不要です。
「永続ボリューム」なのにエフェメラル？
「Persistent Volume として使う」と聞くと、データが永続化されるように聞こえますが、ここには注意が必要です。Kubernetes における PersistentVolume（PV）とは、ストレージリソースを Pod のライフサイクルから切り離して管理するための抽象化の仕組みです。データが永続化されることを保証するものではありません。
Instance Store を PV として扱うことで、Pod から標準の PVC（PersistentVolumeClaim）経由でアクセスできますが、データ自体はエフェメラルであることに変わりはなく、ノードが終了するとデータは消失します。キャッシュや中間データなど「速さは必要だが永続化は不要」な用途に向いているストレージです。
使う前に確認したい制約
導入前に必ず把握しておきたい制約をまとめます。
⚠️ 重要: アドオンのインストール時に、エフェメラルディスク上の既存データはすべて消去されます。LVM・raw ファイルシステム・LUKS など別の CSI ドライバーやボリューム管理システムがエフェメラルディスクを管理している場合は、インストール前に必ずバックアップを取得してください。
動作環境の制限
| 制約 | 内容 |
|---|---|
| EKS Auto Mode | 非対応 |
| Fargate | Fargate Pod へのマウント不可 |
| ボリューム拡張 | 非対応 |
対応していないインスタンスタイプ
Instance Store を搭載していても、以下のインスタンスタイプでは本ドライバーは利用できません。
C1, C3, C4, C5d, C5ad, C6gd,
D2, D3, D3en, DL1,
E3, Edge1gd, F1,
G2, G3, G4ad, G4dn,
H1, HSM1,
I2, I3, I3.metal, I3en,
M1, M2, M3, M4, M5d, M5ad, M5dn, M6gd,
P2, P3, P3dn, P4d, P4de,
R3, R4, R5d, R5ad, R5dn, R6gd,
T1, T2,
X1, X1e, X2gd, Z1d
このリストに含まれない NVMe Instance Store 搭載インスタンス（例：i4i、i4g、im4gn、is4gen など）が対象となります。インスタンスタイプを選定する際は、上記の非対応リストに含まれていないことを事前に確認してください。
よくある誤解：i3 や p3 は Instance Store を搭載したインスタンスとして知られていますが、いずれも非対応リストに含まれています。世代の古いインスタンスタイプや一部の GPU インスタンスは利用できないケースが多いため、インスタンス選定時に必ず確認することを推奨します。
エフェメラル性について
Instance Store はノードが終了するとデータが消失します。重要なデータを扱う場合はアプリケーション側でのレプリケーションやバックアップが必須です。詳細は 7 章のベストプラクティスで取り上げます。
インストール手順
前提条件
- 既存の Amazon EKS クラスターが存在すること
- 対応インスタンスタイプのノードグループが存在すること（4 章参照）
- EKS Auto Mode・Fargate 環境でないこと
AWS CLI でインストールする
Step 1: 利用可能なアドオンバージョンを確認する
1.32 の部分をクラスターの Kubernetes バージョンに置き換えて実行します。
aws eks describe-addon-versions \
--kubernetes-version 1.32 \
--addon-name aws-ec2-local-instance-store-csi-driver \
--query "addons[].addonVersions[].addonVersion"
Step 2: アドオンを追加する
<cluster-name> をクラスター名に置き換えて実行します。
aws eks create-addon \
--cluster-name <cluster-name> \
--addon-name aws-ec2-local-instance-store-csi-driver \
--resolve-conflicts OVERWRITE
Step 3: インストールを確認する
aws eks describe-addon \
--cluster-name <cluster-name> \
--addon-name aws-ec2-local-instance-store-csi-driver \
--query "addon.status"
ACTIVE が返れば完了です。
コンソールでインストールする
- Amazon EKS コンソール を開く
- 対象クラスターを選択し、[Add-ons] タブを選択
- [Get more add-ons] を選択
-
EC2 Instance Store CSI Driverを検索して選択し、[Next] へ - バージョンは特段の理由がなければ latest を選択
- 確認画面で [Create] を選択
手動インストール済み環境からの移行
すでに Instance Store CSI ドライバーを手動でインストールしている場合は、アドオン化の際に競合が発生する可能性があります。--resolve-conflicts OVERWRITE を指定することで、既存の自己管理ドライバーの設定を上書きしてアドオンに移行できます。
カスタム設定を加えている場合は、上書き前に設定内容を記録しておいてください。移行後にアドオンの設定として再適用が必要になる場合があります。
実践的な設定例
StorageClass を作成する
Instance Store CSI ドライバーのプロビジョナー名は lis.csi.aws.com です。volumeBindingMode: WaitForFirstConsumer を設定することで、Pod がスケジュールされるノードに合わせてボリュームがバインドされます。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ec2-instance-store-sc
provisioner: lis.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
PVC を作成する
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: instance-store-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: ec2-instance-store-sc
resources:
requests:
storage: 100Gi
Pod にマウントする
apiVersion: v1
kind: Pod
metadata:
name: instance-store-pod
spec:
containers:
- name: app
image: amazonlinux:2
command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
volumeMounts:
- mountPath: /data
name: instance-store-vol
volumes:
- name: instance-store-vol
persistentVolumeClaim:
claimName: instance-store-pvc
I/O スロットリングについて
本ドライバーはデフォルトで I/O スロットリングが有効になっています。同一ノード上の複数ワークロードが NVMe コントローラーの帯域を公平に共有するための仕組みです。
スロットリングは StorageClass のパラメーターまたは PVC のアノテーションで制御します。PVC のアノテーションが StorageClass の設定より優先されます。
| PVC アノテーション | StorageClass パラメーター | 結果 |
|---|---|---|
| 未設定 | 未設定 | スロットリング有効（デフォルト） |
| 未設定 | "false" |
スロットリング無効 |
"false" |
"true" または未設定 |
スロットリング無効 |
"true" |
"false" |
スロットリング有効 |
StorageClass レベルで無効化する場合：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ec2-instance-store-unthrottled
provisioner: lis.csi.aws.com
parameters:
throttling: "false"
volumeBindingMode: WaitForFirstConsumer
PVC レベルで個別に無効化する場合：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: high-perf-pvc
annotations:
lis.csi.aws.com/throttling: "false"
spec:
accessModes:
- ReadWriteOnce
storageClassName: ec2-instance-store-sc
resources:
requests:
storage: 100Gi
注意: スロットリングを無効化したワークロードは、同一ノード上の他のワークロードの I/O 帯域に影響を与える場合があります。専用ノードへの隔離を検討してください。
ベストプラクティス
エフェメラル性を前提とした設計
Instance Store はノード終了時にデータが消失します。重要データはアプリケーション層でレプリケーションする設計が基本です。Redis Cluster・Cassandra・Kafka のように、データを複数ノードに分散して保持できる構成が有効です。
機械学習の学習ジョブであれば、中間チェックポイントを定期的に S3 や EBS へ書き出すことで、ノード障害時のやり直しコストを抑えられます。用途としてはキャッシュ・バッファ・一時ファイルのように消えても再生成できるデータが適しています。
階層型ストレージ設計
Instance Store 単独ではなく、EBS や S3 と組み合わせた階層型ストレージ設計を推奨します。
| 層 | ストレージ | 用途 |
|---|---|---|
| ホット層 | Instance Store（NVMe） | 高速アクセスが必要なキャッシュ・作業領域 |
| ウォーム層 | EBS（gp3） | 準永続データ・DB のデータファイル |
| コールド層 | S3 | 長期保存・バックアップ・チェックポイント |
トポロジー対応スケジューリング
StorageClass に volumeBindingMode: WaitForFirstConsumer を設定することで、Pod がスケジュールされるノードに合わせてボリュームがバインドされます。Instance Store はホストに物理的に紐づいているため、この設定は必須です（6 章の設定例参照）。
ノードドレイン時のデータ保護
ノードメンテナンスやスケールインの際、Pod が強制終了されるとデータが失われます。PodDisruptionBudget（PDB）を設定することで、一度に退避される Pod 数を制限し、アプリケーション側でのデータ退避処理の時間を確保できます。
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: app-pdb
spec:
minAvailable: 1
selector:
matchLabels:
app: my-app
I/O スロットリングの使い分け
デフォルトのスロットリング有効設定は、複数ワークロードが同一ノードを共有する場面で帯域の分配を保証します。最大スループットが必要な単独ワークロードの場合はスロットリングを無効化する選択肢もありますが、その場合は専用ノードグループへの隔離を合わせて検討してください（6 章参照）。
Karpenter との組み合わせ
Karpenter を使用している場合、NodePool に対応インスタンスタイプを明示的に指定することで、ドライバーが利用可能なノードへのスケジューリングを制御できます。非対応インスタンスタイプが混在しないよう、NodePool の requirements で対応インスタンスファミリーを絞り込む設計が前提になります（4 章参照）。
まとめ
EKS アドオンとして提供されたことで、これまで手動管理が必要だった Instance Store の導入ハードルは下がりました。低レイテンシなローカル NVMe ストレージを Kubernetes から扱いたいチームにとっては、試しやすくなった変化です。
一方で、エフェメラルなストレージであること・対応インスタンスタイプに制限があること・インストール時にディスク上のデータが消去されることなど、事前確認が必要な制約は少なくありません。4 章の内容を確認したうえで、用途に合ったインスタンスタイプと階層型ストレージ設計を検討してください。