【Amazon S3 Files】S3バケットをEC2からNFSマウントして試してみた

Amazon S3 Files とは
Mountpoint for S3との比較
前提条件と事前準備
実際にマウントしてみる
動作確認：ファイルを書いてS3に反映されるか
ハマった及び懸念となりそうなポイント
おわりに

こんにちは、山本です。

近年、AWSのS3はストレージとして欠かせない存在になってきているかと思います。私も業務でS3をよく使うのですが、「Amazon S3のデータをファイル操作感覚で扱えたら楽なのに」と感じる場面が多くありました。例えばMLのデータをAmazon EC2からコピーしてくる手間だったり、複数のサービス間でファイルを共有するためにわざわざAmazon S3 APIを書いたりといった部分がやや面倒に感じていました。

そんな中、2026年4月に「Amazon S3 Files」という機能が一般提供（GA）されました。簡単に言うと、S3バケットをそのままNFSファイルシステムとしてマウントできるようになった機能です。今回はこのAmazon S3 Filesを実際にEC2からマウントして試してみた内容をまとめます。

Amazon S3 Files とは

Amazon S3 Files は、既存のS3バケットを NFSv4.1/4.2 対応のファイルシステムとしてマウントできるようにする機能です。2026年4月7日に一般提供が開始され、現在34の AWS リージョンで利用可能です。

内部的には2層のストレージ構造になっています。

128 KiB未満の小ファイルへのアクセスは高性能ストレージ（EFS層）でキャッシュされ、低レイテンシで応答
1 MiB以上の大きなファイルの読み取りはS3から直接ストリーミングされ、高スループットで処理

書き込みは約60秒間バッチングされてからS3にエクスポートされる仕組みです（後ほど実際に確認します）。また、EC2だけでなくAmazon Lambda・Amazon ECS・Amazon EKSなど幅広いAWSコンピュートリソースからアクセスできます。

docs.aws.amazon.com

Mountpoint for S3との比較

「S3をファイルAPIで使う」という観点では、以前から「Mountpoint for S3」というOSSが存在していました。名前が似ているのでどちらを使うべきか迷う方もいるのではないでしょうか。EFSも含めて3つを比較してみます。

観点	S3 Files	Mountpoint for S3	Amazon EFS
種別	AWSマネージドサービス	OSSクライアント（無料）	AWSマネージドサービス
アクセス方法	NFS v4.1/4.2	FUSE（独自ドライバ）	NFS v4.1
データの場所	S3バケットそのまま	S3バケットそのまま	EFS専用ストレージ
書き込みサポート	あり（約60秒遅延でS3に反映）	新規作成のみ（デフォルト）	あり
最大同時接続数	25,000	クライアント依存	制限なし（スループット依存）
S3 APIとの併用	可	可	不可
向いているケース	読み書き両方必要・本番利用	読み取り中心・コスト重視	S3と関係なくファイルシステムが欲しい
料金	S3料金 + Files利用分	S3料金のみ	EFS料金
パッケージ管理	AWSが管理（不要）	ユーザーが手動更新	AWSが管理（不要）

Mountpoint for S3はデフォルト状態では書き込みが制限されている（新規作成のみ）のに対し、S3 Filesは通常のファイル操作（上書き・削除・ディレクトリ作成）が可能です。

また、Mountpoint for S3はOSSのためバージョン管理は利用者側で行う必要がありますが、S3 Filesにはその必要がないという運用効率の良さもあります。

Mountpoint for S3は追加料金なしで使える分、コスト面では有利です。用途に合わせて使い分けるのが良いのではないかと思います。

前提条件と事前準備

実際に試す前に、以下の準備が必要です。

