トップ > Amazon EKS > Amazon EKSにおけるAmazon S3 CSIドライバーの機能が強化されました

Amazon EKSにおけるAmazon S3 CSIドライバーの機能が強化されました

Amazon EKS Amazon S3
記事タイトルとURLをコピーする

こんにちは。2025年8月にサーバーワークスに入社し、エデュケーショナルサービス課で研修中の髙橋省伍です。

Amazon EKS における Mountpoint for Amazon S3 CSI (Container Storage Interface)ドライバーの機能が強化され、v2 がリリースされましたので4つのポイントをお知らせしたいと思います。

Mountpoint for Amazon S3 CSI ドライバーとは

Amazon EKS はデフォルトでは永続ストレージを持っておらず、利用したい場合には Amazon EBS、EFS、FSx、S3 が選択肢に入るかと思います。

これらを利用するためにそれぞれ CSI ドライバーが用意されています。

S3 については Mountpoint for Amazon S3 CSI ドライバーを EKS クラスタにインストールすることで、ファイルストレージかのようにマウントすることができます。

aws.amazon.com

repost.aws

ポイント1 ： 複数 Pod にまたがるデータキャッシュ機能のサポート

EKS Pod から S3 上のファイルにアクセスする際は、CSI ドライバーが S3 からデータを読み込み、Pod に提供します。

同時にそのデータをワーカーノード上に確保したキャッシュ領域にも書き込み、2回目以降のアクセスに使用されます。

結果として大規模な金融シミュレーションジョブを最大で2倍高速に完了します。

以前（v1）

Pod 単位でキャッシュし、個別の Pod ごとに独立していました。

これから（v2）

ワーカーノード単位でキャッシュし、複数 Pod で共有することで S3 へのリクエスト数とデータ転送量が削減され、リソースを効率的に利用できるようになります。

ポイント2 ： SELinux 対応環境で Kubernetes アプリケーションを実行可能になった

Mountpoint for Amazon S3 はブロックストレージである S3 をあたかもファイルストレージのように見せかける性質があります。

SELinux 対応環境上では、セキュリティコンテキスト（ラベル）をうまくハンドリングできない課題があり、Kubernetes アプリケーションを利用することは事実上不可能、あるいは非常に困難でした。

具体的には以下のような問題がありました。

  • Pod にマウントされた S3 ボリュームのファイルに、SELinux が必要とする適切なセキュリティラベルを付与できない
  • SELinux が有効になっていると、コンテナ内のプロセスがマウントポイントに対してファイルの読み書きを行おうとしても、SELinux のポリシーによってアクセスが拒否されてしまう

v2 ではこれらの課題を解決し、SELinux のマウントオプションに正式に対応しました。

これにより、Podの定義（Pod Spec）内で seLinuxOptions を指定するだけで、マウントされるボリュームに対して適切なセキュリティコンテキストを自動的に付与できるようになりました。

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-app-container
      image: my-image
      volumeMounts:
        - name: s3-volume
          mountPath: /data
  volumes:
    - name: s3-volume
      csi:
        driver: s3.csi.aws.com
        volumeHandle: my-bucket
        volumeAttributes:
          ...
        # SELinuxのコンテキストを指定
        seLinuxOptions:
          level: "s0:c123,c456"

ポイント3 ： EKS Pod Identityを使用してEKS クラスタ間のアクセスポリシーの管理を簡素化

この変更を理解するには、IAM Roleの「信頼ポリシー」と EKS クラスタ間での「関連付け」の仕組みが鍵になります。

以前 （v1）

EKS クラスタ上で稼働する Pod から周辺のリソースに対してアクセス権限を付与する際に、IAM Role を割り当てる IAM Roles for Service Accounts（IRSA）という仕組みがあります。

IRSA では以下の課題がありました。

  • ある IAM Roleを3つの異なる EKS クラスタで使いたい場合、その IAM Role の信頼ポリシーに3つのクラスタすべての OIDC プロバイダ ARN を列挙する必要がある
  • クラスタを追加・削除するたびに IAM Role を修正する必要があり、クラスタ数が増えると管理が煩雑


IRSA の信頼ポリシー（例：S3バケットへのアクセス権を持つ IAM Role イメージ）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.region.amazonaws.com/id/CLUSTER_A_ID",
          "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.region.amazonaws.com/id/CLUSTER_B_ID",
          "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.region.amazonaws.com/id/CLUSTER_C_ID"
        ]
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": { ... }
    }
  ]
}

新しい方法 （v2）

クラスタ固有の ID ではなく、pods.eks.amazonaws.com という新しい共通のサービスプリンシパルを指定します。

EKS Pod Identity では IAM Role の信頼ポリシーは汎用的に記述するように変わり、管理が楽になります。


EKS Pod Identityの信頼ポリシー（イメージ）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

これにより IAM Role は特定のクラスタに依存しなくなり、一度作成すればどのクラスタで使うためにも修正は不要になります。

「どのクラスタ」の「どの Pod（ServiceAccount）」がその IAM Role を使うか、という関連付けは EKS クラスタ内の PodIdentityAssociation というリソースでおこないます。

ポイント4 ： kubectl logs で pod がマウントしている S3 情報が取得可能

これまで必要だった煩雑な手順を踏まずに、標準的な kubectl logs コマンドで、直接マウントポイントのログや情報が確認できるようになりました。

以前 （v1）

Mountpoint for S3 の動作状況やマウントに関する情報を確認するには、以下のステップが必要でした。

  • CSI ドライバが動作しているワーカーノードを確認、特定
  • そのノードに SSH ログインする。または CSI ドライバーの Pod に kubectl exec で入る
  • ノード上の特定のログファイルを直接確認する。または CSI ドライバーの Pod 内でログを探す

新しい方法 （v2）

単一の kubectl logs コマンドを実行するだけで、アプリケーション Pod がマウントしている S3 の情報を簡単に取得できます。

トラブルシューティングなど急いでいる際には焦るポイントでもあったため、原因究明が迅速かつ容易になりました。

kubectl logs <your-app-pod-name> -c <csi-sidecar-container-name>

まとめ

Mountpoint for Amazon S3 CSI ドライバー v1 から v2 へのアップデートでより使いやすくなったかと考えます。

EKS の永続ストレージとして S3 を採用している場合には、ぜひ v2 へのアップデートをご検討いただければと思います。

髙橋 省伍 (記事一覧)

2025年8月入社 エンタープライズクラウド部所属。2025 Japan AWS All Certifications Engineers。