免責事項
本記事は筆者個人の見解であり、所属組織の公式見解・開発体制・業務内容を示すものではありません。
記事内の技術的表現は、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-utilsv3.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）で差がある程度（メタデータキャッシュ効果）。
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 ファイルでも数分〜数十分かかります。
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 テンプレートとベンチマークスクリプトは社内で公開予定です。
参考リンク: