免責事項
本記事は筆者個人の見解であり、所属組織の公式見解・開発体制・業務内容を示すものではありません。
記事内の技術的表現は、2026年3月時点の一般的な理解に基づくものであり、特定の製品・サービスの性能を保証するものではありません。

はじめに

こんにちは！Dirbatoの社内技術横断支援組織Backbeatに所属している柴田です！

2026年4月、AWS から Amazon S3 Files というアップデートが発表されました。

S3 バケットを NFS v4.2 でマウントし、標準的なファイル操作で S3 オブジェクトにアクセス可能。EC2 / Lambda / EKS / ECS に対応。

公式ドキュメント: Working with Amazon S3 Files

本記事は、Classmethodさんの検証記事を参考にさせていただき、そこでカバーされていなかった CloudFormation 対応、Lambda マウント、S3→FS 方向の同期計測、EFS との同一条件ベンチマーク、同時書き込み競合、アクセスポイントによるマルチテナント分離を追加検証した内容です。クラスメソッドさんの記事で基礎的な動作確認が丁寧にまとめられていたおかげで、深掘り検証に集中できました。ありがとうございます。

正直、最初は「EFS の S3 版でしょ？」と思っていました。

全然違いました。

実際に 7 項目を検証したところ、S3 Files は 「ファイルシステムの代替」ではなく「S3 にファイルシステムインターフェースを追加するサービス」 だと分かりました。

本記事では、検証で得られた実測データと、既存ファイル共有サービスとの比較をまとめます。

こんな人に読んでほしい

S3 のデータをファイルシステムとして扱いたいが、EFS への移行コストが気になる人
Lambda / ECS から共有ファイルストレージを使いたい人
EFS と S3 Files のどちらを選ぶべきか迷っている人
CloudFormation で S3 Files を IaC 管理したい人

要点サマリー

忙しい方向けに先に結論を。

検証項目	一言結果
CloudFormation 対応	`AWS::S3Files::` 4リソースタイプで完全 IaC 管理可能*
Lambda マウント	正常動作。書き込み 25ms、読み取り 4ms
S3→FS 同期レイテンシ	約28秒で安定。ドキュメントの「数秒」より遅い
EFS 比較	書き込みは S3 Files が +28% 高速、メタデータ操作は EFS が +37% 高速
同時書き込み競合	S3 が source of truth。FS側の変更は lost+found に退避
マルチテナント分離	アクセスポイントで正しく機能

最大の発見: S3 Files は「EFS の代替」ではなく、「S3 にファイルシステムの皮をかぶせるサービス」。既に S3 にデータがあるケースで最も価値を発揮する。

1. Amazon S3 Files とは — 2層構造のアーキテクチャ

全体構成

S3 Files は「高性能ストレージ層」と「S3 バケット」の 2 層構造で、AWS が自動的にデータの配置と読み取り経路を最適化します。利用者は NFS マウントポイントに対して通常のファイル操作を行うだけ。

┌──────────────────────────────────────────────────────────┐
│                      S3 Files                            │
│                                                          │
│  ┌─────────────────────────┐    ┌─────────────────────┐  │
│  │   高性能ストレージ層     │◄──►│    S3 バケット       │  │
│  │   (低レイテンシ)        │自動 │  (source of truth)  │  │
│  │                         │同期 │                     │  │
│  │ ・小ファイル (< 128KB)   │    │ ・大ファイル (≥128KB)│  │
│  │ ・メタデータ             │    │ ・全データの永続保存  │  │
│  │ ・最近の書き込みデータ   │    │ ・11 9's の耐久性    │  │
│  │ ・未アクセス30日で自動削除│    │                     │  │
│  └──────────▲──────────────┘    └──────────▲──────────┘  │
│             │                              │             │
└─────────────┼──────────────────────────────┼─────────────┘
              │                              │
       小ファイル読み書き              大ファイル読み取り
       全ての書き込み                 (S3から直接配信)
              │                              │
       ┌──────┴──────────────────────────────┴───────┐
       │          Lambda / EC2 / ECS / EKS           │
       │          (NFSマウント: /mnt/s3files)         │
       └─────────────────────────────────────────────┘

ポイントは ファイルサイズによって読み取り経路が自動で切り替わる こと。

