Amazon S3 Files GA — S3バケットをNFSファイルシステムとしてマウントできる時代が来た

AWSAmazon S3S3 FilesNFSEFSファイルシステムストレージ
Announcing Amazon S3 Files, making S3 buckets accessible as file systems - AWS Discover more about what aws.amazon.com
Launching S3 Files, making S3 buckets accessible as file systems | Amazon Web Services Amazon S3 Files makes S3 buckets accessible as high-performance file systems on AWS compute resource... aws.amazon.com
Working with Amazon S3 Files - Amazon Simple Storage Service Learn how to use Amazon S3 Files to access your S3 data as a shared file system with low-latency per... docs.aws.amazon.com
Amazon S3 Files aws.amazon.com

Amazon S3 Filesが全商用リージョンで一般提供（GA）になりました（2026年4月7日 AWS What’s New）。S3バケットをNFS v4.1/4.2でマウントし、通常のファイルシステムとしてアクセスできるようになります。

S3がオブジェクトストアであるという前提は、2006年のローンチ以来ずっと変わっていませんでした。PUT/GETのAPI経由でしかデータにアクセスできない。ファイルパスで open → read → write → close するような操作はできない。この制約のために、ファイルシステムが必要なワークロードではEFSやFSxにデータをコピーして使うのが当たり前でした。S3 Filesはこの前提を根本から変えるアップデートです。

S3とファイルシステムの間にあった溝

これまで、S3のデータをファイルシステムとして使いたい場合の選択肢はどれも一長一短でした。

EFSにコピーして使う。これが最も一般的なパターンです。S3上のデータレイクからEFSに同期パイプラインを構築し、EC2やコンテナからNFSマウントでアクセスする。ファイルシステムとしては完全に動作しますが、データを二重に持つことになり、同期の仕組みも必要になります。EFSのストレージ料金はS3 Standardの約13倍（$0.30/GB vs $0.023/GB、us-east-1の場合）なので、コスト面でも無視できません。

Mountpoint for S3を使う方法もありました。FUSEベースのクライアントでS3バケットをマウントできますが、実質的に読み取り中心の用途に限られます。ファイルロックやPOSIXパーミッション、read-after-write一貫性はサポートされず、複数クライアント間での協調的なアクセスも困難でした。

s3fs-fuseはコミュニティ製のFUSEマウントツールですが、パフォーマンスや安定性に課題がありました。

ML学習やAIエージェントのワークロードでは、この問題が特に顕著です。PyTorchの ImageFolder("/mnt/data/train/") のように、フレームワークがファイルパスを前提に設計されています。数百万ファイルの学習データをS3 APIで1つずつダウンロードしてローカルに保存するのは非現実的なので、結局EFSにコピーするしかありませんでした。

S3 Filesの仕組み

S3 Filesは、S3バケットに対してNFS v4.1/4.2のファイルシステムインターフェースを提供します。裏側ではAmazon EFSの基盤を使っており、高性能ストレージ層がキャッシュとして機能します。

公式ブログには以下のように記載されています（2026年4月7日 AWS News Blog）。

With S3 Files, Amazon S3 is the first and only cloud object store that offers fully-featured, high-performance file system access to your data. It makes your buckets accessible as file systems. This means changes to data on the file system are automatically reflected in the S3 bucket and you have fine-grained control over synchronization.

つまり、データの実体はS3に残ったまま、ファイルシステムとしてのアクセスが可能になります。ファイルシステム上での変更はS3バケットに自動的に反映され、同期の粒度も制御できるとのことです。

アーキテクチャ

S3 Filesのアーキテクチャは3つの要素で構成されます。

  1. ファイルシステム: S3バケット（またはプレフィックス）に紐づくリソース。S3オブジェクトをファイルとディレクトリとして表現します
  2. マウントターゲット: VPC内のAZごとに配置されるネットワークエンドポイント。EC2やLambdaからのNFS接続を受け付けます
  3. アクセスポイント: アプリケーションごとのエントリポイント。UID/GIDの強制やルートディレクトリの制御が可能です