S3バケットのバージョニングを有効化 ： S3 Filesはバージョニングが必須です。既存バケットを使う場合はコンソールから有効化してください。バージョニングを有効化すると以降はオブジェクトのバージョン管理料金が発生する点に注意してください
IAMロールの設定 ： S3 FilesがバケットにアクセスするためのIAMロール（elasticfilesystem.amazonaws.com）と、EC2にアタッチするIAMロール（AmazonS3FilesClientFullAccess）の2種類が必要です。コンソールからファイルシステムを作成すると自動生成されます
amazon-efs-utils 3.0.0以上のインストール ：古いバージョンでは mount.s3files: command not found エラーが発生するようです
セキュリティグループの設定 ： EC2のアウトバウンドとマウントターゲット側のインバウンドで、それぞれTCP 2049（NFS）を許可する必要があります

実際にマウントしてみる

準備ができたら、CLIでファイルシステムを作成してマウントします。

まずファイルシステムを作成します。

aws s3files create-file-system \
  --bucket arn:aws:s3:::your-bucket-name \
  --role-arn arn:aws:iam::accountnumber:role/S3FilesRole

次にマウントターゲットを作成します。EC2と同じサブネット・セキュリティグループを指定します。マウントターゲットの作成には数分〜15分程度かかる場合があります。

aws s3files create-mount-target \
  --file-system-id fs-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --security-groups sg-xxxxxxxx

EC2インスタンスにSSM Session Managerで接続し、マウントします。

sudo mkdir -p /mnt/s3files
sudo mount -t s3files fs-xxxxxxxx:/ /mnt/s3files

df -h でマウントされていることが確認できれば完了です。

df -h の結果を見ると、サイズが 8.0E（8エクサバイト）と表示されました。S3の容量が事実上無制限のため、このような表示になるようです。コマンド3本でマウントまで到達できたのは想像より簡単でした。

動作確認：ファイルを書いてS3に反映されるか

実際にファイルを書いてS3に反映されるか確認してみます。

書き込み直後の aws s3 ls では何も表示されませんでしたが、60秒後に確認するとしっかり test-write.txt が表示されました。今回の検証では 07:12:02 に書き込んで、07:13:08 にS3へ反映されたことが確認できました。約66秒ですね。

逆に、S3に直接オブジェクトをアップロードした場合は通常数秒以内にファイルシステム側に反映されます（EventBridgeで変更を検知する仕組みです）。S3 APIとファイルAPIを同時に使えるのは便利だなと感じました。

ハマった及び懸念となりそうなポイント

実際に試してみて詰まった箇所をまとめます。

mount.s3files: command not foundが出る ： amazon-efs-utilsのバージョンが古い可能性があります。yum update amazon-efs-utils または公式のインストール手順でバージョン3.0.0以上に更新してください
マウントがタイムアウトする ：セキュリティグループのTCP 2049設定を見落としがちです。EC2アウトバウンドとマウントターゲットのインバウンド、両方の設定を確認してください
ファイルを書いてもS3に見えない ： 60秒のバッチエクスポートが仕様です。すぐにS3側から確認しようとすると混乱します。少し待ってから aws s3 ls で確認するのが正解です
ディレクトリのリネームに時間がかかる ：内部的には全オブジェクトのPUT+DELETEになるため、大量ファイルが入ったディレクトリのリネームはコストと時間の両方がかかるようです。大きなディレクトリ操作は慎重に行った方が良さそうです

リネームやバッチエクスポートに関する参考文献 docs.aws.amazon.com

おわりに

いかがでしたでしょうか。Amazon S3 Filesを使うと、S3バケットをそのままNFSマウントしてファイル操作感覚でアクセスできるようになります。

Mountpoint for S3と比べると書き込みやディレクトリ操作が自由にできる点が大きな違いで、読み書きが発生する本番ワークロードに向いているのではないかと思います。60秒の書き込み遅延や、バージョニング有効化によるコスト増など気にしておくべきポイントはありますが、S3 APIとファイルAPIを共存させて使えるのは管理の手間が省けて嬉しい仕様だと感じました。

まだ触れていない方はぜひ試してみてください。この記事が読んでいる皆様の参考になれば幸いです。