Amazon S3 FilesがGA - S3バケットをファイルシステムとしてマウント可能に

2026年4月7日、AWSは「Amazon S3 Files」の一般提供（GA）を発表しました。S3 Filesは、S3バケットを共有ファイルシステムとしてマウントできる新機能です。これにより、オブジェクトストレージとファイルシステムを用途に応じて使い分ける必要が減ります。

本記事では、S3 Filesの仕組み・ユースケース・料金体系・始め方までをまとめます。

S3 Filesとは

S3 Filesは、S3バケットに格納されたデータをNFSファイルシステムとしてマウントし、EC2・ECS・EKS・Lambdaなどのコンピュートリソースから直接ファイル操作できる機能です。内部的にはAmazon EFSの技術基盤を使用しており、低レイテンシーのファイルアクセスとS3のスケーラビリティ・耐久性を組み合わせています。

これまでS3上のデータをファイルベースのアプリケーションで扱うには、データを別のファイルシステムにコピーし、処理後にS3へ書き戻すという手順が必要でした。S3 Filesを使うと、このデータの二重管理が不要になります。

項目	内容
プロトコル	NFSv4.1 / NFSv4.2
対応コンピュート	EC2, ECS, EKS, Fargate, Lambda, Batch
同時接続数	最大25,000コンピュートリソース
読み取りスループット	集約で最大数TB/秒（単一クライアントは最大3 GiB/s）
ファイルシステムIOPS	読み取り最大250,000 / 書き込み最大50,000（ファイルシステムあたり）
レイテンシー	アクティブデータに対して約1ms
整合性モデル	NFS close-to-open consistency
暗号化	転送中: TLS 1.3 / 保存時: SSE-S3 または AWS KMS
提供リージョン	主要なすべての商用リージョン（対応リージョン一覧）

参照: Amazon S3 Files 製品ページ

仕組み ― 高性能ストレージとS3の読み分け

S3 Filesの動作を理解するうえでポイントとなるのが「高性能ストレージ（High-performance storage）」です。

ファイルシステムをマウントしてファイルにアクセスすると、S3 Filesはそのファイルのメタデータとコンテンツをオンデマンドで高性能ストレージにロードします。ただし、すべてのデータがロードされるわけではありません。

読み取りパターン	データの提供元	S3 Filesデータ課金
小さいファイル（デフォルト128KB未満）	高性能ストレージ	あり
大きいファイル（128KB以上）の読み取り	S3バケットから直接ストリーミング	なし（S3 GETリクエスト料金のみ）
高性能ストレージ上にないデータ	S3バケットから直接	なし

書き込みについては、まず高性能ストレージに書き込まれ、その後バックグラウンドでS3バケットに同期されます。ファイルシステム経由の書き込みは約60秒のバッチウィンドウ経過後にS3バケットへ反映されます。S3バケット側で直接変更されたオブジェクトは、通常数秒でファイルシステムに反映されますが、場合によっては1分以上かかることもあります。

高性能ストレージ上のデータは、設定可能な期間（1〜365日、デフォルト30日）アクセスがないと自動的に期限切れとなり、コストはアクティブに使用しているデータ量に比例します。

参照: S3 Files ドキュメント

ユースケース

S3 Filesが向いているシナリオを整理します。

ユースケース	従来の課題	S3 Filesによる解決
AIエージェント	エージェント間の状態共有にカスタム連携が必要	共有ファイルシステムでメモリ・ログ・中間状態を直接読み書き
ML学習・データ準備	S3からファイルシステムへのコピー＆ステージが毎回必要	前処理パイプラインがS3データを直接操作、結果も自動同期
ファイルベースアプリケーション	S3のAPIモデルとファイル操作の非互換	マウントするだけでコード変更なしに既存アプリが動作
チーム間コラボレーション	データの複製と同期パイプラインの管理	同一バケットを複数コンピュートから同時マウント

AWS公式ブログでは、Bayer（ライフサイエンス）、Deloitte（AIエージェント基盤）、Torc Robotics（自動運転のセンサーデータ処理）などの事例が紹介されています。

参照: AWS News Blog - Launching S3 Files

他のファイルサービスとの使い分け

AWSには複数のファイルストレージサービスがあります。S3 Filesの位置づけを整理します。

サービス	主な用途
S3 Files	S3上のデータに対する共有ファイルアクセス。AIエージェント、ML、ファイルベースアプリ
Amazon EFS	汎用的な共有ファイルシステム。S3との連携が不要なワークロード
Amazon FSx for Lustre	HPCやGPUクラスタ向けの高性能ファイルシステム
Amazon FSx for NetApp ONTAP	オンプレNASからの移行、マルチプロトコル対応
Amazon FSx for Windows File Server	Windows環境向けのSMBファイル共有

S3 Filesは「データの正本がS3にあり、それをファイルとしても扱いたい」というケースに向いています。一方、オンプレミスNAS環境からの移行にはFSxシリーズが適しています。

参照: AWS News Blog - Launching S3 Files

料金体系

S3 Filesの料金は、高性能ストレージの使用量とデータアクセスの2軸で構成されます。既存のS3ストレージ料金は別途かかります。

料金項目	内容
高性能ストレージ料金	アクティブデータの保存量に対して $0.30/GB/月
データアクセス料金（書き込み）	高性能ストレージへの書き込み $0.06/GB。同期によるインポート（S3→ファイルシステム）もこの書き込み料金として課金
データアクセス料金（読み取り）	高性能ストレージからの読み取り $0.03/GB。同期によるエクスポート（ファイルシステム→S3）もこの読み取り料金として課金
大きいファイルの読み取り（128KB以上）	S3 GETリクエスト料金のみ（S3 Filesデータアクセス課金なし）

同期（インポート/エクスポート）はデータアクセス料金とは別に二重課金されるものではなく、上記の書き込み・読み取り料金の一部として計上されます。

料金例

100GBのS3バケットに対して、10GBの読み取り（うち94%が大きいファイル）と1GBの書き込みを行った場合の月額は約$0.38です。大きいファイルの読み取りにはS3 Filesの課金が発生しないため、実際のコストはアクティブに使用する小さいファイルの量に大きく依存します。

AWSは「S3と別のファイルシステム間でデータを往復させる場合と比較して最大90%のコスト削減」と謳っています。

料金の詳細は S3料金ページをご確認ください。

始め方

S3 Filesのセットアップは3ステップです。

Step 1: S3ファイルシステムの作成

S3コンソールで「File systems」→「Create file system」を選択し、対象のバケット名を入力します。

AWS CLIの場合は以下のコマンドを使用します。

# ファイルシステムの作成（--bucket にはバケットARN、--role-arn にはIAMロールARNを指定）
aws s3files create-file-system \
  --bucket arn:aws:s3:::my-bucket-name \
  --role-arn arn:aws:iam::123456789012:role/S3FilesRole

# マウントターゲットの作成（VPC内のネットワークエンドポイント）
aws s3files create-mount-target \
  --file-system-id fs-xxxxxxxxx \
  --subnet-id subnet-xxxxxxxx

Step 2: マウント

EC2インスタンスにEFSドライバー（amazon-efs-utils）がインストールされていることを確認し、マウントします。

sudo mkdir /mnt/s3files
sudo mount -t s3files fs-0aa860d05df9afdfe:/ /mnt/s3files

Step 3: ファイル操作

マウント後は通常のファイル操作がそのまま使えます。

# ファイルの作成
echo "Hello S3 Files" > /mnt/s3files/hello.txt

# ファイルの確認
ls -al /mnt/s3files/hello.txt

# S3側にも自動同期される（数分以内）
aws s3 ls s3://my-bucket-name/hello.txt

参照: S3 Files Getting Started / AWS CLI s3files create-file-system

ファイルロックと書き込み競合の挙動

S3 Filesを共有ファイルシステムとして使う場合、ファイルロックと書き込み競合の挙動を把握しておくことが大切です。

NFS経由のファイルロック

S3 FilesはNFSv4.1/4.2のファイルロック機能をサポートしています。ただし、すべてのロックはアドバイザリロック（advisory lock）です。強制ロック（mandatory lock）はサポートされていません。

項目	内容
ロック種別	アドバイザリロックのみ（強制ロックは非対応）
ファイルあたりの最大ロック数	512（全接続インスタンス合計）
マウントあたりの最大ロック数	8,192（最大256のファイル-プロセスペア）
Deny Share	非対応
Client Delegation / Callbacks	非対応

アドバイザリロックは、ロックを取得するプロセス間では排他制御が機能しますが、ロックを取得せずにファイルにアクセスするプロセスを強制的にブロックすることはできません。つまり、すべてのアプリケーションが協調的にロックを取得する設計になっていることが前提です。

参照: S3 Files - Unsupported features, limits, and quotas

NFS経由の書き込み競合（複数コンピュートリソース間）

複数のEC2インスタンスやコンテナから同一ファイルシステムをマウントしている場合、S3 FilesはNFS close-to-open consistencyを提供します。

整合性モデル	挙動
close-to-open consistency	あるクライアントがファイルをclose → 別のクライアントが同じファイルをopen すると、closeまでの変更が反映された状態で読み取れる
同時書き込み（ロックなし）	最後に書き込んだ内容が勝つ（last-writer-wins）。データの整合性は保証されない
同時書き込み（ロックあり）	アドバイザリロックにより排他制御が可能。ただし全プロセスがロックを取得する前提

ファイルシステムへの書き込みは、約60秒ごとに変更がバッチ化されて1回のS3 PUTリクエストとしてS3バケットに同期されます。連続した書き込みが効率的にまとめられる一方、同期完了前のデータはファイルシステム上にのみ存在する点に注意が必要です。

参照: Understanding how synchronization works

S3 API経由の書き込み競合（ファイルシステム vs S3バケット）

S3 Filesで特に注意したいのが、ファイルシステム経由とS3 API経由で同一オブジェクトを同時に変更した場合の競合です。

シナリオ	S3 Filesの挙動
ファイルシステムで編集中に、S3 APIで同一オブジェクトが更新された	S3バケットが正（source of truth）。ファイルシステム側の変更は `lost+found` ディレクトリに退避され、S3バケットの最新バージョンがファイルシステムに反映される
ファイルシステムで編集中に、S3 APIで同一オブジェクトが削除された	同上。ファイルシステム側の変更は `lost+found` に退避
S3バケットへの同期完了後に、S3 APIで更新された	競合なし。S3 Filesがイベント通知で変更を検知し、通常数秒でファイルシステムに反映

競合が発生した場合、ファイルシステム側の変更はファイルシステムのルートディレクトリ配下の .s3files-lost+found-<file-system-id> ディレクトリに移動されます。このディレクトリ内のファイルはS3バケットには同期されず、手動で確認・復旧する必要があります。不要になったファイルは削除しないとストレージ料金が発生し続けます。

競合を避けるためのベストプラクティス

プラクティス	説明
書き込みパスを一本化する	同一オブジェクトに対して、ファイルシステム経由とS3 API経由の書き込みを同時に行わない。どちらか一方をプライマリライターとして指定する
CloudWatchで同期状態を監視する	`PendingExports`（未同期の変更数）と `ExportFailures`（同期失敗数）のメトリクスにアラームを設定する
`lost+found` ディレクトリを定期確認する	競合が発生していないか定期的にチェックし、不要ファイルを削除してストレージコストを抑える
リネーム中のS3直接書き込みを避ける	ディレクトリのリネーム・移動中にS3 API経由で同一プレフィックスにオブジェクトを作成すると、移動対象から漏れる可能性がある

参照: S3 Files best practices

知っておくべきポイント

項目	詳細
アクセス制御	IAMポリシー + POSIXパーミッション（UID/GID）の二重制御
暗号化	転送中はTLS、保存時はSSE-S3またはKMSカスタマーマネージドキー
モニタリング	CloudWatchメトリクス + CloudTrailによる管理イベントログ
対象バケット	汎用バケット（General Purpose Bucket）のみ
プレフィックス指定	バケット全体ではなく特定プレフィックスのみをファイルシステムとして公開可能
ファイルサイズ閾値	デフォルト128KB。これ未満のファイルが高性能ストレージに配置される
データ保持期間	1〜365日（デフォルト30日）。期間内にアクセスがないデータは自動削除