ケース	経路	狙い
小ファイル（< 128KB）	コンピュート → 高性能層	低レイテンシ（サブms〜数ms）
大ファイル（≥ 128KB）で S3 同期済み	コンピュート → S3 から直接配信	高スループット（TB/s 級）
書き込み直後で未同期のデータ	コンピュート → 高性能層	S3 にまだ反映されていないため

128KB — 「低レイテンシ」と「高スループット」の境界

この 128KB という閾値（設定変更可能）、最初は「128KB って小さくない？メタデータくらいしか入らないのでは？」と思いました。

でも実は 128KB 以下のファイルは結構多い んです。

カテゴリ	具体例	典型サイズ
設定ファイル	JSON/YAML設定、.env、マニフェスト	1〜30 KB
コード・スクリプト	Python/Shell、Lambda 内の個別ファイル	5〜100 KB
ML 関連	ハイパーパラメータ、特徴量定義、推論結果JSON	1〜50 KB
IoT / センサー	1デバイス1分間のセンサーデータ (JSON/CSV)	1〜20 KB
小画像	サムネイル、アイコン、QRコード	5〜100 KB

そして 128KB 以上の大きなファイルは S3 から直接配信 されます。

カテゴリ	具体例	典型サイズ
データ分析	Parquet/CSV データセット	数MB〜数GB
ML モデル	学習済みモデル、重みファイル	数百MB〜数GB
メディア	動画、高解像度画像、音声	数MB〜数十GB
ログ集約	圧縮済みアクセスログ、監査ログ	数MB〜数百MB

なぜ大ファイルは S3 直接のほうが速いのか

ここが S3 Files の設計の核心です。

【高性能層経由】
  コンピュート → NFS → 高性能層（単一ファイルサーバ）→ データ
                            ↑ 単一ノードがボトルネック

【S3 直接配信】
  コンピュート → S3（内部で多数のストレージノードが並列配信）→ データ
                      ↑ 分散ストレージによる並列ストリーミング → TB/s 級

S3 は内部的にデータを多数のノードに分散保存していて、大きなファイルを並列にストリーミング配信できます。単一のファイルサーバを経由するより圧倒的に速い。これが TB/s 級スループットの源泉です。

つまり S3 Files は 「小さい荷物は近くの倉庫から、大きい荷物は大型トラックで」という配送の最適化 を自動でやってくれるサービスなんです。

書き込み時のデータフロー

コンピュートが /mnt/s3files/data.txt に write
       │
       ▼
  高性能層に即座に書き込み（本検証の Lambda 実測: 25ms）
       │
       ▼  約60秒後、AWS が自動でバッチ同期
  S3 バケットに PUT（利用者は意識不要）

60秒間の連続した変更は 1 回の S3 PUT にまとめられ、リクエストコストが最適化されます。

S3 Intelligent-Tiering との比較

「Intelligent-Tiering みたいなもの？」と思う方もいると思います。考え方は似ていますが、制御の粒度と方向が違います。

観点	S3 Intelligent-Tiering	S3 Files の高性能層
何を自動化するか	S3 ストレージクラスの切替	ファイルシステム ↔ S3 間のデータ配置
判断基準	アクセス頻度（30/90/180日）	アクセス有無（デフォルト30日で高性能層から自動削除）
利用者の意識	完全に透過的	ほぼ透過的だが同期遅延は設計上考慮が必要
データの流れ	S3 内で階層間を一方向的に移動	FS ↔ S3 で双方向同期

Intelligent-Tiering = 「S3 の中で」コスト最適化を自動でやってくれる
S3 Files = 「S3 とファイルシステムの間で」データ配置を自動でやってくれる

2. 検証環境

項目	値
リージョン	ap-northeast-1（東京）
EC2 インスタンスタイプ	t3.medium × 2台（Writer/Reader）
OS	Amazon Linux 2023
amazon-efs-utils	v3.0.0（dnf リポジトリ版）
構築方法	CloudFormation テンプレートで一括作成

CloudFormation で S3バケット、S3 Files ファイルシステム + マウントターゲット + アクセスポイント×2、EFS（比較用）、EC2 × 2台を一括作成しています。Lambda は CFn とは別に CLI で作成しました。

3. 検証結果

3-1. CloudFormation による環境構築 — 完全 IaC 対応

結果: 成功

Classmethod 記事では CLI 手動構築でしたが、S3 Files は AWS::S3Files::FileSystem、MountTarget、AccessPoint すべて CFn に対応 していました。

