この記事の概要
2026年4月、AWSが「Amazon S3 Files」を全34リージョンで一般提供（GA）開始した。
S3バケットをNFS v4.1ファイルシステムとして直接マウントでき、アクティブデータに対して約1msのレイテンシを実現する。
EFSとS3を組み合わせてデータを二重管理していたアーキテクチャをシンプルに整理できる可能性があり、コスト削減効果は最大90%と発表されている。
S3とファイルシステムの「二重管理」という古い悩みがなくなる
インフラエンジニアとして「S3に置いたデータをアプリから直接ファイルとして読みたい」と感じたことは一度や二度ではないはずです。
これまでのAWSのストレージ選択は、ざっくり言うとこういうトレードオフでした。
- Amazon S3: 安い・耐久性が高い・スケールする。でもAPIベースのオブジェクトアクセスなのでアプリの改修が必要
- Amazon EFS: ファイルシステムのようにマウントして使える。でもS3より高い
この両方の要件を満たすために、S3にデータを置きつつ、処理時だけEFSに同期コピーして使うという構成をとるケースが多くありました。
データのコピー管理、同期タイムラグ、コストの二重払い——誰もが経験したことのある頭痛の種です。
Amazon S3 Filesは、この問題に正面から答えを出しています。
S3バケットをそのままNFSファイルシステムとしてマウントして使えるようになりました。
なぜ「S3 Files」でなければならなかったのか
オブジェクトストアとファイルシステムは本質的に別物だった
S3はオブジェクトストレージです。
ファイルを「本全体」として扱うため、一部だけ書き換えることができません。
ファイルシステムは「本のページ単位」で編集できます。
この違いが、「S3は耐久性とスケールは最高だが、Linuxのファイルシステムと同じ感覚では使えない」という制約を生んでいました。
MLとAIエージェントがトリガーになった
AWSがS3 Filesの開発を急いだ理由のひとつが、機械学習とAIエージェントの台頭です。
モデルの学習パイプラインは大量のデータセットを逐次読み書きします。
複数のGPUインスタンスが同じデータを共有しながら処理するためには、共有ファイルシステムが必要です。
これまでは「S3からEFSにコピーしてから学習開始」というステップが当たり前でしたが、データが数TBになると同期だけで数時間かかることもありました。
AWSが公式ブログで「AIエージェントシステムの構築」を代表的なユースケースとして挙げているのは、こうした背景があるためです。
graph LR
subgraph "Before S3 Files"
S3_old[S3 Bucket] -->|手動コピー・同期| EFS_old[EFS]
EFS_old -->|マウント| EC2_old[EC2 / ECS / EKS]
end
subgraph "After S3 Files"
S3_new[S3 Bucket] -->|NFS直接マウント| EC2_new[EC2 / ECS / EKS / Lambda]
end
実際にEC2インスタンスにS3バケットをマウントしてみる
S3 Filesの設定は驚くほどシンプルです。
マネジメントコンソール、CLI、IaC（CloudFormation/Terraform）のいずれからでも操作できます。
以下はCLIでの手順です。
1. S3 ファイルシステムを作成する
# バケットをファイルシステムとして登録
aws s3 create-file-system \
--bucket-name my-ml-datasets \
--region ap-northeast-1
# 出力例
# {
# "FileSystemId": "fs-0aa860d05df9afdfe",
# "BucketName": "my-ml-datasets",
# "LifeCycleState": "creating"
# }
2. マウントターゲットを作成する
# VPCサブネットにマウントターゲットを作成
aws s3 create-mount-target \
--file-system-id fs-0aa860d05df9afdfe \
--subnet-id subnet-0abc12345def67890 \
--security-groups sg-0987654321abcdef0
3. EC2インスタンスにマウントする
EC2インスタンスに amazon-efs-utils の最新バージョンが必要です（AWS提供のAMIには事前インストール済み）。
# マウントポイント作成
sudo mkdir -p /mnt/s3files
# S3 Filesをマウント（ファイルシステムIDを指定）
sudo mount -t s3files fs-0aa860d05df9afdfe:/ /mnt/s3files
# 通常のファイルシステムと同じように操作できる
ls -la /mnt/s3files/
# ファイルを書き込む
echo "Hello S3 Files" > /mnt/s3files/test.txt
# ファイルが自動的にS3オブジェクトとして同期される（数分以内）
aws s3 ls s3://my-ml-datasets/test.txt
# 2026-04-10 10:04:22 15 test.txt
4. ECSコンテナからマウントする場合
ECSのタスク定義では、EFSボリュームと同じ構文でS3 Filesを使えます。
{
"volumes": [
{
"name": "s3files-volume",
"efsVolumeConfiguration": {
"fileSystemId": "fs-0aa860d05df9afdfe",
"rootDirectory": "/datasets"
}
}
],
"containerDefinitions": [
{
"name": "ml-worker",
"image": "my-ml-image:latest",
"mountPoints": [
{
"containerPath": "/data",
"sourceVolume": "s3files-volume"
}
]
}
]
}
実務での活用シナリオ
シナリオ1：MLモデルの学習データ共有
複数のGPUインスタンスが同じS3バケット内のデータセットを共有して学習を行う構成では、これまでEFSを間に挟む必要がありました。
S3 Filesを使えばS3バケット直接で同じことができ、データの二重管理が不要になります。
シナリオ2：Lambdaからのファイル操作
Lambda関数のストレージは一時領域（/tmp）だけですが、S3 FilesをマウントすることでファイルシステムとしてS3にアクセスできます。
既存のファイルI/Oライブラリをそのまま使えるため、アプリのコードを変更せずにLambdaに移植するケースで効果的です。
シナリオ3：AIエージェントの共有作業領域
LangChainやCrewAIなどのエージェントフレームワークは、内部でファイルシステムを使ってタスクの状態やログを管理します。
複数のエージェントが同じS3 Filesをマウントすることで、共有メモリのような使い方ができるようになります。
EFS・FSxとの使い分け指針
S3 Filesが登場したことで「EFSはいらなくなるのか？」という疑問が出てきますが、そうではありません。
| ユースケース | 推奨ストレージ |
|---|---|
| S3上のデータをファイルとして読み書きしたい | S3 Files |
| オンプレNASからの移行・NFS/SMB互換性が必要 | FSx for NetApp ONTAP / OpenZFS |
| HPC・GPU クラスターの高スループットストレージ | FSx for Lustre |
| Windows共有フォルダの代替 | FSx for Windows File Server |
| S3と独立したスタンドアロンのファイルシステム | EFS |
料金と注意事項
S3 Filesの料金は以下の要素の組み合わせです。
- ファイルシステム上のデータ保存量（アクティブデータのキャッシュ分）
- 小さなファイルの読み取り・すべての書き込み操作
- S3とファイルシステム間の同期に伴うS3リクエスト料金
通常のS3ストレージ料金は従来通りかかります。
AWSは「S3との間でデータをサイクルさせる従来構成と比べて最大90%のコスト削減が可能」と発表していますが、アクセスパターンやデータ量によって効果は異なるため、実際のワークロードで検証することをおすすめします。
また、現時点での注意点として以下を把握しておきましょう。
- S3バケットは 汎用バケット（General Purpose） が必要。ディレクトリバケットは非対応
- ファイルシステムへの変更がS3に反映されるまで最大数分かかる場合がある
- S3側のオブジェクト変更がファイルシステムに反映されるまでは数秒〜1分程度かかることがある
- POSIX権限管理にはUID/GIDを使うため、コンテナ環境での権限設計に注意が必要
まとめ：S3のポジションが変わった
Amazon S3 Filesは、AWSのストレージ戦略における大きな転換点です。
これまでS3は「保存場所」であり、アプリケーションがそこからデータを取ってきて処理するという一方向の関係でした。
S3 Filesにより、S3は「すべての組織データの中心ハブ」として、どのコンピューティングリソースからも直接インタラクティブにアクセスできる場所になりました。
インフラエンジニアとしてまず試してみたいのは、「MLパイプラインのEFS部分をS3 Filesに置き換えられないか」という検証です。
データコピーのステップが消えることで、パイプラインのシンプルさとコストの両方が改善する可能性があります。
ぜひ、まずは開発・検証環境で試してみてください。
コメント