S3 Files: What 20 Years of “You Can’t Mount S3” Looks Like When It Finally Ships
My hands on experience about the new S3 Files.
Series: Golden Jacket Field Notes (22 articles)
- …
- 12S3 Files: What 20 Years of “You Can’t Mount S3” Looks Like When It Finally Ships This article
Disclaimer
**Originally published on Medium as Week 6 of Golden Jacket Field Notes.**Canonical URL: https://medium.com/aws-tip/s3-files-what-20-years-of-you-cant-mount-s3-looks-like-when-it-finally-ships-90e6e01792eaThis is a republication on AWS Builder Center for the AWS community. The piece below appeared first on Medium and is preserved here in its original form.
For more than 10 years I have been explaining the same thing to customers. S3 stores objects. You cannot edit a page inside an object. You replace the entire thing. If your application needs a file system, you use EFS (Elastic File System) or FSx. If your data lives in S3, you copy it somewhere else before your tools can touch it.
I had an analogy I used in architecture reviews. Objects are like books in a library. You can check one out, you can replace it, but you cannot walk up to the shelf and rewrite chapter three while someone else is reading chapter five. Files are the opposite. They exist precisely so that multiple processes can read, write, and edit the same data concurrently.
That analogy is now less useful than it was a week ago.
On April 7, 2026, AWS launched S3 Files in general availability across 34 regions. It lets you mount any S3 bucket as a shared NFS (Network File System) file system on EC2 (Elastic Compute Cloud) instances, containers running on ECS (Elastic Container Service) or EKS (Elastic Kubernetes Service), Lambda functions, Fargate, and Batch. Your applications read and write S3 data using standard file operations. No code changes. No copy pipelines. No intermediate staging.
I spent the week testing it. This is what I found, what the documentation leaves out, and why the design decisions behind S3 Files are more interesting than the feature itself.
Why This Matters Now
If you work with data on AWS, you have lived with a version of this friction. Your data sits in S3 because S3 is durable, cheap, and scales without limits. But the tools you use to process that data expect a file system. Python scripts expect to open files. ML (Machine Learning) training jobs expect mounted directories. Unix command-line tools expect paths.
The workaround has always been the same. Copy data from S3 to EFS or EBS (Elastic Block Store). Process it. Copy results back. Build a sync pipeline. Hope it does not break during a long-running job.
That friction is not just annoying. It is expensive, error-prone, and it slows down every team that touches data. ML engineers copying terabytes to local storage before training. Data scientists downloading datasets to notebooks. ETL (Extract, Transform, Load) pipelines shuttling files between storage layers.
And with AI agents becoming part of real workflows, the friction got worse. Agents reach for Unix tools instinctively. They want to cat, grep, ls, and pipe data through standard utilities. When their data lives in S3, they need custom logic to list objects, download them, and clean up after. That is extra reasoning the agent has to do on every interaction, and extra context consumed in the process.
S3 Files removes the copy step entirely.
But I have seen enough “revolutionary” storage announcements to be skeptical. S3 Mountpoint already exists and gives you FUSE-based access to S3. Third-party tools like s3fs and goofys have been around for years. The question was whether S3 Files actually solves the problem or just adds another option to an already confusing storage menu.
After almost a week of testing, I think it solves the problem. And the reason it works is not the technology. It is a design decision the team made after their first approach failed.
The Design That Failed
The most interesting part of the S3 Files launch was not the feature itself. It was the essay Andy Warfield published alongside it on All Things Distributed. Warfield is a VP and distinguished engineer who leads S3 engineering at AWS, and he wrote something you almost never see from a cloud provider: an honest account of a design that did not work.
The problem goes back further than most people realize. Before joining Amazon, Warfield was at UBC working with genomics researchers who were sequencing sunflower DNA. The biologists’ tools all expected a Linux file system. Their data lived in S3. A PhD student spent most of his time not doing biology but building caching and naming layers to copy data between where it was stored and where the tools expected it to be. That friction, data on one side, tools on the other, and a manual pipeline in between, is something Warfield says he has seen repeated across every industry since.
The original idea for S3 Files was straightforward. Combine EFS and S3 into a single unified storage system. The internal project name was “EFS3.” The team locked their most senior engineers in a room and told them to come up with a plan that made both abstractions work as one.
They could not do it.
Every design they tried forced one side to compromise in ways that would break real workloads. File systems need fine-grained mutations, where you edit byte 47 of a file while someone else reads byte 200. Objects assume immutability. Over 300 billion S3 event notifications go out daily based on the assumption that objects are created or overwritten as complete units. Billions of existing applications depend on that behavior.
One engineer on the team described the process as “a battle of unpalatable compromises.” They tried for months. They came back after the holidays in early 2025 and enumerated every specific compromise they would need to accept. The conclusion was clear: a unified system would not be the best of both worlds. It would be the lowest common denominator of both.
That failure is the reason S3 Files works as well as it does.
Stage and Commit: The Architecture That Survived
Instead of hiding the boundary between files and objects, the team made it explicit. They borrowed a concept from version control systems like Git: stage and commit.
Here is how it works.
When you create an S3 file system and mount it, the service attaches an EFS namespace to mirror the metadata from your S3 bucket. Your applications interact with the EFS layer through standard NFS v4.1+ operations. They see files and directories. They can create, read, update, delete, rename, and lock files.
Under the hood, the data lives in S3. The EFS layer is a presentation and caching tier. Changes accumulate on the file system side, and approximately every 60 seconds, they are committed back to S3 as complete object PUTs. In the other direction, when something modifies objects directly through the S3 API, S3 Files detects those changes and reflects them in the file system view.
The two layers are explicitly separate. Each one preserves its own semantics. The file side gives you NFS close-to-open consistency, meaning changes become visible to other clients after a file is closed. The object side gives you standard S3 strong consistency with full atomic PUTs. The boundary between them is not a limitation. It is the thing that makes both sides work without compromise.
If there is ever a conflict where the same data is modified from both the file system and the S3 API simultaneously, S3 is the source of truth. The file system version goes to a lost+found directory, and a CloudWatch metric fires to let you know it happened.
The Tradeoffs They Had to Navigate
The stage-and-commit model gave the team a structure, but it did not make every decision easy. Two areas stood out to me as particularly well-thought-through.
The first is authorization. S3 and file systems think about permissions in completely different ways. S3 supports IAM (Identity and Access Management) policies scoped to key prefixes. You can deny GetObject on anything under /private/* and further constrain those permissions based on the network or properties of the request itself. IAM policies are incredibly expressive but also expensive to evaluate on every operation.
File systems take a different approach. They evaluate permissions upfront, cache the result in a file handle, and then use that handle for persistent access. Permissions live in the inode. Hard links give you multiple paths to the same file with potentially different directory permissions. Once you have a handle, you can keep using it even if the file is renamed, moved, or deleted from the directory.
By making the boundary explicit, the team avoided having to represent both permission models on every single object. Permissions are specified on the mount itself, which is familiar territory for anyone who has worked with NFS. IAM policy on S3 remains as a backstop. You can always disable access at the S3 layer if you need to change a data perimeter, while delegating authorization to the file system layer within each mount.
The second is consistency and atomicity. S3 readers assume full object updates and notifications. Many applications depend on the ability to do atomic file renames as a way of making a large change visible at once. S3 conditionals help with some of that, but there is no S3 equivalent for an atomic directory move. By letting each layer keep its own consistency model, the team avoided subtle breakage. You can rename files all you want on the NFS side, and at a later point the committed version appears in S3 as a complete object PUT.
Lazy Hydration and Read Bypass
Two performance decisions stood out during testing.
The first is lazy hydration. When you mount a bucket, S3 Files does not download everything. It imports metadata and populates the file system view in the background. For files smaller than 128 KB, it also pulls the actual data. For everything larger, only metadata co41mes over, and the actual file content is fetched from S3 on demand when you read it.
This means you can mount a bucket with millions of objects and start working immediately. You do not wait for a full sync. The background import runs while you are already reading and writing files.
The second is what AWS calls read bypass. For large sequential reads, the system detects that NFS is not the optimal path and reroutes the read operation. Instead of going through the file system layer, it fires parallel GET requests directly against S3. The result is throughput of up to 3 GB/s per client, scaling to terabits per second across multiple clients. For ML training workloads reading large dataset files, this is exactly the pattern you want.
Small files get low-latency access from the EFS caching layer. Large files get high-throughput streaming directly from S3. The system decides automatically based on access patterns.
The Namespace Problem (and “Filerectories”)
This is where things get funny, in an engineering-dark-humor kind of way.
S3 and file systems think about naming differently. In a file system, the forward slash is a real path separator. Directories are first-class entities with their own permissions. In S3, the slash is a convention. A suggestion. S3 does not have directories. You can even have objects whose keys end with a slash, which means you can have something that looks like a directory but is actually a file.
The S3 engineering team apparently called these “filerectories” for about twenty minutes before deciding that was a terrible name. It was. But the problem is real.
There are object keys in S3 that simply cannot be represented as valid POSIX filenames. When S3 Files encounters one of these, it does not try to force a translation. It does not fail. It skips the object, emits an event, and lets you handle it. The key stays in S3, accessible through the S3 API, but it does not appear in the file system view.
This is a deliberate design choice. Instead of breaking assumptions in either domain, the boundary acknowledges that some things do not translate. You get a monitoring mechanism to detect and address edge cases as they come up.
What the Documentation Does Not Tell You
Here are the things I found during testing that are worth knowing before you build on S3 Files in production.
Renames are expensive. S3 has no native rename operation. Renaming a file through the NFS mount means S3 Files copies the object to the new key and deletes the old one. For a single file, that is barely noticeable. For a directory with 50,000 objects, that is 50,000 individual copy-and-delete operations. AWS warns you when a mount covers more than 50 million objects, and this is one of the reasons why.
The 60-second commit window is not configurable at launch. Changes accumulate on the file system and commit to S3 roughly every minute. For most workloads this is fine. For pipelines that depend on immediate S3 visibility after a file write, you need to account for this lag. There is no explicit flush or manual commit API yet. Warfield’s essay signals this is something the team plans to evolve.
NFS file locks work, but S3 API operations bypass them. I verified this with flock on a test file. Two NFS clients competing for an exclusive lock behaved correctly. But if a third process writes to the same object through the S3 API directly, the lock is invisible to it. If your workload updates data through both paths, you need an external coordination mechanism.
The 32 KB metering minimum is real. Every data access operation is metered at a minimum of 32 KB. Read a 1-byte config file? Metered for 32 KB. Write a 4-byte update? 32 KB. Metadata operations like listing directories or checking file attributes cost 4 KB metered as a read. For workloads with millions of tiny metadata-heavy operations, like ML checkpointing or agentic workflows, those minimums add up.
S3 versioning is required. You cannot create an S3 file system on a bucket without versioning enabled. This makes sense architecturally because the stage-and-commit model needs to track changes, but it also means your storage costs increase from the additional versions. Factor this into your cost modeling.
Custom S3 metadata is not visible through the NFS mount. If your application sets x-amz-meta headers on objects through the S3 API, those values do not appear as extended attributes on mounted files. POSIX attributes only. If metadata is part of your workflow logic, you need to maintain that through S3 API calls.
Glacier storage classes are not compatible. The file system needs to read data on demand, and Glacier retrieval times would break NFS expectations. S3 Standard, Intelligent-Tiering, and Infrequent Access all work. Glacier does not.
The 1,024-byte S3 key length limit applies. Deeply nested directory structures with long filenames can hit the ceiling. If your application generates paths like /data/project/2026/04/08/experiment-abc-123/results/output-final-v2.json, measure the total key length before committing to a directory structure. This is easy to overlook and hard to fix after the fact.
Hard links are not supported. Symbolic links work fine. If your application relies on hard links for its internal state management, like some build systems and package managers do, you will need to adjust.
Up to 25,000 concurrent connections are supported. S3 Files inherits this from EFS. For large-scale ML training across hundreds of nodes or containerized workloads with thousands of tasks, this ceiling is worth knowing. It is generous for most production scenarios, but if you are running hyperparameter sweeps across massive GPU clusters, you could approach it.
First mount latency depends on bucket size. The background metadata import is fast, but on buckets with millions of objects, the initial file system view takes time to fully populate. You can start working immediately with the objects that have been imported so far, but a full directory listing of a very large prefix will not return complete results until the import catches up. There is no progress indicator in the console for this.
The Bigger Picture: S3 as a Multi-Modal Data Platform
S3 Files does not exist in isolation. It is the third major data type AWS has added to S3 in the past two years.
At re:Invent 2024, they launched S3 Tables for structured tabular data. Built on Apache Iceberg, S3 Tables gives you managed table primitives with automatic compaction, cross-region replication, and security guardrails. Today there are over 2 million tables stored in S3 Tables.
At re:Invent 2025, they launched S3 Vectors for similarity search. Instead of running a separate vector database with expensive compute clusters, you get an elastic, S3-native vector index that scales from hundreds to billions of records.
And now S3 Files for file system access.
The pattern is clear. AWS is transforming S3 from a pure object store into a multi-modal data platform. Objects, tables, vectors, and files. Four different ways to access and work with data, all on top of the same storage layer with eleven nines of durability.
For solutions architects, this changes the decision matrix. The question is no longer “where does my data live?” It is “how do my applications need to access data that already lives in S3?”
In Week 2 of this series, I wrote about the AWS agentic stack and how Strands Agents SDK, AgentCore, MCP (Model Context Protocol), and A2A (Agent-to-Agent) fit together. S3 Files connects directly to that picture. Agents built with Strands can now read and write S3 data through standard filesystem calls. Training pipelines running on SageMaker can mount S3 buckets directly. Data preparation workloads can process files in place without staging.
The data copy step that has frustrated every ML engineer I have ever worked with is gone.
Think about what that means in practice. An agent built with Strands needs to analyze a CSV file sitting in an S3 data lake. Before S3 Files, the agent would need to call the S3 API, download the file to local storage, process it, and clean up. That is four steps of logic, each one a potential failure point, each one consuming reasoning tokens. With S3 Files mounted, the agent runs
cat /mnt/s3/data/report.csv | head -20 and moves on. Same data. Same durability. Zero orchestration overhead.For teams running multi-agent architectures where agents need to share state, this is equally significant. Multiple agents can read and write to the same mounted S3 bucket concurrently, using standard file locks for coordination. The S3 bucket becomes both the persistent storage layer and the shared workspace, without a separate file system to manage.
Cost Model: What You Actually Pay
S3 Files pricing has three layers on top of your existing S3 storage costs.
High-performance storage runs at $0.30 per GB-month, but only for the data actively cached on the file system layer. If you mount a 10 TB bucket but only work with 500 GB of small files, you pay the $0.30 rate only on those 500 GB.
Data access charges are $0.03 per GB for reads and $0.06 per GB for writes. But large sequential reads of 128 KB or more bypass the file system layer entirely and incur only standard S3 GET request costs with no S3 Files surcharge.
Background sync operations also incur data access charges. Importing data onto the fast storage layer counts as writes. Exporting changes back to S3 counts as reads.
The first time you read a small file, it gets imported onto the fast storage. That first read costs $0.06 per GB (the import write charge), not $0.03. Subsequent reads of the same cached file are $0.03 per GB. This is a nuance that is easy to miss on the pricing page.
Data that has not been accessed in 30 days is automatically evicted from the file system layer. It is not deleted from S3. It just stops costing you $0.30 per GB-month on the fast tier.
For a practical comparison: if you stored all 10 TB on EFS Standard, you would pay around $3,000 per month. With S3 Files, that same 10 TB bucket with 500 GB of active small files costs roughly $370 per month plus access charges. The cost advantage grows as the ratio of total data to active working set increases.
When to Use S3 Files (and When Not To)
S3 Files works best when you have large datasets in S3 and file-based tools that need to operate on a subset of that data without copying it. ML training pipelines, data preparation workloads, agentic AI systems that use filesystem tools, and legacy applications migrating from on-premises NAS environments are all strong fits.
It is not a replacement for EFS in every scenario. If all of your data is hot and every file is accessed frequently, EFS still makes sense because there is no import cost and no sync lag. If you need the highest possible parallel throughput for HPC (High-Performance Computing) workloads, FSx for Lustre remains the better choice.
And it is not a replacement for S3 Mountpoint either. Mountpoint is a FUSE-based client that gives you read-only (or limited write) access to S3 with lower overhead and no EFS layer. If your workload is read-heavy with no mutation needs, Mountpoint might be simpler and cheaper.
The decision tree looks like this: Do your applications need to read and write S3 data through a file system interface? Do you work with a subset of a larger dataset? Do multiple compute resources need shared concurrent access? If yes to all three, S3 Files is what you want.
Takeaway
Twenty years after S3 launched, the question that every builder has asked at least once now has a real answer. Yes, you can mount your S3 bucket as a file system. And the reason it works is that the team did not try to pretend files and objects are the same thing. They built an explicit boundary between the two, gave each side its full semantics, and made the synchronization transparent.
The most interesting engineering lesson from this launch has nothing to do with storage. It is that sometimes the best design comes from accepting that your first instinct was wrong. The unified model sounded elegant. The explicit boundary actually works.
This is Week 6 of Golden Jacket Field Notes, a series where I share practitioner-level lessons from building on AWS at scale. I write about the things I wish someone had told me before I learned them the hard way.
Previous weeks:
- Week 1: Bedrock Knowledge Bases in Production
- Week 2: The AWS Agentic Stack Explained
- Week 3: Architecting Payment Authorization on AWS
- Week 4: I Connected Five MCP Servers to My IDE. My AI Agent Got Dumber
- Week 5: AWS Security Agent and DevOps Agent: The Agentic Stack Gets Its First Production Proof
Erick Mancz is an AWS Solutions Architect with Golden Jacket status (all active AWS certifications). He writes about cloud architecture, ML/GenAI, and the things the documentation does not cover.
Follow on Medium: @erickmancz Connect on LinkedIn: linkedin.com/in/erick-mancz
Series: Golden Jacket Field Notes (22 articles)
- …
- 12S3 Files: What 20 Years of “You Can’t Mount S3” Looks Like When It Finally Ships This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article