確認項目	結果
CFn での S3 Files リソース作成	`AWS::S3Files::*` 4リソースタイプすべて対応
`amazon-efs-utils` v3.0.0	dnf でプレビルド版インストール可能（ソースビルド不要）
NFS マウント	`mount -t s3files fs-xxx:/ /mnt/s3files` で成功
POSIX 操作	write/read/chmod/stat/mv すべて正常動作

127.0.0.1:/ on /mnt/s3files type nfs4
  (rw,vers=4.2,rsize=1048576,wsize=1048576,hard,noresvport,timeo=600,retrans=2)

発見: amazon-efs-utils v3.0.0 は AL2023 の標準 dnf リポジトリに x86_64 プレビルド版が収録済み。Classmethod 記事ではソースからの Rust ビルドが必要とされていましたが、dnf install amazon-efs-utils-3.0.0 で即時インストールできました。

3-2. Lambda マウント — EC2 以外からも正常動作

結果: 成功

Lambda の FileSystemConfigs に S3 Files アクセスポイント ARN を指定してマウント成功。

指標	1回目（コールド）	2〜5回目（ウォーム平均）
書き込み	25.13 ms	25.96 ms
読み取り	3.49 ms	4.69 ms
ディレクトリリスト	8.28 ms	1.11 ms

コールドスタートとウォームスタートで書き込み/読み取りの差はほぼありません。ディレクトリリストのみ初回（8ms）と 2 回目以降（1ms）で差がある程度（メタデータキャッシュ効果）。

注意: Lambda の IAM ロールには s3files:ClientMount / s3files:ClientWrite が必要です。elasticfilesystem:* ではないので注意。

3-3. S3→FS 同期レイテンシ — ドキュメントの「数秒」より遅い

結果: 約28秒で安定

S3 API (aws s3 cp) でオブジェクトを PUT し、マウントポイントでファイルが出現するまでの時間を計測しました。

ファイルサイズ	反復	Min	P50	P95	Max
1KB	10回	26,457 ms	28,219 ms	28,255 ms	28,265 ms
100KB	10回	28,152 ms	28,247 ms	28,260 ms	28,269 ms

ファイルサイズによる差はほぼなし。メタデータ同期が律速です。

ドキュメントの”typically within seconds”とは差がありますが、EventBridge 経由の通知ポーリング間隔が影響している可能性があります。Classmethodさんの検証記事の FS→S3 方向（66秒）と合わせると、双方向で30秒〜70秒程度の同期遅延があると考えておいたほうがよさそうです。

3-4. 同時書き込み競合 — S3 が勝つ、FS 側は lost+found へ

結果: S3 が source of truth

FS と S3 API から同一ファイルに同時書き込みした結果がこちら。

テスト	FS側の内容	S3側の内容	lost+found
S3→FS 順	`from-filesystem`	`from-s3-api`	なし
ほぼ同時	`from-s3-simul`	`from-s3-simul`	`from-fs-simul`（退避）

ほぼ同時に書き込むと、S3 が勝ち、FS 側も S3 の内容に上書きされます。FS 側のオリジナル変更は .s3files-lost+found-fs-xxx/ ディレクトリに退避されました。

競合時の振る舞いはドキュメント通り。運用上、同一ファイルへの FS/S3 同時書き込みは避けるべき です。

3-5. EFS 比較 — 書き込みは S3 Files 優位、メタデータは EFS 優位

結果: 全体的にほぼ同等

同一 EC2（t3.medium）、同一ワークロードで計測しました。

ワークロード	S3 Files	EFS	差分
小ファイル作成（1KB×1000）	11,403 ms	11,176 ms	ほぼ同等
100MB 書き込み	354 ms（282.5 MB/s）	451 ms（221.7 MB/s）	S3 Files +28%
100MB 読み取り（コールド）	253 ms（395.3 MB/s）	256 ms（390.6 MB/s）	同等
100MB 読み取り（ウォーム）	24 ms（4.2 GB/s）	24 ms（4.2 GB/s）	同等
メタデータ操作（ls 1000）	111 ms	70 ms	EFS +37%
ランダム読み取り（100回）	582 ms	420 ms	EFS +28%

大きなファイルの書き込みは S3 Files が優位（高性能ストレージ層のバッファリング効果）、メタデータ操作・ランダム読み取りは EFS が優位（S3 メタデータ変換のオーバーヘッド）。

パフォーマンスだけで見ると「ほぼ互角」ですが、コスト構造が全く違う。これについてはセクション 4 で詳しく比較します。

3-6. 大量ファイル操作 — FS 上は瞬時、S3 側は要注意

操作	結果
1000 ファイル作成	12,142 ms（約 82 files/s）
FS→S3 同期	90秒後に S3 上で 1001 オブジェクト確認
FS 上ディレクトリリネーム	13 ms（瞬時）
S3 側リネーム同期	5分経過時点で未完了

FS 上のリネームは 13ms で完了しますが、S3 側では全オブジェクトを新キーで PUT + 旧キー DELETE する必要があり、1000 ファイルでも数分〜数十分かかります。

注意: 大量ファイルのディレクトリリネーム / 移動は S3 リクエストコスト（PUT + DELETE × ファイル数） に要注意。

3-7. アクセスポイントによるマルチテナント分離

結果: 正しく機能

確認項目	結果
テナントA（uid=1001）でマウント	成功。`/tenant-a` がルートとして見える
テナントB からテナントA のファイルアクセス	不可（`/tenant-a` 自体が見えない）
通常マウントでの全体表示	両テナントのファイルが見える

ハマりポイント: アクセスポイント経由でマウントする場合、ルートディレクトリが事前に存在する必要がある。存在しないと access denied エラーになります。

4. AWS ファイル共有サービスとの比較

S3 Files の位置づけを明確にするため、既存サービスと多角的に比較しました。

4-1. サービス概要比較

項目	S3 Files	Amazon EFS	FSx for Lustre	FSx for Windows	FSx for ONTAP	FSx for OpenZFS
プロトコル	NFS v4.1/4.2	NFS v4.0/4.1	Lustre (POSIX)	SMB 2.0〜3.1.1	NFS/SMB/iSCSI/NVMe	NFS v3/4.0/4.1/4.2
バックエンド	S3	専用ストレージ	SSD/HDD	SSD/HDD	SSD + 容量プール	SSD
最大スループット	読取: TB/s級	〜10 GiB/s	数百 GB/s	〜12 GB/s	数十 GiB/s	〜12.5 GiB/s
最大IOPS	読取: 250K	〜250K	数百万	〜400K	数百万	〜1M
容量スケーリング	実質無制限（S3）	自動（無制限）	プロビジョン	プロビジョン	プロビジョン+自動階層化	プロビジョン

出典: AWS ストレージサービスの選択ガイド、各サービス公式ドキュメント

4-2. コスト構造の違い — ここが最大の差

項目	S3 Files	Amazon EFS	FSx for Lustre
課金モデル	S3ストレージ + 高性能層（アクティブ分のみ）	使用量課金（全データ）	プロビジョン容量
ストレージ単価	S3 Standard: $0.025/GB + 高性能層	Standard: $0.36/GB	SSD: $0.17/GB

S3 Files のコスト優位性:

100TB のデータセットのうちアクティブに使用するのが 5TB の場合:

EFS: 100TB 全体に課金 → 約 $36,000/月
S3 Files: S3 Standard 100TB（$2,500/月）+ 高性能層 5TB 分のみ → 大幅削減

さらに大きなファイルの読み取りは S3 から直接配信されるため、ファイルシステムアクセス料が発生しません。

4-3. ユースケース別推奨サービス

ユースケース	推奨	理由
既存 S3 データへのファイルアクセス追加	S3 Files	データ移行不要、即座に NFS マウント
アクティブデータ ≪ 全体データ量	S3 Files	アクティブ分のみ課金で大幅コスト削減
ETL / データレイク連携	S3 Files	S3 API + NFS の双方向同期
汎用 Linux ファイル共有	EFS	メタデータ操作 +37% 高速、同期遅延なし
HPC / 機械学習	FSx for Lustre	数百 GB/s、数百万 IOPS
Windows AD 連携	FSx for Windows	SMB ネイティブ、AD 統合
マルチプロトコル	FSx for ONTAP	NFS + SMB + iSCSI + NVMe
リアルタイム同期が必須	EFS / FSx 各種	S3 Files は同期遅延あり

5. Classmethod 記事との比較 — 追加で分かったこと

Classmethod さんの記事を参考に検証を開始しましたが、追加で分かったことが多くありました。

