Amazon S3 Files が発表されました。What’s new によると “With S3 Files, Amazon S3 is the first and only cloud object store that provides fully-featured, high-performance file system access to your data.” (S3 Files によって Amazon S3 はデータに対してファイルシステムからアクセスできる最初で唯一のクラウドオブジェクトストアになった)とのことですが、AWS サービスには他にもファイルストレージがあります。この発表を機に他のファイルストレージとの違いを調べてみました。
Amazon S3 Files とは
製品ページには端的にどんなサービスか説明されています。
S3 Files is a shared file system that connects any AWS compute directly with your data in Amazon S3.
S3 に保存されているデータにファイルシステムからアクセスできるサービスのようです。こういった新規サービスで気になるものが出たとき自分は What’s new を見てそこからリンクされているページを読むようにしています。関連してそうなリンクをまとめておきます。
S3 Files の裏側
S3 Files は Amazon EFS を使っていて NFS v4.1 の操作をサポートしています。複数クライアントからファイルシステムにアクセスできます。Launch blog を読むと複数の AI Agent がファイルを読み書きしたり、機械学習パイプラインがデータを加工したりするワークロードで使われることを想定しているようです。
クライアントは EFS をマウントしてファイルシステムのプロトコルでデータをファイルとしてやり取りし、裏では S3 と REST API のプロトコルでデータをオブジェクトとしてやりとりする。言葉にすると簡単ですがファイルとオブジェクトだとプロトコルや機能が大きく変わりバランスを取るのが大変だったようです。例えばファイルシステムだと親ディレクトリや子ディレクトリを走査するのはよくあることで階層構造を活用することが多いですが、オブジェクトストレージにはファイルパスという概念がありません(保存されているオブジェクトはすべてフラットな構造で言ってしまえば巨大な key value store です。バケット名がグローバルで一意な必要性があるのはフラットな構造の現れで、オブジェクト名が /2026/04/10/09/log.txt だったとしてあくまで階層っぽい prefix がついているだけにすぎません)。他にもファイル操作だと rename は気軽にできそうですが、S3 は rename 操作をサポートしていないので旧名オブジェクトを削除して新名オブジェクトでアップロードすることになるといった違いがあります。
そういった大変なバランスをとりつつ S3 Files は S3 に保存したデータにファイルシステムからアクセスできるようになっています。コンポーネントとしては以下のように NFS でやりとりできるファイルとしての側面を提供する部分と、S3 に原子的な PUT 操作を行うオブジェクトとしての部分、そして両者を同期する部分の三つからなります。
A file view that provides full NFS close-to-open consistency. An object view that provides full S3 atomic-PUT strong consistency. And a synchronization layer that keeps them connected.
同期をリアルタイムに行うのはパフォーマンス的に厳しい(一行だけのログからなるファイルを毎回 S3 に PUT するとネットワークオーバーヘッドが支配的になりそうですし、巨大な何 GB もあるファイルが大量にあるバケットをマウントした時に全てダウンロードするとマウントがなかなか終わらない)ので、Git のようなバージョン管理システムから着想を得た ‘stage and commit’ という仕組みを使っています。Git での git add と git commit をイメージするとわかりやすくてファイルを新規作成や更新した場合加えられた変更は EFS 側でまとめられて大体 60 秒おきに S3 にアップロードされます。
パフォーマンスの工夫も色々されているようです。ファイルストレージの中にも Tier がありそうで、頻繁にアクセスされるデータは高速なストレージに保存されると書かれていますし、シーケンシャル読みこみでは NFS へのアクセスではなく S3 に対して並行で GET リクエストを送ってスループットを向上させる ‘read bypass’ が行われます。
複数クライアントからアクセスする場合は NFSの close-to-open 一貫性が提供されています。close-to-open 一貫性を初めて聞いたので調べたところ、大学の講義のページが見つかりました。クライアント 1 がファイルの内容を更新し close コマンドを使ってファイル X を閉じて、同じファイル X をクライアント 2 から open コマンドで開こうとするとクライアント 2 が更新された内容を見ることができるのが close-to-open 一貫性のようです。複数クライアントから S3 Files のファイルを読み書きするなら fnctl などの標準的なファイルロック機能が使えそうです。
また ファイルシステム側と S3 バケット側とで同時に変更して競合が起きた場合については特別なルールがあります。 この場合はS3側のデータが single source of truth として優先され、S3 Files のファイルシステム側で変更されたデータは lost+found ディレクトリに退避されます。ファイルシステム側から見るとコンフリクトを解消するときはマージ元を使う(git checkout --theirs )ということです。
まとめると S3 Files の裏側は以下の図のようになっています(NotebookLM に図を作ってもらいました)。
気になったところ
ドキュメントにファイルシステムから S3 バケットにアクセスするのに必要なポリシーが定義されています。“s3:ListBucket” とか “kms:Decrypt” は想像がつく(S3 バケットを列挙するのは必要そうだし、オブジェクトが KMS で暗号化されてるなら KMS 関連の操作は必要そう)んですが、“events:PutTargets” などの EventBridge 関連の権限も必要なのが意外でした。最初は EFS にファイルを投入するたびにイベントが発火して S3 と同期してるのかなと思ったんですが、リアルタイムに同期するのは大変だから EFS 側で変更をまとめて S3 にあげてるはずで何でなんだろうと。EFS のマウントポイントを作成したときにイベントが飛んで裏側で必要なリソースのセットアップが行われるってことなのかもしれないです。
他のファイルストレージとの違い
S3 Files が S3 をバックエンドにもつ EFS ってことはわかりました。この説明を読んで自分が最初に思ったのは Mountpoint for Amazon S3 と何が違うんだろうってことです。またそもそも EFS 単独だと不都合があるんだろうかとも思いました。ここからは他のファイルストレージと比較してみます。
Mountpoint for Amazon S3 との違い
Mountpoint for Amazon S3 は S3 バケットをローカルのファイルシステムにマウントできるファイルクライアントです。ファイル操作を S3 への API コールに変換しすることでファイルシステムからオブジェクトストレージにアクセスできます。
実は README に向いてないユースケースが書かれています。
but probably not the right fit for applications that: use file operations that S3 doesn’t natively support, like directory renaming or symlinks make edits to existing files
ファイル操作を S3 への API コールに変換しているのでそもそも S3 が対応していない操作は行えない(rename とか)ですし、既存のファイルへの変更も行えません。なのでファイルをそのまま読み込むとか、新規作成したファイルをそのまま保存するのが Mountpoint for Amazon S3 が想定しているワークロードです。一方で既存のファイルを直接編集や更新する場合は S3 Files が向いてそうです。
EFS との違い
S3 Files は何度も書いてきたように EFS を使っているわけですが EFS だと何が不都合なんでしょうか。
クライアントからファイルシステムに書き込む分には EFS でも良さそうですが、どちらかというとデータの保存先を EFS にする場合他のシステムとの連携はどうなるかを考えるのが良さそうです。
AWS を使っている場合データ置き場は S3 にするのが安牌なケースが多いです。これは S3 と連携できるサービスが数多く、後から処理を変えやすいからです。クライアントからファイルシステムにデータを書き込んで終わりということはなく、他のサービスからそのデータを読み込んだり更新したりするケースは多いでしょう。EFS にデータを保存していると他のサービスは EFS をマウントしないといけなくて選択肢が狭まります(例えば元になっているデータがリアルタイムデータなら Kinesis Streams から S3 に保存する、RDS のデータなら snapshot を S3 に保存することが多いですが、これらを EFS に保存しようと思ったら何らかのコンピュートリソースが必要になります)。
クライアントからファイルシステムに書き込むだけなら EFS でも問題ないが、データの利活用を考えると S3 に保存した方が色々と都合が良く、S3 Files が登場したというわけです。
FSx との違い
AWS のファイルシステムサービスには FSx ファミリーがありこれは NetApp ONTAP や Lustre といったファイルシステムのマネージドサービスです。これらと S3 Files は違うというよりも、これまでマネージドファイルストレージサービスに S3 をバックエンドとしてサポートする機能追加がされてきた流れの延長で、EFS に S3 をバックエンドとしてサポートする今回のアップデートが来たということなのかなと思っています。
FSx for Lustre はリリース当初から S3 とネイティブに統合されていたようで、FSx for NetApp ONTAP には S3 統合が 2025 年 12 月に追加されています。この流れで EFS に S3 統合が来たのが S3 Files なのかなと。
S3 の歴史で見ると単なるオブジェクトストレージから各ワークロード専用のインターフェース（Apache Iceberg サポートが組み込まれ大量の表形式データを保存できる S3 Tables や、ベクトルデータの保存とクエリをサポートする S3 Vectors など）を持つプラットフォームに進化してきていてその流れで今回の S3 Files ができたと言えるし、EFS というかファイルストレージの歴史で見ると FSx シリーズの S3 統合が来て EFS の S3 統合が来たという流れで見ています。
AWS ファイルストレージ比較表（性能・汎用性・互換性）
| サービス | 主な性格 | プロトコル | 性能・スループット | S3との親和性 | 主なユースケース |
|---|---|---|---|---|---|
| S3 Files | 汎用・S3連携 | NFS v4.1 | 中〜高 Read Bypassによる高速読込 |
最高 双方向の自動同期 |
AIエージェントの作業領域、MLパイプライン |
| EFS | 汎用・高可用性 | NFS v4.0/4.1 | 中 分散並列によりスケール |
低 基本は独立したFS |
Webサーバ共有、開発環境のホームディレクトリ |
| FSx for Lustre | 性能特化 | Lustre | 最高 数百GB/s、並列アクセス |
高 インポート/エクスポート |
HPC（スパコン）、大規模な機械学習トレーニング |
| FSx for ONTAP | 多機能・互換性 | NFS, SMB, iSCSI | 高 NetAppのキャッシュ技術 |
中 階層化ストレージとして使用 |
オンプレからの移行、複雑なデータ管理 |
おわりに
発表されてまだ新しいサービスなのでこれからユースケースや使い分けの知見が溜まってくると思います。料金ページを見ると S3 Files のハイパフォーマンスストレージ料金が結構高い(GB月あたり 0.36$で S3 バケットのスタンダード料金の 10 倍以上する)ので、このストレージ領域の使用を抑えられるといいのかなと思ってます。ハイパフォーマンスストレージ領域はずっと置いておくと高いが、S3 へコミットされた後は S3 料金になる（はず）ですし 30 日使われないとこの領域からは削除されるようなので、この領域は書き込みや読み込みのための一時的なバッファ領域と考えた方がいいのかもしれません。