接続できるコンピュートリソースは以下のとおりです。

  • Amazon EC2
  • AWS Lambda
  • Amazon ECS / Amazon EKS（Fargate含む）
  • AWS Batch

最大25,000の同時接続をサポートします。

データの流れとキャッシュ戦略

S3 Filesの特徴的な設計は、ファイルサイズに基づくインテリジェントなルーティングです。

  • 128KB以下のファイル: 高性能ストレージ（EFS基盤のキャッシュ層）にロードされ、サブミリ秒〜1桁ミリ秒のレイテンシで提供されます
  • 128KBを超えるファイル: S3から直接ストリーミングされ、最大テラバイト/秒のスループットが得られます

このしきい値（128KB）はデフォルト値で、同期設定によりカスタマイズ可能です。自分が検証した環境でも、デフォルトの同期設定で sizeLessThan: 131072（128KB）が確認できました（後述）。

高性能ストレージ上のデータには有効期限も設定されています。デフォルトは30日で、その間アクセスがないデータは自動的に高性能ストレージから削除されます。ただし、S3上の権威データは常に保持されます。

同期モデル

S3 Filesは双方向の自動同期を行います。

  • インポート（S3 → ファイルシステム）: ディレクトリへの初回アクセス時にメタデータとファイルが取り込まれます
  • エクスポート（ファイルシステム → S3）: ファイルシステム上での変更は数分以内にS3バケットに反映されます

公式ブログの記述によると、S3バケットへの直接変更はファイルシステムに数秒〜1分程度で反映されるとのことです。

When I make updates to my files in the file system, S3 automatically manages and exports all updates as a new object or a new version on an existing object back in my S3 bucket within minutes.

Changes made to objects on the S3 bucket are visible in the file system within a few seconds but can sometimes take a minute or longer.

セキュリティ

  • 認証・認可: IAMベースのアクセス制御とPOSIXパーミッション（UID/GID）の両方をサポート
  • 暗号化: 転送中はTLS 1.3、保管時はSSE-S3またはSSE-KMS（カスタマーマネージドキー可）
  • モニタリング: CloudWatchメトリクスとCloudTrailによるログ記録

CLIで試してみる

ここからは実際にAWS CLIでS3 Filesを操作してみた結果です。

  • AWS CLI: 2.34.27
  • リージョン: ap-northeast-1
  • 対応CLIバージョン: 2.34.26以降（2026年4月頃 CHANGELOG 2.34.26）

利用可能なサブコマンド

aws s3files の下に以下のサブコマンドが用意されています。

$ aws s3files help

AVAILABLE COMMANDS
  create-access-point
  create-file-system
  create-mount-target
  delete-access-point
  delete-file-system
  delete-file-system-policy
  delete-mount-target
  get-access-point
  get-file-system
  get-file-system-policy
  get-mount-target
  get-synchronization-configuration
  list-access-points
  list-file-systems
  list-mount-targets
  list-tags-for-resource
  put-file-system-policy
  put-synchronization-configuration
  tag-resource
  untag-resource
  update-mount-target

EFSのCLI構成とかなり似ていることが分かります。create-file-system + create-mount-target の2段階構成、access-point の概念、file-system-policy など、EFSの設計思想をそのまま踏襲しています。

前提条件: バケットのバージョニングが必須

ファイルシステムを作成するには、対象バケットでバージョニングが有効になっている必要があります。バージョニングを有効にせずに create-file-system を実行すると、以下のエラーになります。

$ aws s3files create-file-system \
    --bucket arn:aws:s3:::my-bucket \
    --role-arn arn:aws:iam::123456789012:role/S3FilesTestRole \
    --region ap-northeast-1 \
    --profile your-profile

An error occurred (ValidationException) when calling the CreateFileSystem operation:
Your bucket must have versioning enabled to create a file system.

バージョニングを有効にしてから再実行します。

$ aws s3api put-bucket-versioning \
    --bucket my-bucket \
    --versioning-configuration Status=Enabled \
    --profile your-profile

IAMロールの設定

S3 Filesがバケットにアクセスするために、専用のIAMロールが必要です。ここでポイントなのは、サービスプリンシパルが s3files.amazonaws.com ではなく elasticfilesystem.amazonaws.com であることです。S3 Filesの内部基盤がEFSであることがここにも表れています。

信頼ポリシーは以下のとおりです（2026年4月 AWS Documentation）。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3FilesAssumeRole",
            "Effect": "Allow",
            "Principal": {
                "Service": "elasticfilesystem.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:s3files:ap-northeast-1:123456789012:file-system/*"
                }
            }
        }
    ]
}

SourceAccount と SourceArn の条件で、自アカウント・自リージョンのS3 Filesからのみ引き受けを許可しています。Confused Deputy対策として適切な設計です。

許可ポリシーには、S3バケットへのアクセス権限に加えて、EventBridgeの操作権限も必要です。S3 Filesが同期のためにEventBridgeルールを管理するためです。

ファイルシステムの作成

$ aws s3files create-file-system \
    --bucket arn:aws:s3:::my-bucket \
    --role-arn arn:aws:iam::123456789012:role/S3FilesTestRole \
    --region ap-northeast-1 \
    --profile your-profile

{
    "creationTime": "2026-04-10T14:49:34+09:00",
    "fileSystemArn": "arn:aws:s3files:ap-northeast-1:123456789012:file-system/fs-0123456789abcdef0",
    "fileSystemId": "fs-0123456789abcdef0",
    "bucket": "arn:aws:s3:::my-bucket",
    "prefix": "",
    "clientToken": "34778a55-a1f0-474e-a700-7d2a3cf6cc84",
    "status": "creating",
    "roleArn": "arn:aws:iam::123456789012:role/S3FilesTestRole",
    "ownerId": "123456789012",
    "tags": []
}

ファイルシステムIDは fs- で始まる形式で、EFSと同じプレフィックスです。ただしARNは s3files サービスのものになっています。

status は作成直後は creating ですが、数秒で available に変わりました。

$ aws s3files get-file-system \
    --file-system-id fs-0123456789abcdef0 \
    --region ap-northeast-1 \
    --profile your-profile

{
    "creationTime": "2026-04-10T14:49:34+09:00",
    "fileSystemArn": "arn:aws:s3files:ap-northeast-1:123456789012:file-system/fs-0123456789abcdef0",
    "fileSystemId": "fs-0123456789abcdef0",
    "bucket": "arn:aws:s3:::my-bucket",
    "prefix": "",
    "clientToken": "34778a55-a1f0-474e-a700-7d2a3cf6cc84",
    "status": "available",
    "roleArn": "arn:aws:iam::123456789012:role/S3FilesTestRole",
    "ownerId": "123456789012",
    "tags": []
}

同期設定の確認

デフォルトの同期設定を確認してみます。

$ aws s3files get-synchronization-configuration \
    --file-system-id fs-0123456789abcdef0 \
    --region ap-northeast-1 \
    --profile your-profile

{
    "latestVersionNumber": 0,
    "importDataRules": [
        {
            "prefix": "",
            "trigger": "ON_DIRECTORY_FIRST_ACCESS",
            "sizeLessThan": 131072
        }
    ],
    "expirationDataRules": [
        {
            "daysAfterLastAccess": 30
        }
    ]
}

ここで注目すべきは3点です。

  1. trigger: ON_DIRECTORY_FIRST_ACCESS: ディレクトリに初めてアクセスした時点でインポートが走る
  2. sizeLessThan: 131072: 128KB未満のファイルのみ高性能ストレージにロードされる（ドキュメントの記述と一致）
  3. daysAfterLastAccess: 30: 30日間アクセスがないデータは高性能ストレージから期限切れになる

この設定は put-synchronization-configuration で変更可能です。しきい値を大きくすればより多くのファイルがキャッシュされますが、高性能ストレージの料金が増えるトレードオフがあります。