観点	Classmethod	本検証の追加知見
構築	CLI 手動	CFn 完全対応（`AWS::S3Files::*` 4リソースタイプ）
efs-utils	ソースビルド必須	dnf でプレビルド版インストール可能
コンピュート	EC2 のみ	Lambda からも正常動作（write 25ms / read 4ms）
S3→FS 同期	未計測	約28秒（ドキュメントの”typically within seconds”より遅い）
競合	未検証	S3 が source of truth、FS 変更は lost+found へ退避
EFS 比較	なし	書き込み +28% 優位 / メタデータ操作 +37%
大量ファイル	100MB 単一	FS リネーム 13ms（即時）だが S3 同期は数分以上
アクセスポイント	未検証	マルチテナント分離が正しく機能

6. S3 Files の本質 — 「ファイルシステムの代替」ではない

検証を通じて、S3 Files は従来のファイルシステムサービスとは設計思想が根本的に違うと感じました。

観点	従来の FS（EFS / FSx）	S3 Files
データの所在	ファイルシステムが一次データ	S3 が一次データ（source of truth）
設計アプローチ	FS を作り、データを入れる	既存の S3 データに FS インターフェースを追加
容量管理	自動スケーリング or プロビジョン	S3 に依存（実質無制限）
コスト最適化	ストレージクラス・ライフサイクル	アクティブデータのみ高性能層課金
アクセス方法	NFS / SMB のみ	NFS + S3 API（双方向同期）
整合性モデル	即時整合	結果整合（同期遅延あり）

実際のシステムで言うと、こんなイメージです。

ML パイプラインの例:

  1. config.json (5KB) を読む
     → 高性能層から 3ms で取得【低レイテンシ】

  2. train.parquet (2GB) を読む
     → S3 から直接ストリーミングで数秒【高スループット】

  3. result.json (10KB) を書く
     → 高性能層に 25ms で書き込み【低レイテンシ】

  4. model.bin (500MB) を保存
     → 高性能層に書き込み → 60秒後に S3 へ自動同期

  ※ 全て /mnt/s3files/ への通常のファイル操作。
  ※ AWS が裏で最適な経路を自動選択。

7. 所感

「S3 にファイルシステムの皮をかぶせる」が正しい理解

最初は「EFS の S3 版」と思っていましたが、検証してみると全く違うサービスでした。S3 Files は S3 のデータをそのままに、ファイルシステムのインターフェースを追加する サービスです。

これは「S3 → EFS への移行」ではなく、「S3 のまま、NFS でもアクセスできるようにする」 という発想。既に S3 にデータがある環境では、移行コストゼロで NFS マウントを追加できます。

同期遅延は「仕様」として設計に組み込むべき

S3→FS 約28秒、FS→S3 約60秒。リアルタイム同期を期待すると裏切られます。

ただし、ETL パイプライン（S3 API で書き込み → 数十秒後にアプリが NFS で読む）のような構成では十分実用的です。「同期遅延を前提とした設計」が S3 Files を活かすコツ だと感じました。

CloudFormation 完全対応は大きい

検証環境を CloudFormation で完全に IaC 管理できたのは、研修教材や PoC の再現性確保の面で非常に助かりました。AWS::S3Files::FileSystem、MountTarget、AccessPoint すべて CFn 対応済みです。

EFS とは「どちらが上か」ではなく「使い分け」

パフォーマンスはほぼ互角。差が出るのは コスト構造 と 同期モデル です。

アクティブデータが全体の一部 → S3 Files（コスト優位）
リアルタイム整合性が必要 → EFS（同期遅延なし）
メタデータ操作が頻繁 → EFS（+37% 高速）
S3 API とのデュアルアクセスが必要 → S3 Files（双方向同期）

おわりに

S3 Files は「ファイルシステムの代替」ではなく、「S3 にファイルシステムインターフェースを追加するサービス」 です。

特に以下に当てはまる方は、検証してみる価値があると思います:

S3 にデータがあるが、アプリが NFS パスでしか読めない
EFS を使っているが、アクティブデータが全体の一部でコストが気になる
ETL パイプラインで S3 API と NFS の両方からアクセスしたい
Lambda / ECS から共有ファイルストレージを低コストで使いたい

本記事の CloudFormation テンプレートとベンチマークスクリプトは社内で公開予定です。

参考リンク: