icon/copy-url

favicon-32x32

logo-2x

IT Consulting | Outsourcing | Vietnam

**For 20 years, S3 was not a file system.**

That sentence shaped an entire generation of cloud architecture. If your application needed POSIX paths, you reached for EFS, FSx, or a third-party hack like s3fs-fuse. If you wanted cheap, durable, infinitely scalable object storage, you used S3 and rewrote your code to speak the REST API.

On April 7, 2026, AWS [launched Amazon S3 Files](https://aws.amazon.com/blogs/aws/launching-s3-files-making-s3-buckets-accessible-as-file-systems/). Any general-purpose S3 bucket can now be mounted as a native NFS v4.1 file system from EC2, ECS, EKS, or Lambda. It went GA in 43 regions on day one.

This is the biggest change to how teams interact with S3 since the service launched. At INNOMIZE, we're still in the early days of analyzing it and thinking through where it could fit in the client workloads we run. Here's the deep dive so far.

## What S3 Files is

S3 Files is not a rewrite of S3. It is a managed file-system layer that sits in front of an existing bucket, speaks NFS v4.1, and keeps the bucket as the source of truth.

Key properties:

- **Not a new bucket type.** You point S3 Files at a general-purpose bucket you already own.
- **Objects stay objects.** Files written through the NFS mount are readable through the S3 API. Files uploaded through the S3 API show up in the file system.
- **Concurrent access.** Multiple EC2 instances, ECS tasks, EKS pods, and Lambda functions can share the same mount with NFS close-to-open consistency.
- **Fully managed.** No file servers, no capacity planning, no scaling levers.

The short version: the same bucket now has two front doors. Pick whichever one fits the caller.

## How it works under the hood

Most of the announcement coverage skips this part, and it drives every cost and performance decision you'll make.

S3 Files is a **two-tier system**:

1. **A high-performance caching layer** backed by Amazon EFS infrastructure. This is where hot data, metadata, directory listings, and small reads live. Latency is around **1ms**.
2. **The S3 bucket itself** as the cold, durable, bottomless backing store.

When a client does a file-system operation, S3 Files makes a routing decision:

- **Metadata, directory listings, and small reads (under 128 KB)** → served from the high-performance tier.
- **Files used actively by your workload** → promoted to the high-performance tier on first access and served from there.
- **Large sequential reads (1 MB and above)** → streamed directly from S3 to maximize throughput.

Writes go through the high-performance tier. S3 Files then asynchronously persists them back into the bucket as normal S3 objects.

Hybrid routing is the point of the design. The EFS-backed cache gives you POSIX semantics and low latency where it matters. The direct-from-S3 path keeps large-read throughput high without forcing you to pay cache costs for data you only touch once.

## The cost model

Pricing is where teams will get surprised, in both directions.

You pay for three things:

1. **Storage for the hot tier.** Data promoted into the high-performance layer is billed like EFS storage while it lives there.
2. **Per-request charges on the high-performance layer.** Small file operations, metadata lookups, directory listings, and sub-128 KB reads all hit this tier. You pay per NFS operation served from the cache.
3. **Standard S3 charges for direct reads.** Large reads (≥1 MB) that stream directly from the bucket incur only normal S3 GET request costs. **No extra S3 Files surcharge on that path.**

Two patterns fall out of this model:

**Cheap on S3 Files:**
- Large datasets where only a slice is actually hot.
- Read-heavy workloads on large files (think training data, video, backups, archives).
- Workloads that already pay S3 GET costs and just want POSIX access on top.

**Expensive on S3 Files:**
- Metadata-chatty workloads (lots of `stat`, `ls`, tiny config files).
- Applications that constantly churn tiny files with no locality.
- Workloads where the entire dataset is hot all the time. You'd pay cache storage for 100% of your data.

> If most of your reads are large files and most of your dataset is cold, S3 Files will feel almost free. If your workload is small-file metadata spam, it will not.

This is the inverse of how most people intuit "file system on top of S3" pricing. Run the math before committing.

## How it compares to the existing options

AWS now has four credible ways to get file-style access to data in or alongside S3. They are not interchangeable.

### S3 Files vs Mountpoint for S3

Mountpoint for S3 is the open-source FUSE-based mount AWS released in 2023. It is a thin translator: every read hits S3, every write goes to S3, nothing is cached across processes.

Early community benchmarks show the gap clearly:

- **1,000 small file reads:** S3 Files **4.3s** vs Mountpoint **87.1s**. ([source](https://computingforgeeks.com/s3-files-vs-mountpoint-vs-s3fs/))
- **Cached large read throughput:** S3 Files served ~**1.9 GB/s** from the EFS-backed cache.
- **Concurrency model:** Mountpoint is per-instance with no cross-instance coordination. S3 Files is a shared NFS mount across EC2, ECS, EKS, and Lambda.

Mountpoint is still a fine tool for single-node, read-mostly, large-file workloads where you want the absolute cheapest option and don't need sharing. S3 Files is what you reach for when you need a real shared POSIX surface or when small-file performance matters.

### S3 Files vs EFS

EFS is still the right answer when **all of your data is hot** and you want consistent sub-millisecond NFS access without any S3 semantics underneath. A shared working directory for a compute cluster, where every file is touched regularly, is the textbook fit.

S3 Files wins when only a fraction of the dataset is active. You get EFS-class latency on the hot slice without paying EFS storage rates on the cold majority. You also skip the dual-source-of-truth problem where some data lives in EFS and some in S3.

### S3 Files vs FSx

FSx is the purpose-built family: FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, FSx for OpenZFS. If you need SMB, Windows ACLs, Lustre-class HPC throughput, or ONTAP multi-protocol features, FSx is still the answer. S3 Files does not replace any of them. It addresses a different problem: giving S3 itself a POSIX front door.

## Where S3 Files fits

Based on the workloads we run and audit for clients, these are the cases where S3 Files looks like the obvious choice:

**1. ML training and inference where the data already lives in S3.**
Frameworks like PyTorch and TensorFlow expect file paths. Teams currently solve this by pre-copying shards to EBS or EFS, or by using Mountpoint and paying the small-file penalty. S3 Files collapses this: point training at the mount, let the hot shards cache, and stop maintaining a second copy.

**2. Data pipelines with mixed consumers.**
When the same dataset has to serve a Spark job (happy with S3), a legacy script (wants POSIX), and an analytics tool (wants SQL on S3), you usually end up with duplicates. S3 Files lets all three hit the same bucket through whichever door fits.

**3. Shared media and asset storage for web apps.**
Today this is often EFS, because S3 alone doesn't give you the semantics the app expects. S3 Files lets you keep the durability and cost profile of S3 while the app still sees directories.

**4. Lift-and-shift of legacy applications.**
The classic "this app writes to `/data` and we cannot change it" migration. Previously that meant EFS or FSx, even if the access pattern was a poor fit. S3 Files gives you a cheaper target for cold-heavy workloads.

**5. Cross-service scratch space.**
Lambdas, ECS tasks, and EKS pods can now share a POSIX mount backed by S3 without standing up a second storage system.

## Where we would not reach for it

- **Very small, very hot datasets.** Use EFS. You're not going to benefit from the S3 tier and you'll pay cache charges on all of it anyway.
- **Windows workloads needing SMB.** Use FSx for Windows.
- **HPC and high-throughput shared scratch.** Use FSx for Lustre.
- **Workloads dominated by tiny files and metadata ops with poor locality.** The per-request cost on the high-performance tier will hurt. Benchmark before committing.
- **Single-node, read-mostly, large-file jobs** where cost is everything. Mountpoint is still cheaper.

## The decision framework we're using

For new work, we're starting with three questions:

1. **Does the workload need POSIX, or will S3 API calls do?**
   If S3 API is fine, stay on plain S3. Do not add a file system for the sake of it.

2. **Is the dataset mostly cold with a hot working set, or mostly hot?**
   Mostly cold with a hot slice → S3 Files.
   Mostly hot → EFS (or FSx for specialized cases).

3. **Do multiple compute nodes need to share the mount?**
   Yes → S3 Files or EFS, not Mountpoint.
   No, and the files are large → Mountpoint is still the cheapest option.

If we were designing some of our recent architectures today, this framework would likely change the storage choice. The clearest candidate for revisiting is the dual EFS + S3 pattern, used when an app wanted directories but the dataset was huge and mostly cold.

## What this means

S3 Files does not make EFS, FSx, or Mountpoint redundant. Each still wins in its own lane.

What it does change is the **default**. For a large category of workloads, the ones where teams used to stand up a second storage system just because an application needed POSIX, "put it in S3" is now a complete answer instead of the first step of a migration plan.

One source of truth. Two access patterns. That is the real shift.

If you're running workloads where you suspect S3 Files could collapse a storage layer or cut a dual-copy pattern, that's exactly the kind of audit we do. Reach out and we'll look at it together.

large_amazon-s3-files-cover.png

medium_amazon-s3-files-cover.png

small_amazon-s3-files-cover.png

thumbnail_amazon-s3-files-cover.png

amazon-s3-files-cover.png

Amazon S3 Files Deep Dive: File System Access to S3 Buckets, How It Works and When to Use It