はじめに

こんばんは、mirukyです。

2026年4月7日、AWSは Amazon S3 Files を一般提供（GA）開始しました。S3バケットをNFS v4.1ファイルシステムとしてマウントし、EC2やECS、EKS、Lambdaなどのコンピュートリソースからファイル操作で直接アクセスできる新機能です。

これまでS3のデータをファイルとして扱うには、別途EFSやFSxを立てて同期するか、Mountpoint for S3で読み取り主体のアクセスに限定するか、いずれかのトレードオフを受け入れる必要がありました。S3 Filesはこのトレードオフを解消し、 オブジェクトストレージとファイルシステムを1つのバケットに統合 します。

この記事では、S3 Filesの仕組み、セットアップ手順、既存サービスとの違い、そして注意点をコンパクトにまとめます。

1. S3 Filesとは

S3 Filesは、S3バケットの中身をそのままNFSファイルシステムとして公開する機能です。AWSの公式ブログでは以下のように表現されています。

"With S3 Files, Amazon S3 is the first and only cloud object store that offers fully-featured, high-performance file system access to your data."
（S3 Filesにより、Amazon S3はフル機能の高パフォーマンスなファイルシステムアクセスを提供する、最初にして唯一のクラウドオブジェクトストアとなった）

1-1. 基本スペック

項目	内容
発表日	2026年4月7日
提供状態	一般提供（GA）
対応リージョン	全商用リージョン
プロトコル	NFS v4.1+
対応コンピュート	EC2、ECS、EKS、Fargate、Lambda
同時接続	最大 25,000 コンピュートリソース
読み取りスループット	4TB/s超（集約）
ファイルシステムIOPS	1,000万超 /バケット
アクティブデータのレイテンシ	約 1ms

1-2. 何が変わるのか

S3 Filesの登場前、S3のデータをファイルとして扱うには以下のいずれかが必要でした。

データのコピー ：S3からEFSやローカルストレージへデータを複製し、処理後に書き戻す
パイプラインの構築 ：S3とファイルシステム間の同期を自前で管理する
Mountpoint for S3の利用 ：読み取り主体のワークロードに限定して、S3をFUSEマウントする

S3 Filesでは、これらのいずれも不要になります。マウントした瞬間からS3バケット内のオブジェクトがファイルとして見え、ファイルへの書き込みは自動的にS3オブジェクトとして同期されます。AWSは 最大90%のコスト削減 が可能と試算しています（データのコピーや二重管理が不要になるため）。

2. アーキテクチャと仕組み

2-1. 内部構造

S3 Filesの実体は Amazon EFSの技術基盤 の上に構築されています。AWS公式ブログによれば、S3 Filesは以下のように動作します。

ファイルシステム経由でアクセスされたデータのメタデータとコンテンツを、高パフォーマンスストレージに遅延ロードする
設定したファイルサイズの閾値を下回るデータは、S3から直接読み取る（高パフォーマンスストレージを経由しない）
書き込みは高パフォーマンスストレージに保存され、その後S3バケットに自動同期される
設定した期間（1〜365日、デフォルト30日）アクセスのないデータは高パフォーマンスストレージから自動的に削除される

つまり、よく使うデータはキャッシュ的に高速ストレージ上に保持し、使わないデータはS3のみに保管するという 自動階層化 の仕組みです。

2-2. 整合性モデル

S3 Filesは NFS close-to-open整合性 を採用しています。ファイルをクローズした時点で変更がコミットされ、他のクライアントがオープンした時点で最新の状態が見える仕組みです。

ファイルシステム → S3への反映：書き込み後 数分以内
S3 → ファイルシステムへの反映：変更後 数秒〜数分

2-3. セキュリティ

項目	内容
転送中の暗号化	TLS 1.3
保管時の暗号化	SSE-S3 または AWS KMS（カスタマーマネージドキー）
アクセス制御	IAMポリシー + POSIXパーミッション（UID/GID）
監視	CloudWatchメトリクス + CloudTrail

