【AWS】Amazon S3 Files の概要・料金・設定手順と他サービス比較

はじめに

近年、クラウド環境における大容量データ管理において、オブジェクトストレージの優れたスケーラビリティと、ファイルシステムの直感的な操作性の両立が課題となっていました。これまで、Amazon S3 に保存されたデータを従来のアプリケーションからファイルとして扱うためには、データの複製や定期的な同期バッチ、あるいはサードパーティ製ツールの導入が求められるケースが一般的でした。

2026 年 4 月 7 日に一般提供（GA）が開始された Amazon S3 Files は、S3 バケットを直接ファイルシステムとしてマウントできるネイティブな機能です。データの複製や移動を伴わずに、既存のファイルベースのツールやアプリケーションから S3 データへ直接アクセスすることが可能になります。GA 開始時点で 34 の AWS リージョンで利用可能です。

参考: AWS（Announcing Amazon S3 Files, making S3 buckets accessible as file systems）

“S3 Files is a shared file system that connects any AWS compute directly with your data in Amazon S3. It provides fast, direct access to all of your S3 data as files with full file system semantics and low-latency performance, without your data ever leaving S3.” （S3 Files は、任意の AWS コンピューティングを Amazon S3 内のデータに直接接続する共有ファイルシステムです。データが S3 から離れることなく、すべての S3 データにファイルとして高速かつ直接アクセスでき、完全なファイルシステムセマンティクスと低レイテンシーのパフォーマンスを提供します。）

https://aws.amazon.com/jp/s3/features/files/

一言でいうと、S3 Files は「S3 を、コピーせずに、みんなで開ける共有フォルダにする」機能。Linux からは NFS でそのまま、Windows は EC2 経由で SMB 共有にすると、まさにいつものファイルサーバー感覚で使えます。

本記事では、この Amazon S3 Files の概要や利点を整理するとともに、類似サービスとの比較、具体的な設定手順、運用上の留意点について詳しく解説します。

Amazon S3 Files の概要と主なメリット

Amazon S3 Files は、Amazon S3 に保存されたオブジェクトデータを、共有ファイルシステムとして直接マウントして利用できる機能です。内部的には Amazon EFS の技術が組み込まれており、頻繁にアクセスされるデータ（アクティブなワーキングセット）を自動的に高性能ストレージへロードするアーキテクチャが採用されています。

これにより、事前のデータ同期やコピー処理を挟むことなく、既存のファイルベースのアプリケーションからアクティブなデータに対して約 1 ミリ秒のレイテンシーで S3 のデータ群へアクセスすることが可能になります。

参考: AWS（Announcing Amazon S3 Files, making S3 buckets accessible as file systems）
“S3 Files is built using Amazon EFS, which intelligently loads your active working set onto high-performance storage. This delivers low latencies for frequently accessed data while keeping costs proportional to what you’re actively using.”
（S3 Files は Amazon EFS を使用して構築されており、アクティブなワーキングセットを高性能ストレージにインテリジェントにロードします。これにより、頻繁にアクセスされるデータに対して低レイテンシーを提供しながら、アクティブに使用しているものに比例したコストを維持します。）
https://aws.amazon.com/jp/s3/features/files/

本機能を利用する主なメリットとして、以下の 3 点が挙げられます。

データサイロの解消とアーキテクチャの簡素化

S3 を信頼できる単一の情報源（Single Source of Truth）として維持したまま、最大 25,000 のコンピューティングリソース（EC2・ECS・EKS・Lambda・Fargate・Batch を含む）から同時にファイルアクセスが可能です。データ移動のための ETL パイプラインや同期バッチが不要になるため、システム構成の複雑化や運用負荷の軽減につながります。

高パフォーマンスの維持

バケットあたり 1,000 万以上の IOPS、および 4 TB/s 以上の集約読み取りスループットにスケールします。機械学習のトレーニングパイプラインや、AI エージェントが中間結果をやり取りする共有ワークスペースなど、高い I/O 性能が要求されるワークロードへの適用が推奨されます。

運用コストの最適化

設定した期間（1 〜 365 日の間で指定、デフォルトは 30 日）アクセスされなかったデータは、自動的に高性能なキャッシュストレージから期限切れとなる仕組みを持っています。必要なデータのみに高性能ストレージのコストが発生するため、別々のファイルシステム間でデータを循環させる従来の手法と比較して、最大 90% 程度のコスト削減が見込めます。

中身は EFS ベースで、よく使うデータだけ自動で速い置き場に載せます。だから最初は普通、2回目から速い。料金も「置いた分」ではなく「触った分」が中心なので、使わないデータを温め続ける無駄が減ります。最大25,000台から同時アクセスも OK、は大規模学習でも安心な数字です。 

Amazon S3 Files の料金・コスト構造

Amazon S3 Files の課金は「高性能ストレージ（キャッシュ層）に載ったデータの分だけ課金される」という設計が基本です。S3 バケット全体に対してではなく、実際にアクセスされたアクティブなワーキングセットのみに対して高性能ストレージの料金が発生します。

料金の仕組みと主要な単価

S3 Files の料金は大きく 3 つの軸で構成されます（以下は米国東部リージョンの参考単価です。リージョンにより異なるため、実環境では公式料金ページをご確認ください）。

参考: AWS（Amazon S3 料金）

https://aws.amazon.com/jp/s3/pricing/

コスト設計上の重要な特性

ファイルサイズしきい値（デフォルト 128 KB）の挙動

デフォルトでは 128 KB 未満の小規模ファイルのみがキャッシュ層に取り込まれ、ストレージ料金と読み書き料金が発生します。128 KB 以上の大規模ファイルは S3 から直接ストリーミングされるため、高性能ストレージのコストはかかりません。このしきい値はワークロードに合わせて変更可能です。

初回読み取り時の挙動

小規模ファイルを初めて読み取ると、そのファイルはキャッシュ層にインポートされます。このインポート処理には書き込み料金（$0.06/GB）が適用されるため、初回アクセス時のコストは 2 回目以降の読み取り（$0.03/GB）より高くなります。アクセス頻度が低いファイルを大量に保有するワークロードでは、この点を考慮した設計が推奨されます。

EFS との比較

S3 Files の高性能ストレージ料金（$0.30/GB-月）は EFS Performance-optimized Standard と同一の単価です。ただし、EFS は保存しているすべてのデータに対して $0.30/GB-月 が課金されるのに対し、S3 Files はアクティブなデータの一部のみに課金される点が決定的に異なります。データセット全体を S3 に置いたまま、頻繁にアクセスする部分だけをキャッシュ層に展開できるため、大量データを保有しつつ一部だけを集中的に操作するようなワークロードでコスト効率が高まります。

コスト試算の目安

公式料金ページには月次の試算例として、以下のようなシナリオが掲載されています（米国東部リージョン）。

• S3 Files 書き込み：1 GB × $0.06 = $0.06
• 書き込みの S3 同期：0.25 GB × $0.03 = $0.0075
• 小規模ファイル読み取り：10 GB のうち 6%（0.60 GB）× $0.03 = $0.018
• 大規模ファイル（128 KB 以上）の読み取り：$0（S3 から直接ストリーミングのため）
• 合計：約 $0.38

実際の料金はホットデータの割合・読み書きパターン・リージョンによって大きく異なるため、本番採用前に AWS 料金計算ツールでの試算を推奨します。

参考: AWS（AWS 料金計算ツール）

https://calculator.aws/

既存サービス（FSx シリーズ・S3FS）との機能・コスト比較

Amazon S3 のデータをファイルとして扱う場合、これまでは Amazon FSx for Lustre を利用してデータを同期するか、オープンソースの S3FS（FUSE）を用いてマウントする手法が一般的でした。また、AWS が提供するオープンソースクライアント「S3 Mountpoint」も選択肢の一つです。しかし、それぞれパフォーマンスや運用コスト、管理の手間において一長一短があります。

Amazon S3 Files は、これら既存手法の課題を解決する新しい選択肢として位置づけられます。特に、別々のファイルシステムを用意してデータを移動させる従来手法と比較した場合、大幅なコスト最適化が期待できます。

参考: AWS（Announcing Amazon S3 Files, making S3 buckets accessible as file systems）
“up to 90% lower costs compared to cycling data between S3 and separate file systems”
（S3と個別のファイルシステム間でデータを循環させる場合と比較して、最大90%のコスト削減）
https://aws.amazon.com/jp/s3/features/files/

各サービスの特徴と、それぞれの導入が推奨されるユースケースを以下の表に整理しました。

選択のポイント

機械学習のトレーニングやデータサイエンティストのコラボレーション環境など、パフォーマンスと運用負荷のバランスが求められる一般的なファイルベースのワークロードにおいては、データ同期の複雑さを排除できる Amazon S3 Files の採用を推奨します。

一方で、既存のサービスが完全に不要になるわけではありません。以下のケースでは他サービスが引き続き有力な選択肢となります。

• FSx for Lustre: 数百〜数千の並列ノードで極限のスループットを追求する HPC 領域
• S3 Mountpoint: 既存ファイルの変更が不要な読み取り中心ワークロードで、コストを最小化したい場合
• FSx for Windows File Server: Windows 環境のネイティブ連携（Active Directory 統合など）が必須な場合
• S3FS: 個人検証・低頻度アクセスで、ツールインストールを最小限にしたい場合

Amazon S3 Files のマウント・設定手順（EC2・オンプレミス）

Amazon S3 Files は内部的に Amazon EFS の技術を採用しているため、標準的な Linux ベースのコンピューティングリソースから、従来のネットワークファイルシステムと同様のコマンド体系でアクセスすることが可能です。専用のカスタムツールや複雑な認証フローを新しく覚える必要はありません。

参考: AWS（Announcing Amazon S3 Files, making S3 buckets accessible as file systems）
“S3 Files works like a traditional high-performance file system that can be accessed by any Linux-based compute resource, but its view of files and folders reflects what’s in your S3 bucket.”
（S3 Files は、Linux ベースの任意のコンピューティングリソースからアクセスできる従来の高性能ファイルシステムのように機能しますが、ファイルとフォルダーのビューは S3 バケット内のものを反映します。）
https://aws.amazon.com/jp/s3/features/files/

実際の運用環境で想定される、代表的な 2 つの接続パターンにおけるマウント手順と設定の要点を解説します。

# ファイルシステムの作成
aws s3files create-file-system \
  --region <aws-region> \
  --bucket <bucket-arn> \
  --role-arn <iam-role-arn>

# マウントターゲットの作成（EC2 と同一 AZ のサブネットを指定）
aws s3files create-mount-target \
  --region <aws-region> \
  --file-system-id <file-system-id> \
  --subnet-id <subnet-id>

# Amazon Linux 2023 / RHEL 系
sudo yum install -y amazon-efs-utils

# Ubuntu / Debian 系
sudo apt-get install -y amazon-efs-utils

# マウントポイントの作成
sudo mkdir /mnt/s3files

# マウントの実行
sudo mount -t s3files <file-system-id>:/ /mnt/s3files

sudo mount -t s3files -o accesspoint=<access-point-id> <file-system-id> /mnt/s3files

やることは普通の NFS マウントです。コマンドは mount -t s3files。つまずきは 2 つだけ。

➀セキュリティグループで TCP 2049 を開ける
➁オンプレから使うときは DNSを先に通す（Route 53 Resolverのフォワーダ）

バケットはバージョニング必須、CLI は 2.34 以上が必要です。
Windows から直接使いたい時は、EC2 にマウントしてからその EC2 を SMB 共有すると、普通の Windows 共有として使えます。

導入前に確認しておきたい制約事項・非対応機能

Amazon S3 Files は GA 時点においていくつかの制約があります。既存のワークフローやアプリケーションとの適合性を確認するために、導入前に把握しておくことが推奨されます。

ストレージ・データ操作面の制約

プロトコル・ネットワーク面の制約

参考: AWS（Working with Amazon S3 Files）

https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files.html

パフォーマンス特性と実運用に向けた最適化のヒント

Amazon S3 Files は、バケットあたり 1,000 万以上の IOPS、4 TB/s 以上の集約読み取りスループット、そして最大 25,000 のコンピューティングリソースからの同時アクセスをサポートするスケーラブルなパフォーマンスを提供します。

この性能をコスト効率よく最大限に引き出すためには、S3 Files が内部でどのようにデータを扱っているか（キャッシングと遅延ロードの仕組み）を理解し、ワークロードに応じたチューニングを行うことが推奨されます。

参考: AWS（Announcing Amazon S3 Files, making S3 buckets accessible as file systems）
“When you read files, S3 Files lazily loads portions of file metadata and contents onto high-performance storage. Data that doesn’t meet your configured file size threshold is read directly from S3, with no file system storage involved.”
（ファイルを読み取ると、S3 Files はファイルメタデータとコンテンツの一部を高性能ストレージに遅延ロード（lazy load）します。設定したファイルサイズしきい値を満たさないデータは、ファイルシステムストレージを介さずに S3 から直接読み取られます。）
https://aws.amazon.com/jp/s3/features/files/

実運用に向けて、以下の 3 つの最適化ポイントを考慮することをおすすめします。

ワーキングセットの有効期限（保持期間）の最適化

S3 Files の背後にある高性能ストレージ（EFS ベース）にロードされたデータは、一定期間アクセスがないと自動的に削除（期限切れ）になります。この期間は 1 日から 365 日（デフォルトは 30 日）の間で設定可能です。バッチ処理や機械学習の学習フェーズなど、短期間しかデータにアクセスしないワークロードの場合は、この日数を短く設定することで、不要なストレージコストの削減につながります。

ファイルサイズのしきい値の設計

前述の引用にある通り、すべてのファイルが高性能ストレージにキャッシュされるわけではありません。設定したサイズしきい値以下の小さなファイルは S3 から直接読み取られます。大量の小規模ファイルを頻繁に読み書きする環境（IoT ログや一部の解析データなど）では、このしきい値の設定がレイテンシに直結するため、実際のデータ特性に合わせた事前の検証を推奨します。

書き込みの同期タイミングと整合性の考慮

S3 Files マウント経由でデータを書き込むと、データはまず耐久性の高い高性能ストレージに保存され、その後バックグラウンドで S3 バケットへ同期（Sync）されます。このため、書き込み直後に別システムから「S3 API 経由」で該当オブジェクトを直接参照すると、変更が反映されるまでにわずかなタイムラグが発生する可能性がある点に留意が必要です。

覚えるのは「遅延ロード」だけ。読んだ分だけ速い置き場に乗ります。小さいファイルを大量に触るなら、しきい値を下げてキャッシュに乗せるか、割り切って S3 直読み設計に。保持期間はデフォルト 30 日ですが、学習ジョブなら 7〜14 日に短くするとコストが下がります。書き込みは一度速い層に入ってから S3 へ同期なので、書いた直後に別システムから S3 API で見ると少し遅れて見えることがあります。リトライを入れておくと安全

既存の S3 機能（ライフサイクル等）との連携における留意点

Amazon S3 Files の最大の特徴は、マスターデータが S3 バケットから別のストレージへと移動しない点にあります。そのため、Amazon S3 が提供する強固なセキュリティ（IAM ポリシーやアクセス制御リスト）、監査証跡、およびデータ保護機能（クロスリージョンレプリケーションなど）をそのまま継続して利用することが可能です。

参考: AWS（Announcing Amazon S3 Files, making S3 buckets accessible as file systems）
“Data that hasn’t been accessed within a configurable window (1 to 365 days, defaulting to 30) automatically expires from this storage, so you pay only for what you’re actively using while your authoritative data always remains in S3.”
（設定可能な期間（1 日〜 365 日、デフォルトは 30 日）アクセスされなかったデータは、自動的にこのストレージから期限切れになります。そのため、マスターデータは常に S3 に残ったまま、アクティブに使用しているものに対してのみ支払いが発生します。）
https://aws.amazon.com/jp/s3/features/files/

このように既存の仕組みを維持できる一方で、ファイルシステムとしての機能が追加されることで、従来の S3 運用ルールと組み合わせる際には以下の点に留意することが推奨されます。

S3 ライフサイクルルールとの競合

S3 Files 側の「高性能ストレージ（キャッシュ）からの期限切れ」と、S3 バケット側の「S3 Glacier などのアーカイブ層への移行（ライフサイクルルール）」は、完全に独立した設定です。ファイルシステムとして頻繁にアクセスする予定のデータが、S3 側のルールによって誤って Glacier へ移行（読み取りに復元プロセスが必要な状態）してしまわないよう、両者の保持ポリシーを統合的に設計することが推奨されます。

S3 バージョン管理機能との関係

S3 バケットのバージョン管理機能が有効な環境において、S3 Files のマウントポイント経由でファイルを上書き、または削除した場合、S3 側ではオブジェクトの新しいバージョンの作成や削除マーカーの付与が行われます。ファイルシステム上の気軽なファイル操作が、S3 側のストレージ容量（古いバージョンの蓄積）に影響を与える可能性がある点に注意が必要です。

イベント通知との連携

S3 Files 経由での書き込みは、バケットへの同期が完了したタイミングで S3 の標準的な PutObject などのイベントをトリガーします。既存の AWS Lambda などを用いたイベント駆動型のパイプラインと連携する際は、ファイルシステム側での一時的な保存ではなく、S3 側への同期タイミングが起点となることを前提としたアーキテクチャの構築をおすすめします。

ここは落とし穴。S3 Files の「キャッシュから消す」と、S3 の「Glacier へ送る」は別物です。よく触るデータを間違って Glacier に送らないよう注意しましょう。

まとめ

• Amazon S3 Files は、S3 のデータを直接ファイルシステムとしてマウントできるネイティブ機能
• データの同期や移動が不要になるため、システム構成の簡素化と最大 90% のコスト削減が期待できる。
• EC2 やオンプレミス環境からamazon-efs-utilsとmount -t s3filesコマンドを使用してマウント可能
• 料金はアクティブデータのみに課金される。
• Glacier 非対応・ハードリンク非対応・pNFS 非対応など、導入前に制約事項の確認が推奨される。
• 運用時は、キャッシュの保持期間や S3 側のライフサイクルルールとの競合を考慮した設計が推奨
• 高い I/O 性能が求められる AI 開発や、分析パイプラインなどの共有ワークスペースに有力な選択肢となる。

以上、最後までお読みいただきありがとうございました。