TL;DR（30秒で分かる要約）
- 何が起きた？ → AmazonがS3バケットをNFSファイルシステムとして直接マウントできる「S3 Files」を全商用リージョンで一般提供開始（2026-04-07）
- なぜ重要？ → これまでS3のオブジェクトAPIとファイルシステムAPIは別物で、両方使いたい場合はデータのコピーや専用ツールが必要だった。それが不要になる
- 何をすべき？ → ML訓練データの共有やマルチインスタンス間のデータ連携を行っている場合、EFSとのコスト比較を検討してみましょう
はじめに
「S3にファイルを置く」と「サーバーにファイルを置く」は、これまで別の操作でした。
S3はAWSのオブジェクトストレージで、ファイルを「アップロード」「ダウンロード」するAPIで操作します。一方、サーバー上のファイルは ls、cp、cat といったコマンドで操作します。この2つは仕組みが違うため、「S3のデータをプログラムから直接ファイルとして読み書きしたい」という要件があると、どこかで変換・コピーが必要でした。
今回GAになった「Amazon S3 Files」は、この壁を取り除く機能です。S3バケットをLinuxのディレクトリとしてマウントして、通常のファイル操作でS3のデータを読み書きできるようになりました。
今回のアップデート概要
| 項目 | 内容 |
|---|---|
| 発表者 | AWS |
| GA日 | 2026年4月7日 |
| 対象サービス | Amazon S3 |
| 提供形態 | GA（全商用リージョン） |
| 対応環境 | EC2・ECS・EKS・Lambda |
| プロトコル | NFS v4.1+ |
何が変わったのか（Before / After）
Before（これまで）
S3のデータをファイルシステムとして扱いたい場合、主に3つの方法がありました。
1. EFS（Elastic File System）と組み合わせる
EFSはNFS対応のマネージドファイルシステムです。ただし、S3とは別のサービスのため「S3のデータをEFSにコピーしてから処理→処理後にS3に書き戻す」という二重管理が発生していました。コストも積み上がります。
2. s3fsなどのサードパーティツールを使う
s3fs-fuse などのOSSツールでS3をFUSEマウントする方法もあります。ただし、パフォーマンスが安定しない・本番運用での信頼性に懸念があるという声も多くありました。
3. アプリ側でS3 SDKを直接使う
コード内でBoto3などのSDKを使いS3 APIで読み書きする方法です。既存のファイルシステムを前提としたライブラリやツールはそのまま使えません。
After（これから）
S3バケットをNFSとしてマウントするだけで、通常のファイル操作が使えるようになりました。
# マウントコマンド（例）
mount -t nfs4 \
-o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 \
<bucket-name>.s3files.<region>.amazonaws.com:/ /mnt/s3data
マウント後はこれだけで動きます。
# S3のオブジェクトをファイルとして読む
cat /mnt/s3data/train/data.csv
# ファイルを書き込む（数分以内にS3に反映）
cp ./output.json /mnt/s3data/results/output.json
# ディレクトリ一覧を取得
ls -la /mnt/s3data/models/
技術的な詳細
仕組み
S3 Files はS3バケットに専用のNFSエンドポイントを提供します。EC2などのコンピュートリソースからNFS v4.1でこのエンドポイントに接続すると、バケット内のオブジェクトがファイルとして見えます。
EC2 / ECS / EKS / Lambda
↓ NFS v4.1
S3 Files エンドポイント
↓
S3 バケット（通常のオブジェクトストレージ）
重要な点として、S3側のオブジェクトとファイルシステムのファイルは同一データです。ファイルシステム経由で書いたファイルはS3 APIからも見えますし、S3 APIで置いたオブジェクトはファイルシステム経由でも読めます。
性能・制限・コスト
| 項目 | 内容 |
|---|---|
| レイテンシ | 約1ms（同一リージョン内） |
| ファイルシステム→S3反映 | 数分以内 |
| S3→ファイルシステム反映 | 数秒〜数分 |
| 暗号化 | TLS 1.3（転送中）、KMS対応（保存時） |
| アクセス制御 | POSIX権限 ＋ IAM |
| コスト | S3の標準ストレージ料金 ＋ S3 Filesのアクセス料金 |
注意事項：
- ファイルシステムへの書き込みがS3に反映されるまでに数分かかります。リアルタイム同期が必要な用途には向きません
- POSIX完全互換ではありません。一部のファイル操作はサポートされていない可能性があります
- 同一バケットに対して複数のインスタンスからマウントすることは可能ですが、同一ファイルへの同時書き込みには注意が必要です
boto3 と S3 Files の使い分け
import boto3
# これまで通り、S3 APIでも同じバケットにアクセス可能
s3 = boto3.client('s3')
s3.upload_file('local_file.txt', 'my-bucket', 'path/to/object.txt')
# ↑でアップロードしたファイルは、マウント済みなら下記でも読める
with open('/mnt/s3data/path/to/object.txt', 'r') as f:
content = f.read()
S3 APIとファイルシステムAPIは同じバケットに対して共存して使えます。
実際にどう使えるか（ユースケース）
ユースケース 1：ML訓練データの複数インスタンス共有
課題： 複数のGPUインスタンスで同じ訓練データセットを使いたい。これまではS3から各インスタンスにコピーする処理が必要で、ストレージコストとコピー時間がかかっていた。
S3 Filesでの解決： 各インスタンスが同じS3バケットをマウントするだけで、データのコピーなしに共有アクセスが可能になります。
# 全インスタンスで同じコマンドでマウント
mount -t nfs4 -o nfsvers=4.1 \
training-data-bucket.s3files.ap-northeast-1.amazonaws.com:/ \
/mnt/training-data
# PyTorchのDataLoaderはそのまま使える
from torch.utils.data import Dataset
class S3Dataset(Dataset):
def __init__(self, data_dir):
# /mnt/training-data を普通のディレクトリとして扱うだけ
self.files = list(Path(data_dir).glob('*.pt'))
ユースケース 2：既存のファイルシステム前提ツールをそのまま使う
課題： ffmpegやImageMagickなど、ファイルパスを前提としたツールをS3のデータに対して使いたい。これまではS3からダウンロードして処理→S3へアップロードという手順が必要だった。
S3 Filesでの解決： マウント後はファイルパスを渡すだけで動きます。
# S3上の動画ファイルを直接変換
ffmpeg -i /mnt/s3data/videos/input.mp4 \
-c:v libx264 \
/mnt/s3data/videos/output.mp4
# 変換結果は自動的にS3に保存される
ユースケース 3：AIエージェントパイプラインの中間データ共有（エンジニア向け応用）
課題： 複数のコンテナ（エージェント）が中間データをやり取りするパイプラインで、コンテナ間のデータ受け渡しにS3 APIのコードを書くのが煩雑だった。
S3 Filesでの解決： 全コンテナが同じS3バケットをマウントすることで、ファイルの読み書きだけでデータ連携が完結します。EFSより安価なS3のストレージコストのまま運用できます。
# ECSタスク定義（イメージ）
volumes:
- name: shared-s3-data
efsVolumeConfiguration: # ← ここをS3 Filesに変えられる
fileSystemId: fs-xxx
containers:
- name: agent-1
mountPoints:
- containerPath: /mnt/shared
sourceVolume: shared-s3-data
- name: agent-2
mountPoints:
- containerPath: /mnt/shared
sourceVolume: shared-s3-data
他のストレージサービスとの比較
S3 Filesを選ぶべき場面を整理します。
| S3 Files | EFS | S3（API直接） | |
|---|---|---|---|
| アクセス方法 | NFS + オブジェクトAPI両方 | NFSのみ | オブジェクトAPIのみ |
| コスト（目安） | S3料金 + アクセス料金 | 高め（GB単価がS3の数倍） | S3料金のみ |
| レイテンシ | 約1ms | サブms | S3 API依存 |
| 既存ツール互換性 | ファイルパス前提のツールが使える | 使える | 使えない（SDK要） |
| 向いている用途 | MLデータ共有・バッチ処理 | 低レイテンシ・高頻度アクセス | APIアクセスのみの用途 |
「S3のコストでファイルシステムが使いたい」という要件に対しては、S3 Filesが素直な選択肢になります。ただし、レイテンシがサブmsレベルで必要な場合やファイルの整合性要件が厳しい場合はEFSの方が安全です。
まとめ
今回はAmazon S3 FilesのGAリリースについてご紹介しました。
- ✅ S3バケットをNFS v4.1でマウントし、通常のファイル操作でアクセス可能になった
- ✅ EC2・ECS・EKS・Lambdaで利用でき、全商用リージョンで提供中
- ✅ S3 APIとファイルシステムAPIが同じバケットに対して共存できる
- ✅ EFSよりS3のストレージコストで運用できる場面が増える
- ⚠️ ファイルシステムへの書き込みがS3に反映されるまで数分かかる点に注意
複雑な構成を組まなくても、マウントコマンド1行で既存ツールやライブラリがそのまま使えるようになります。ML系のワークロードやファイルベースの処理パイプラインをお持ちの方は、EFSとのコスト比較も含めて一度検討してみてください。
最後まで読んでいただき、ありがとうございました！