ファイルレベルのパーミッションにはPOSIX（UID/GID）が使用され、S3バケット内のオブジェクトメタデータとして保存されます。

3. セットアップ手順

EC2インスタンスからS3バケットをマウントする手順を解説します。コンソールとCLIの両方を示します。

3-1. 前提条件

汎用（General Purpose）S3バケットが存在すること
S3バケットにバージョニングが適用されていること
EC2インスタンスがバケットと同じリージョン・VPCにあること
EC2インスタンスに最新の amazon-efs-utils パッケージがインストールされていること（AWS提供AMIにはプリインストール済み）

S3バージョニングが適用されていないS3汎用バケットを選択した場合、下記のようなエラー文が出ます。

もし適用していない場合は、汎用バケット→対象バケットクリック→プロパティタブから「バケットのバージョニング」を有効にしましょう。
（エラー文の「バケットのバージョニングを有効にする」からでも有効にできます）

3-2. コンソールからの手順

【Step 1：ファイルシステムを作成する】

S3コンソールの左メニューから ファイルシステム を選択し、 ファイルシステムを作成 をクリックします。対象のバケット名を入力して「ファイルシステムを作成」をクリックします。

このような青いポップアップが表示されます。

【Step 2：マウントターゲットを確認する】

作成されたファイルシステムの マウントターゲット タブを開きます。VPC内に自動的にマウントターゲットが作成されています。マウントターゲットIDをメモしておきます。

【Step 3：EC2からマウントする】

EC2インスタンスにSSHで接続し、以下を実行します。

# マウントポイントを作成
sudo mkdir /home/ec2-user/s3files

# S3ファイルシステムをマウント（fs-xxxは自分のファイルシステムID）
sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files

3-3. CLIからの手順

AWS公式ブログによれば、CLIでは create-file-system でファイルシステムを作成し、 create-mount-target でマウントターゲットを作成します。

# Step 1: ファイルシステムを作成
aws s3api create-file-system --bucket my-bucket-name

# Step 2: マウントターゲットを作成
aws s3api create-mount-target \
  --file-system-id fs-0aa860d05df9afdfe \
  --subnet-id subnet-xxxxxxxx \
  --security-groups sg-xxxxxxxx

# Step 3: EC2からマウント
sudo mkdir /home/ec2-user/s3files
sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files

CLIのサブコマンド名は公式ブログの記述に基づいています。正確なコマンド構文は S3 Files Documentation を参照してください。

3-4. 動作確認

# ファイルシステム上でファイルを作成
echo "Hello S3 Files" > s3files/hello.txt

# ファイルが存在することを確認
ls -al s3files/hello.txt
# -rw-r--r--. 1 ec2-user ec2-user 15 Oct 22 13:03 s3files/hello.txt

# S3側にも反映されていることを確認
aws s3 ls s3://my-bucket-name/hello.txt
# 2025-10-22 13:04:04 15 hello.txt

# S3から取得しても同じ内容
aws s3 cp s3://my-bucket-name/hello.txt -
# Hello S3 Files

ファイルシステムへの書き込みが数分以内にS3オブジェクトとして反映されます。逆に、S3 APIで直接アップロードしたオブジェクトも数秒〜数分程度でファイルシステム側に反映されます。

EC2、ECS、EKSだけでなく、FargateやLambdaからもマウント可能です。コンテナワークロードでの利用も想定されています。

4. Mountpoint for S3との違い

S3をファイルシステムとして使う手段として、既存の Mountpoint for Amazon S3 があります。両者は位置づけが異なります。

比較項目	S3 Files	Mountpoint for S3
プロトコル	NFS v4.1+	FUSE
読み取り	対応	対応
書き込み	対応（新規・上書き・追記）	限定的（新規作成・追記のみ）
既存ファイルの編集	対応	非対応
同時共有アクセス	最大25,000	単一インスタンス推奨
整合性	NFS close-to-open	結果整合性
POSIXパーミッション	対応	非対応
レイテンシ	~1ms（キャッシュ済み）	S3 APIレイテンシ依存
追加コスト	ファイルシステムストレージ + オペレーション	なし（S3リクエスト料金のみ）
用途	共有ワークロード、書き込み多用	読み取り主体、大規模シーケンシャル

