AWSでストレージを選ぶとき、
という判断は設計の定番の悩みのひとつではないでしょうか。
S3はコスト効率が高くデータレイクとして使いやすい一方、ファイルシステムアクセスが必要なアプリケーションからは直接触りにくい。
そのため「S3のデータをEFSにコピーして処理する」という二重管理が発生しがちでしたよね。
そこで2026年4月に登場したのが Amazon S3 Files です。
このサービスはS3上のデータを、コード変更なしにファイルシステムとしてマウントして扱えるようにしてくれます。
待ってました！
という方も多いのではないでしょうか？
この記事では、EFS・EBS・FSxなど他のAWSストレージサービスと何が違うのかを軸に解説していきますので、ストレージ選択の参考にしてみてくださいね。
AWSのストレージサービス、まず整理しておく
S3 Filesの話をする前に、AWSの主要ストレージサービスを一覧で整理しておきます。
| サービス | ストレージ種別 | アクセス方法 | 主な用途 |
|---|---|---|---|
| Amazon S3 | オブジェクトストレージ | REST API / SDK | データレイク・バックアップ・静的コンテンツ |
| Amazon EBS | ブロックストレージ | ブロックデバイス（単一EC2に接続） | EC2のOSディスク・高速I/Oが必要なDB |
| Amazon EFS | ネットワークファイルシステム（NFS） | POSIX互換マウント（複数インスタンスから） | 複数EC2・コンテナ間でのファイル共有 |
| Amazon FSx for Lustre | 高性能分散ファイルシステム | POSIX互換マウント | HPC・機械学習の学習ジョブ |
| Amazon FSx for Windows | Windowsファイルサーバー | SMBプロトコル | Windows環境の共有フォルダ代替 |
| Amazon S3 Files（新） | オブジェクトストレージ（ファイルシステムアクセス付き） | POSIX互換マウント | S3データへのファイルシステムアクセス |
これまでの構図では、「データをどこに置くか」と「どうアクセスするか」がセットで決まっていました。
という棲み分けです。
S3 Filesはその境界を崩すサービスと言えるでしょう。
Amazon S3 Filesとは何か
Amazon S3 Filesは、S3バケット上のデータをPOSIX互換のファイルシステムとしてマウントできるサービスです。
Amazon EFSを基盤として構築されており、EC2インスタンスやコンテナから通常のファイルのようにS3のデータを読み書きできます。
最大の特徴はデータの複製が不要なことです。
これまで「ファイルシステムアクセスが必要だからS3のデータをEFSにコピーして……」という作業が必要だったところが、S3のデータをそのままマウントして使えるようになりました。
「同一ファイルシステムに何千ものコンピューティングリソースが同時に接続できる」と発表されており、集約読み取りスループットは最大数TB/秒に達します。
また、既存のコードを変更しなくてよいのも嬉しいですよね。
ファイルパスを指定して読み書きするアプリケーションがそのまま動く、つまりS3を意識させずにファイルシステムとして透過的に使うことが可能です。
他のストレージサービスと何が違うのか
S3 vs S3 Files
従来のS3はREST API（PutObject / GetObject）やSDK経由でアクセスするオブジェクトストレージです。
ファイルパスで直接触ることはできず、アプリケーション側がS3用のコードを持つ必要がありました。
S3 Filesはそのデータをファイルシステムとしてマウントするレイヤーを追加したイメージで、S3のコスト効率とスケールを活かしたまま、ファイルシステムアクセスを得られるのが大きな違いです。
EFS vs S3 Files
EFSも複数のEC2やコンテナから同時にマウントできるNFSファイルシステムです。
EFSとS3 Filesの最大の違いはデータの置き場所です。
EFSはEFS独自のストレージにデータが保存されますが、S3 Filesはデータの実体がS3バケットに存在します。
すでにS3にデータがある場合、EFSには一度コピーが必要でした。
S3 Filesならそのコピーが不要になります。
逆に言えば、データがS3にない場合や、EFSの高度な機能（ライフサイクル管理・レプリケーションなど）を使いたい場合はEFSが引き続き適した選択肢になるでしょう。
FSx for Lustre vs S3 Files
FSx for LustreはS3との連携機能（データリポジトリ）を持っており、機械学習の学習ジョブなどでS3のデータをLustreファイルシステムにロードして高速処理するのに活用されています。
ただし、Lustreへのデータロード（インポート）やS3への書き戻し（エクスポート）という同期ステップが必要なのが手間でした。
S3 Filesはデータ同期なしにS3を直接ファイルシステムとして扱える点でシンプルですが、FSx for LustreはHPCや超高速I/Oが求められる用途に特化した専用ファイルシステムです。
極限のスループットが必要な場面ではFSx for Lustreが依然として選択肢になりますね。
EBS vs S3 Files
EBSは単一のEC2インスタンスに接続するブロックストレージで、OSのルートディスクやデータベースのディスクに使います。
複数インスタンスからの同時接続（マルチアタッチ）は限定的なサポートです。
S3 FilesはEC2・コンテナ含め多数のリソースから同時接続できるため、用途の性質がまったく異なります。
EBSは別物と考え、EFSやFSxの代替候補として検討するのが良さそうです。
どんな用途に向いているの？
S3 Filesが特に力を発揮しそうな場面を整理します。
一般提供は34のAWSリージョンで開始済みです。
EFSを基盤として構築されているため、EFSに慣れている方には設定面でも親しみやすい構成になっているようです。
ストレージ選択の悩みが、ひとつ減った
Amazon S3 Filesの登場で、「ファイルシステムアクセスが必要だからS3は使えない」という制約がなくなります。
S3のスケール・コスト・エコシステムを活かしたまま、既存のファイルベースのアプリケーションをそのまま動かせる・・・これは大きな変化ですね。
EFS・EBS・FSxとS3 Filesのどれを選ぶかは、
によって変わります。
ただ「S3にデータがあって、ファイルとして触りたい」という状況なら、まずS3 Filesを検討する価値があるでしょう。
ストレージ設計の選択肢が増えた分、アーキテクチャの自由度も上がりましたね。
