Amazon S3 Filesは、S3の汎用バケットをNFSのファイルシステムとしてEC2やLambda、ECS、EKSからマウントできるAWSの機能で、2026年4月7日に一般提供が始まりました。データの実体はS3バケットに残したまま、ファイル前提の既存アプリケーションから ls や cat で読み書きできます。この記事では、仕組みと前提条件を公式ドキュメントに沿って整理し、AWS CLIでのファイルシステム作成からマウント、fstabの自動マウント、Lambdaへの接続までをコマンド付きで扱います。60秒の書き戻しやリネームの負荷といった同期仕様の注意点、料金の内訳、Mountpoint for Amazon S3やAmazon EFSとの使い分けも判断基準としてまとめました。記載内容は2026年9月時点の公式情報に基づきます。
まとめ：S3 Filesの仕組みとマウント手順・採用判断の要点
S3 FilesはEFSの技術基盤の上に作られた「S3バケットのファイル窓口」です。よく使うデータだけを高性能ストレージへ取り込み、変更はS3へ新しいオブジェクトバージョンとして書き戻します。正本はあくまでS3バケットで、競合したときもS3側が勝ちます。
準備はバケットのバージョニング、2種類のIAMロール、TCP 2049番の3点。CLIで作成し、amazon-efs-utils 3.0.0以上を入れたEC2で mount -t s3files を打てば使えます。
採用の分かれ目は2つあります。既存ファイルの書き換えやリネームが必要ならMountpointではなくS3 Files。一方で、他システムがS3側を即時に読みに行く連携や、大量ファイルのディレクトリ移動を日常的に行う処理には向きません。そこではEFSを選ぶほうが素直です。
S3 Filesの仕組みとS3バケット・高性能ストレージ・マウントターゲットの関係
S3 Filesを理解する近道は、「どこにデータがあり、誰が同期しているか」を先に押さえることです。S3そのものの基本はAmazon S3の仕組みとストレージクラスの解説を前提とし、ここではファイルシステムとして見せる層だけを扱います。
EFS基盤の高性能ストレージにアクティブなデータだけを置く二層構造
構成要素は3つです。正本を持つS3汎用バケット、よく使うデータを置く高性能ストレージ（ファイルシステム）、VPC内の接続口であるマウントターゲット。コンピュートはマウントターゲットへNFSで接続し、ファイルシステムの裏でS3 Filesが双方向の同期を行います。
同期の仕組みを説明する公式ドキュメントによると、ディレクトリを初めて開いた時点でその配下の全ファイルのメタデータと、128KiB未満の小さなファイルのデータが取り込まれます。大きなファイルはメタデータだけが入り、読み出し時にS3から直接返されます。バケット全体を丸ごとコピーする仕組みではない点が、EFSへデータを移す従来の構成との違いです。
マウントはNFSv4.2で、TLSとIAM認証が常に有効になり、無効化できません。EC2へのマウント手順のページには、rsize・wsizeが1MiB、timeoが60秒といった既定のマウントオプションも一覧で載っています。
2026年4月のGAと同月のLambda対応で広がった対応コンピュート
AWS News Blogの発表記事では、2026年4月7日のGA時点で全商用リージョンに提供され、アクティブなデータへのレイテンシは約1ミリ秒とされています。接続できるのはEC2、ECS・EKSのコンテナ、Lambdaで、Lambda関数からのマウントは同じ4月のアップデートで案内されました。
EC2側の対応OSはAmazon Linux 2・2023、RHEL 8・9、Ubuntu 20.04・22.04・24.04、SLES 15などのLinuxに限られます。WindowsとmacOSからはマウントできません。Windowsのファイルサーバーを置き換えたい案件は、この時点で対象外です。
S3 Filesを使い始める前にそろえるバケット設定・IAMロール・通信経路
コンソールから作るとIAMロールやマウントターゲットは自動で用意されますが、CLIやIaCで作るならバケット・IAM・ネットワークの3か所を自分で揃えます。
バージョニング必須とSSE-S3・SSE-KMSに限られる暗号化の前提条件
S3 Filesの前提条件のページが挙げるバケット側の条件は2つです。S3のバージョニングが有効であること、暗号化がSSE-S3かSSE-KMSであること。対象は汎用バケットで、ディレクトリバケットは含まれません。
バージョニング必須は料金にも効きます。ファイルを編集するたびに旧版がS3に残るため、ライフサイクルルールで非現行バージョンの削除期限を決めておかないと、ストレージ容量が静かに積み上がります。既存バケットに後付けする場合は、S3側の課金を東京リージョンの単価で分解したS3料金の記事で見積もってから有効化すると安全です。
# バージョニングを有効化し、非現行バージョンを30日で削除するルールを入れる
BUCKET=my-s3files-bucket
aws s3api put-bucket-versioning --bucket $BUCKET \
--versioning-configuration Status=Enabled
aws s3api put-bucket-lifecycle-configuration --bucket $BUCKET \
--lifecycle-configuration '{"Rules":[{"ID":"expire-noncurrent","Status":"Enabled",
"Filter":{},"NoncurrentVersionExpiration":{"NoncurrentDays":30}}]}'30日という値は例です。誤編集からの復旧をどこまで遡れればよいかで決めてください。
同期用ロールとコンピュート用ロールに分かれる2種類のIAM権限
IAMロールは用途別に2本要ります。1本目はS3 Filesがバケットを読み書きするための同期用ロールで、信頼ポリシーのプリンシパルは elasticfilesystem.amazonaws.com です。インラインポリシーにはS3のオブジェクト操作に加え、同期の起点になるEventBridgeルールの管理権限が含まれます。
# 同期用ロールの信頼ポリシー（ACCOUNT_IDとREGIONを置き換える）
cat > trust.json <<'EOF'
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowS3FilesAssumeRole",
"Effect": "Allow",
"Principal": { "Service": "elasticfilesystem.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "aws:SourceAccount": "ACCOUNT_ID" },
"ArnLike": { "aws:SourceArn": "arn:aws:s3files:REGION:ACCOUNT_ID:file-system/*" }
}
}]
}
EOF
aws iam create-role --role-name S3FilesSyncRole \
--assume-role-policy-document file://trust.json2本目はEC2のインスタンスプロファイルやLambdaの実行ロールに付けるコンピュート用ロールです。読み書きならAWS管理ポリシー AmazonS3FilesClientFullAccess、読み取り専用なら AmazonS3FilesClientReadOnlyAccess を付け、さらにバケットへの s3:GetObject と s3:GetObjectVersion を許可します。後者は大きなファイルをS3から直接読むための権限で、この経路ではPOSIXのパーミッションではなくIAMとバケットポリシーでアクセスが決まります。
TCP 2049番を双方向で許可するマウントターゲットとEC2のセキュリティグループ
通信経路で詰まるのはほぼセキュリティグループです。EC2側はマウントターゲットのセキュリティグループ宛てにTCP 2049番のアウトバウンド、マウントターゲット側はEC2のセキュリティグループからのTCP 2049番のインバウンドを許可します。
もう1つの条件が、EC2とマウントターゲットを同じアベイラビリティゾーンに置くことです。マウントターゲットはAZごとに作るため、複数AZにまたがるAuto Scalingグループで使うなら、各AZのサブネットに1つずつ用意します。
AWS CLIでファイルシステムを作成しEC2へマウントするまでの作業手順
ここからは実際のコマンドです。AWS CLIは s3files サブコマンドを持つ2系の新しい版を使います（2026年9月時点のリファレンスは2.37.1版）。
バケットと同期用ロールを指定してファイルシステムと接続口を作る手順
CLIでは create-file-system と create-mount-target を使い、ファイルシステムとマウントターゲットを順に作ります。create-file-systemのリファレンスでは、必須引数は --bucket（バケットARN）と --role-arn の2つで、--prefix を付けるとバケット内の特定プレフィックスだけをファイルシステムにできます。
# 1) ファイルシステムを作成（prefixを付けるとその配下だけが対象になる）
REGION=ap-northeast-1
FS_ID=$(aws s3files create-file-system --region $REGION \
--bucket arn:aws:s3:::my-s3files-bucket \
--prefix projects/ \
--role-arn arn:aws:iam::123456789012:role/S3FilesSyncRole \
--query fileSystemId --output text)
# 2) 状態がAVAILABLEになるまで確認
aws s3files get-file-system --region $REGION --file-system-id $FS_ID \
--query status --output text
# 3) EC2と同じAZのサブネットにマウントターゲットを作成
aws s3files create-mount-target --region $REGION \
--file-system-id $FS_ID \
--subnet-id subnet-0123456789abcdef0 \
--security-groups sg-0123456789abcdef0オブジェクト数が非常に多いプレフィックスを指定すると、作成時にエラーで止まります。ディレクトリのリネームに最大4時間（約1,200万オブジェクト）かかる規模が目安で、承知のうえで進めるなら --accept-bucket-warning を付けます。この警告が示す負荷の詳細は、後の同期仕様の章で説明する内容です。
amazon-efs-utils 3.0.0以上でEC2へマウントする手順
EC2側にはマウントヘルパーを含む amazon-efs-utils の3.0.0以上が必要です。EFSと共通のクライアントで、インストールすると s3files というファイルシステム種別が使えるようになります。接続時は、次の例のように mount -t s3files でこの種別を指定してください。
# Amazon Linuxの場合
sudo yum -y install amazon-efs-utils
# マウントポイントを作ってマウント
FS_ID=fs-0123456789abcdef0
sudo mkdir -p /mnt/s3files
sudo mount -t s3files $FS_ID:/ /mnt/s3files
# 確認（Sizeは8.0Eと表示される）
df -h /mnt/s3files
findmnt -T /mnt/s3files
ls /mnt/s3filesUbuntuなど他のディストリビューションでは、公式のインストーラースクリプトかGitHubのREADMEの手順で入れます。CloudWatchでマウント状態を監視するなら botocore も追加します。
fstabに_netdevとnofailを付けて再起動後も自動マウントする設定
再起動後もマウントを維持するには /etc/fstab に1行足します。公式ドキュメントが警告しているのが _netdev の付け忘れで、これが無いとネットワーク初期化前にマウントを試みてインスタンスが応答しなくなることがあります。
# /etc/fstab に追記する行（本番はnofailも付ける）
fs-0123456789abcdef0:/ /mnt/s3files s3files _netdev,nofail 0 0
# アクセスポイント経由でマウントする場合
fs-0123456789abcdef0:/ /mnt/s3files s3files _netdev,nofail,accesspoint=fsap-0123456789abcdef0 0 0
# 反映の確認
sudo mount -a
findmnt -T /mnt/s3filesnofail はマウントに失敗しても起動を続けるオプションです。ファイルシステム側の障害でインスタンスごと起動できなくなる事態を避けられます。
Lambda関数へアクセスポイント経由で接続するときのVPCとメモリの条件
Lambdaから使う場合は、関数をマウントターゲットと同じVPCに置き、デプロイ先の各サブネットにマウントターゲットを用意します。LambdaのS3 Files設定ページによると、マウントパスは /mnt/ で始める必要があり、アクセスポイントが無いファイルシステムを選ぶと、UID・GIDが1000:1000、ルートが /lambda、パーミッション755のアクセスポイントが自動で作られます。
実行ロールには s3files:ClientMount と、書き込むなら s3files:ClientWrite が要ります。大きなファイルをS3から直接読む Direct S3 Reads は、既定の AUTO では、有効になる対象はメモリ512MB以上の関数だけです。512MB未満の関数では読み取りがすべて高性能ストレージ経由になるため、大きなファイルを扱う関数はメモリを512MB以上にするか、設定値を ENABLED にします。Lambda側のVPC接続やコールドスタートの前提はAWS Lambdaの仕組みと採用判断の解説にまとめています。
同期の挙動で詰まりやすい60秒の書き戻し・リネーム・競合時の退避
落とし穴はマウント手順より同期の仕様にあります。ファイルとして見えている状態と、S3のオブジェクトに反映された状態の間には時間差があります。
書き込み停止から60秒後にS3へ書き戻す仕様と他システム連携の時間差
ファイルを変更すると、S3 Filesは書き込みが60秒止まるのを待ってからS3へ書き出します。30秒ごとに追記を5分間続けるログなら、S3への書き出しが始まるのは6分目です。連続した書き込みが1回のPUTにまとまるため、リクエスト料金とバージョン数は抑えられます。
裏返すと、S3のイベント通知でLambdaを起動する既存のパイプラインは、ファイル保存から最低でも1分遅れて動きます。逆方向のS3からファイルシステムへの反映はS3イベント通知が起点で、高性能ストレージにデータがあるファイルだけが更新されます。
ディレクトリのリネームがオブジェクト数だけコピーと削除を発生させる負荷
S3にはディレクトリもアトミックなリネームもありません。そのため mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta はファイルシステム上では一瞬で終わっても、S3側では配下のオブジェクトを1つずつ新しいキーへコピーして元を消します。1,000万ファイルのディレクトリなら、1,000万回のコピーと削除のリクエストが発生します。
処理中はS3側に alpha/ と beta/ の両方が存在し、リネーム後に旧パスへ書かれたオブジェクトは移動されません。作成時の警告は、この負荷を事前に知らせるための仕組みです。日付ディレクトリを毎日リネームしてローテーションするような運用は、S3 Filesに載せる前に書き方を変えるべきです。
S3側の更新が優先され編集中のファイルがlost+foundへ退避される競合処理
同じファイルをファイルシステムで編集している間に、別のアプリケーションがS3へ新しい版をアップロードすると競合になります。このときS3 Filesはバケット側を正とし、ファイルシステム側の版を .s3files-lost+found-ファイルシステムID というディレクトリへ移して、S3の最新版を取り込みます。
退避されたファイルはS3へ同期されず、消すまで残り続け、ファイルシステムのストレージ料金に数えられます。アクセスポイントでルートを絞ってマウントしているとこのディレクトリは見えません。ファイル側とS3 API側の両方から同じキーを書く設計は、最初から避けるのが無難です。
128KiBの取り込み閾値と30日未読で高性能ストレージから外れるデータ
高性能ストレージに入るのは、既定では128KiB未満のファイルと実際に読まれたデータです。30日間読まれず、かつS3への同期が済んだファイルはデータ部分だけが外され、名前・サイズ・パーミッションなどのメタデータは残ります。次に読んだときはS3から取り直すため、初回だけ遅くなります。
閾値と保持日数はどちらも変更できます。同じ小ファイルを繰り返し読む処理なら閾値を上げ、大きなファイルを順番に流し読む処理なら下げるほうが料金面で有利です。
S3 Filesの料金を高性能ストレージと1MiB以上の直接読み取りで見積もる方法
料金はS3バケット側の通常の課金に、S3 Files固有の課金が上乗せされる形です。固有分は「高性能ストレージに置かれた容量」と「高性能ストレージへの読み書き量」の2種類で、プロビジョニングや最低利用料金はありません。
0.30USD／GB月の高性能ストレージと読み書き単価の内訳
S3の料金ページのS3 Filesの計算例（米国西部オレゴン）では、単価と対象は次のとおりです。
| 課金項目 | 単価（オレゴンの例） | 対象 |
|---|---|---|
| 高性能ストレージ | 0.30USD／GB月 | 取り込まれている容量 |
| 書き込み | 0.06USD／GB | ファイル書き込みとS3からの取り込み |
| 読み取り | 0.03USD／GB | 小さな読み取りとS3への書き戻し |
| 1MiB以上の読み取り | S3のGET料金のみ | S3から直接返す読み取り |
公式の例では、高性能ストレージ0.85GBと書き込み1GBほどの小さな構成で、S3 Files分の月額は0.3765USDです。1MiB以上の大きな読み取りは高性能ストレージにデータがあってもS3から直接返され、S3 Files固有の料金はかかりません。
東京リージョンの単価は料金ページのリージョン切り替えで確認してください。執筆時点でAWS Price List APIの東京リージョンのオファーファイル（AmazonS3・AmazonEFS）を確認したところ、S3 Files名義の項目は見当たりませんでした。見積もりで効くのは単価より容量の見立てです。高性能ストレージの容量は、直近30日に読まれたデータと128KiB未満のファイルの合計でおおむね決まるので、まずこの量を既存アプリのアクセス傾向から見積もり、稼働後はCloudWatchメトリクスで実際の容量と突き合わせます。
S3 Filesの書き換え要件と正本の置き場所による使い分け・採用しない条件
S3をファイルとして扱う手段は、S3 Filesの登場で3つになりました。ここでは、S3 Files・Mountpoint for Amazon S3・Amazon EFSを比較対象とします。どれが上位互換という関係ではなく、書き換えの有無と正本の置き場所で選び分けます。
既存ファイルの書き換えとリネームの要否で決まるMountpointとの境界線
Mountpoint for Amazon S3の公式ドキュメントは、既存ファイルの変更・ディレクトリ削除・シンボリックリンク・ファイルロックに対応しないと明記しています。GitHubで公開されているOSSで、料金はS3のリクエストと転送だけです。
| 観点 | S3 Files | Mountpoint | Amazon EFS |
|---|---|---|---|
| 正本の置き場所 | S3バケット | S3バケット | EFS |
| 既存ファイルの書き換え | 可 | 不可 | 可 |
| リネーム | 可（S3側は複製と削除） | 制限あり | 可 |
| S3 APIからの直接参照 | 可（最低60秒遅れ） | 可 | 不可 |
| 追加の料金 | 高性能ストレージと読み書き | なし | EFSの容量と読み書き |
読み取り中心の機械学習の学習データやETLの入力なら、今でも最も安く済む選択肢はMountpointです。設定ファイルの書き換えや、ファイルを開いて上書き保存する業務アプリをS3上のデータで動かしたい場合に、S3 Filesの出番が来ます。EFSそのものの特徴はAWS EFSとS3・EBS・FSxの違いの解説で比較しています。
S3 Filesを採用せずEFSやS3 APIの直接利用を選ぶべき3つの場面
S3 Filesを選ばないほうがよい場面ははっきりしています。
- S3へ置いた直後に別システムが読みに行く連携：60秒の書き戻し待ちが処理時間に乗る。S3 APIで直接PUTするほうが確実
- 大量ファイルのディレクトリ移動を日常的に行う処理：リネームのたびにオブジェクト数分のリクエストが発生する。正本をEFSに置く
- 同じファイルをファイル側とS3 API側の両方から更新する設計：S3側が優先され、編集がlost+foundへ退避される
逆に、S3に溜めたデータを動かさずに、ファイル前提の既存アプリケーションやスクリプトから触りたいという要件には、S3 Filesがいちばん移行量の少ない選択です。コピー先のEFSを別に持つ構成からの置き換えも候補になります。既存システムのストレージ構成を見直す段階で判断に迷う場合は、AWSを含むクラウドのインフラ構築支援で、現行のデータ量とアクセスの傾向から構成案を作ることもできます。
よくある質問
S3 Filesについて、導入検討の段階で出やすい質問をまとめました。
S3 FilesとMountpoint for Amazon S3は何が違いますか？
最大の違いは書き換えの可否です。Mountpointは既存ファイルの変更やディレクトリ削除、ファイルロックに対応しない一方、S3 FilesはEFSの基盤を挟むことでファイルの上書きやリネームを含む操作に対応します。その代わり、S3 Filesには高性能ストレージの容量と読み書きの料金がかかります。読み取り中心ならMountpoint、書き換えが要るならS3 Filesという切り分けが基本です。
S3 FilesはWindowsのEC2からマウントできますか？
できません。対応OSはAmazon LinuxやRHEL、UbuntuなどのLinuxに限られ、WindowsとmacOSは対象外です。WindowsからS3のデータをファイル共有として扱いたい場合は、FSx for Windows File ServerやStorage Gatewayなど別の手段を検討してください。
S3 Filesを使うにはバケットのバージョニングが必須ですか？
必須です。S3 Filesはファイルの変更を新しいオブジェクトバージョンとして書き戻し、削除は削除マーカーとして記録します。編集のたびに旧版が残るため、非現行バージョンを一定日数で消すライフサイクルルールも合わせて入れておくと安全です。
S3 Filesでファイルを保存するとS3にはいつ反映されますか？
書き込みが60秒間止まった時点で、S3への書き出しが始まります。書き続けている間は書き出されないため、追記を続けるログファイルなら最後の追記から1分後です。S3のイベント通知を起点にした後続処理は、この待ち時間を前提に組む必要があります。反対方向の、S3 APIで更新したオブジェクトは、S3イベント通知を受けてファイルシステムへ反映されます。
S3 Filesの料金はS3の料金とは別にかかりますか？
S3の通常料金とは別に必要な費用です。S3バケットの保存料金とリクエスト料金に加え、高性能ストレージに取り込まれた容量（オレゴンの例で0.30USD／GB月）と、そこへの書き込み・読み取りの料金が上乗せされます。1MiB以上の大きな読み取りはS3から直接返され、課金対象はS3のGET料金だけです。固有分の月額は、直近30日に読まれたデータと小さなファイルの容量でおおむね決まります。
関連記事
- Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説：S3 Filesの正本となるS3そのものの基礎
- AWS EFS（Amazon Elastic File System）とは？S3・EBS・FSxとの違い・料金・使い方を解説：S3 Filesの基盤技術で、正本をファイル側に置く選択肢
- S3の料金を実額で計算する｜東京リージョンの単価内訳とコストを下げる設定手順：バケット側で発生する課金の内訳
- Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説：マウント先となるインスタンスの選び方
- Amazon S3 Tablesとは何か？その概要と基本概念：S3のデータを表形式で扱う別のインターフェース