Mountpoint for S3は「S3をできるだけそのまま低コストでマウントしたい」場合に適しています。一方、S3 Filesは「複数のコンピュートリソースで共有しながら読み書きする」対話的なワークロードに適しています。

S3 Filesはファイルシステムの高パフォーマンスストレージにキャッシュされたデータ分の追加コストが発生します。Mountpoint for S3には追加のストレージ料金がありません。ワークロードの特性に応じて選択してください。

Amazon FSxとの違いも整理しておきます。

比較項目	S3 Files	Amazon FSx
データの保管先	S3バケット（本体）	FSx独自のストレージ
データの移行	不要（既存バケットをそのまま利用）	必要
プロトコル	NFS	Lustre / ONTAP / ZFS / SMB
主な用途	S3データへのファイルアクセス	オンプレNAS移行、HPC

既存のS3データをファイルシステムでアクセスしたいなら S3 Files 、オンプレミスからの移行やLustreが必要なHPCワークロードなら FSx という棲み分けです。

5. ユースケースと注意点

5-1. 想定ユースケース

【AIエージェントの共有ワークスペース】

複数のAIエージェントがS3上のデータを共有ワークスペースとして利用できます。エージェント間でファイルベースの中間結果やステートを受け渡す場面で、データコピーなしに標準的なファイル操作が使えます。

【ML学習パイプラインのデータ準備】

S3に蓄積されたTB〜PB規模のデータセットを、ファイルシステムとしてマウントしたままデータ準備やクレンジングを実行できます。従来は「S3からダウンロード → 加工 → S3へアップロード」だった工程が不要になります。

【レガシーアプリケーションのクラウド移行】

ファイルパスを前提とするレガシーアプリケーションを、コード変更なしでS3上のデータに接続できます。

5-2. 注意点

高パフォーマンスストレージの料金 ：アクティブに使用されるデータはEFSベースの高パフォーマンスストレージに保持されるため、S3標準料金に加えてファイルシステムストレージ料金が発生します。データの有効期限（1〜365日、デフォルト30日）を適切に設定してコストを管理してください
同期のタイムラグ ：ファイルシステムからS3への反映は数分、S3からファイルシステムへの反映は数秒〜数分です。リアルタイム同期が必要な場合は注意が必要です
汎用バケット限定 ：S3 Filesは汎用（General Purpose）バケットでのみ利用可能です。ディレクトリバケット（S3 Express One Zone）には対応していません
NFS v4.1+ ：NFS v3以前のクライアントでは接続できません。EC2のAMIに含まれるamazon-efs-utilsは最新版にアップデートしてください

料金体系はS3料金ページに記載されていますが、ファイルシステムストレージ料金、小ファイル読み取り操作料金、書き込み操作料金、S3同期リクエスト料金の4要素で構成されます。利用前にAWS料金見積りツールでコストを確認することを推奨します。

おわりに

ここまでお読みいただきありがとうございます。

S3 Filesは、長年のAWSストレージにおける「オブジェクトストレージかファイルシステムか」というトレードオフを解消する機能です。S3バケットをそのままNFSマウントでき、データコピーや同期パイプラインの構築が不要になります。1msレイテンシ、4TB/s超の読み取りスループット、25,000同時接続というスペックで、AIエージェントの共有ワークスペースやMLパイプラインを含む幅広いワークロードをカバーします。一方で、高パフォーマンスストレージの追加コストや同期のタイムラグなど、導入前に理解しておくべきポイントもあります。ワークロードの特性に合わせて、Mountpoint for S3やFSxとの使い分けを検討してください。

ではまた、お会いしましょう。