コンソールとCLIの違い

公式ブログのチュートリアルでは、コンソールからファイルシステムを作成するとマウントターゲットが自動的に作成されると記載されています。しかしCLIでは自動作成されません。

$ aws s3files list-mount-targets \
    --file-system-id fs-0123456789abcdef0 \
    --region ap-northeast-1 \
    --profile your-profile

{
    "mountTargets": []
}

CLIの場合は create-mount-target で明示的にサブネットを指定して作成する必要があります。EC2インスタンスと同じAZのサブネットを指定する点に注意してください。

料金

S3 Filesの料金は以下の要素で構成されます（2026年4月時点 S3 Pricing）。

項目概要
高性能ストレージキャッシュ層に保持されたデータに対するGB単位の課金（$0.30/GB）
ファイルシステムアクセス高性能ストレージへの読み書きに対するGB単位の課金
S3リクエスト同期時のS3 GET/PUTリクエスト（通常のS3料金）

「高性能ストレージ」はS3 Files内部のキャッシュ層で、EFSの基盤技術を使って構築されています。ユーザーが別途EFSファイルシステムを作るわけではなく、S3 Filesが自動的に管理する仕組みです。単価はEFS Standardと同じ $0.30/GB ですが、S3 Filesの場合はアクティブなワーキングセットのみがこの料金の対象になります。使われていないデータは30日（デフォルト）で自動的に高性能ストレージから削除され、S3のストレージ料金（$0.025/GB、ap-northeast-1）のみで維持されます。

公式ページでは「S3と別のファイルシステム間でデータを循環させる場合と比較して最大90%のコスト削減」と謳っています（2026年4月 Amazon S3 Files Feature Page）。

S3 Files delivers up to 90% lower costs compared to cycling data between S3 and separate file systems.

この「90%削減」の意味を、具体的な数字で見てみます。1TBのデータセットがあり、日常的にアクセスするのはそのうち100GBだけ、というケースを考えます（us-east-1の料金で試算）。

従来（S3 + EFSにコピー）:

項目容量単価月額
S3 Standard（データレイク）1TB$0.023/GB$23.55
EFS Standard（NFSマウント用コピー）1TB$0.30/GB$307.20
合計$330.75

S3 Files:

項目容量単価月額
S3 Standard（データの実体）1TB$0.023/GB$23.55
高性能ストレージ（キャッシュ層）100GB$0.30/GB$30.72
合計$54.27

EFSでは1TB全量をコピーするので $330/月。S3 Filesではアクティブな100GBだけがキャッシュ層に乗るので $54/月。差額は約 84%削減 です。アクティブデータの割合が小さいほど削減率は大きくなり、「最大90%」という数字に近づきます。

EFS・FSx・Mountpointとの使い分け

S3 Filesの登場で、AWSのファイルシステム系サービスの選択肢がさらに増えました。公式ブログでも使い分けについて言及されています。

サービス適したユースケース
S3 FilesS3上のデータにファイルシステムとしてアクセスしたい。複数のコンピュートリソースから共有アクセスが必要。データの実体はS3に置きたい
Amazon EFSファイルシステムがプライマリストレージ。S3とのデータ同期が不要な純粋なNFSワークロード
Amazon FSxオンプレからの移行（ONTAP、Windows File Server）やHPC/GPUクラスタ（Lustre）
Mountpoint for S3S3データの読み取り中心のワークロード。ファイルロックや書き込み一貫性が不要な場合

自分の印象としては、「データがS3にあり、そこからファイルシステムとして使いたい」ケースの多くがS3 Filesのカバー範囲に入ると思います。逆に、S3を介さない純粋なNFSストレージが必要な場合はEFSのほうが適切です。

Terraform対応

Terraform AWS Provider v6.40.0（2026年4月8日リリース）で、S3 Files関連のリソースが追加されています。

データソースとして aws_s3files_file_systems も用意されています。GA翌日にTerraform対応が出たのは、事前にAWSと連携して準備していたものと思われます。

EFSと比べたときのデメリット

S3 Filesは「安いEFS」ではありません。アーキテクチャが異なる以上、EFSにはないトレードオフがあります。導入前に理解しておくべきポイントをまとめます。

レイテンシの一貫性

EFSは全ファイルに対してサブミリ秒のレイテンシを提供します。S3 Filesの場合、高性能ストレージにキャッシュされたファイルはサブミリ秒ですが、キャッシュに載っていないファイルへのアクセスはS3へのGETが走るため数十ms程度のレイテンシになります。

たとえばWebアプリケーションのように、多数の小さなファイルへのランダムアクセスが頻繁に発生するワークロードでは、キャッシュヒット率によってレスポンスタイムにばらつきが出ます。レイテンシの予測可能性が重要なケースでは、EFSのほうが安定します。今回はローカルからのマウントができないため実測は行えていませんが、この点は本番導入前に必ずベンチマークを取るべきだと思います。

同期の遅延

EFSでは書き込んだ瞬間から他のクライアントでデータが読めます。S3 Filesでは双方向の同期に遅延があります。

  • ファイルシステム → S3バケット: 数分以内
  • S3バケット → ファイルシステム: 数秒〜1分以上

これはデュアルアクセス（NFSとS3 APIの両方から同じデータにアクセスする）を前提としたワークロードで問題になります。「ファイルシステム経由で書き込んだデータを、別のプロセスがS3 APIで即座に読む」ような処理フローは成立しません。

全データにアクセスするケースではコスト増

コスト試算の節で見たとおり、削減効果はアクティブデータが全体の一部であることが前提です。ワークロードがデータセットの大部分に頻繁にアクセスする場合、高性能ストレージにほぼ全データが載ることになり、$0.30/GB のキャッシュ層 + $0.023/GB のS3ストレージで、EFS単体（$0.30/GB）よりむしろ高くなります。

バケットのバージョニングが必須

検証でも確認しましたが、S3 Filesの利用にはバケットのバージョニングを有効にする必要があります。オブジェクトの上書きや削除時に旧バージョンが残り続けるため、ライフサイクルルールで非現行バージョンの削除を設定しないと、ストレージ料金が意図せず膨らみます。

オンプレミスからのアクセス不可

EFSはVPN/Direct Connect経由でオンプレミスからマウントできますが、S3 FilesはAWSコンピュートリソース（EC2, Lambda, ECS, EKS）からのみアクセス可能です。ハイブリッド構成でオンプレミスからファイルシステムアクセスが必要な場合は、引き続きEFSまたはAWS Storage Gatewayが選択肢になります。

まとめ

S3 Filesは「S3にファイルシステムの顔を付けた」サービスです。データの実体はS3に残したまま、NFS v4.1/4.2でマウントできる。EFS基盤のキャッシュ層で低レイテンシアクセスを実現しつつ、ラージファイルはS3から直接ストリーミングする。このインテリジェントなルーティングが、コストとパフォーマンスのバランスを取る鍵になっています。

ただし、EFSの代替として無条件に置き換えられるものではありません。レイテンシの一貫性、同期遅延、アクティブデータ比率によるコスト構造の違い。これらのトレードオフを理解した上で、自分のワークロードに合うかどうかを判断する必要があります。「S3にデータがあり、その一部をファイルシステムとして使いたい」ケースでは最適な選択肢になる一方、「全データに均一な低レイテンシでアクセスしたい」ケースではEFSのほうが適切です。

サービスプリンシパルが elasticfilesystem.amazonaws.com であること、バケットのバージョニングが必須であること、CLIではマウントターゲットが自動作成されないこと。こうした実装の細部に、EFSの上に構築されたサービスであることが透けて見えます。パケットの流れを追うと、EC2 → VPC内のマウントターゲット（NFS） → EFS基盤のキャッシュ層 → S3、という経路が見えてきます。この構成を理解しておくと、トラブルシューティングの際にも役立つと思います。