S3 just became a filesystem: Amazon S3 Files for real-world workloads

Amazon S3 is no longer “just” object storage – with the new Amazon S3 Files feature, you can mount S3 buckets as real, shared file systems with POSIX semantics and NFS access. For DevOps and platform teams, that means many workloads that used to need EFS or FSx (plus a lot of data‑copy glue) can now run directly on top of S3.

What is Amazon S3 Files?

Amazon S3 Files is a feature that exposes any general‑purpose S3 bucket (or prefix) as a mountable file system that applications can access over NFS. Under the hood, it keeps S3 as the authoritative data store but presents files and directories with familiar POSIX semantics like hierarchical paths, permissions, and atomic renames.

You can mount S3 Files from EC2, containers (ECS/EKS/Fargate), and even AWS Lambda functions, so file‑based and object‑based workloads can share one storage layer. Because the feature is embedded in S3 itself rather than being a client‑side hack, it is designed to support heavy concurrent access, high throughput, and real multi‑writer scenarios.

How S3 Files works under the hood

S3 Files connects your bucket to a file system implementation backed by high‑performance storage that sits between your compute and S3. Frequently accessed data and metadata are cached on this fast storage, while S3 continues to hold the durable, long‑term copy.

A few important mechanics to understand:techforward+1

• Intelligent caching: When files are actively used, their contents and metadata are pulled into the high‑performance layer and served with low‑millisecond or sub‑millisecond latency.
• Size‑aware hydration: There is a configurable file‑size threshold (AWS’s examples use a default around the hundreds of kilobytes) to decide when to fully hydrate vs lazily stream content.
• Direct S3 bypass for large reads: For big, sequential reads (for example, multi‑MiB streaming workloads), S3 Files can serve data directly from S3 at maximum throughput, only transferring the requested ranges.
• Write‑back then sync: Writes land first on the high‑performance storage layer and are then batch‑synced back into S3, typically within seconds to a few minutes, with S3 remaining the source of truth.
• Eviction of cold data: Data that has not been accessed for a configurable retention window is evicted from the high‑performance layer while remaining safely stored in S3.

From an application’s perspective, you get a normal NFS file system with close‑to‑open consistency semantics, while S3 Files handles the heavy lifting of cache management, synchronization, and integration with S3.

Performance characteristics that matter

AWS’ published numbers highlight that cached workloads can hit very low latency and massive aggregate throughput. For hot data in the high‑performance layer, S3 Files targets sub‑millisecond to low single‑digit millisecond access times.

On the throughput side, AWS documentation and early benchmarks talk about tens of thousands of concurrent connections per file system and up to several terabytes per second of aggregate read throughput across clients and buckets. A single client doing large sequential reads can achieve multi‑GiB/s by leveraging parallel S3 GETs when bypassing through to S3.

In practice, this means workloads like media processing, ML training, and analytics that previously required carefully tuned EFS or FSx deployments can now run directly against S3 with very competitive performance, provided that access patterns are either cache‑friendly or sequential.

Pricing and cost model for S3 Files

S3 Files uses a pay‑for‑what‑you‑use model tied to your active working set rather than the total size of your bucket. You pay for:

• The capacity of the high‑performance storage layer that actually holds hot data.
• File system access operations during import/export phases and metadata operations.

For large, direct‑to‑S3 reads (when S3 Files decides to serve data straight from S3), you pay normal S3 request and data transfer charges without additional file‑system usage fees for those reads. AWS positions this as a way to avoid the cost of running separate file systems plus sync pipelines, claiming that you can cut total storage and data‑movement cost by up to around 90% compared with environments that duplicate datasets across S3 and file services.

Because there is no provisioned capacity or minimum commitment for the file‑system layer itself, the economics scale naturally with how much data is actually “hot” in your workloads rather than how large your bucket has grown over time.

S3 Files vs Mountpoint, s3fs, EFS, and FSx

If you’ve been running S3‑centric architectures for a while, you likely already have tools like Mountpoint for Amazon S3, s3fs‑fuse, or native S3 SDK usage in the mix. S3 Files sits in a different category.

• Versus Mountpoint for S3 / s3fs: Mountpoint and s3fs are client‑side solutions that translate file operations into S3 API calls, with various semantic gaps and performance trade‑offs (for example, limited support for certain file operations, weaker consistency guarantees, or poor behavior under heavy parallel writes). S3 Files, by contrast, is a managed service embedded into S3 with a dedicated cache and NFS server layer designed from the ground up to support full POSIX semantics for concurrent workloads.
• Versus Amazon EFS: EFS is still a great fit when you want a classic regional NFS file system where the file system is the system of record and S3 may not be involved at all. S3 Files flips this around: S3 is the system of record, and the file system is a projection on top, ideal when your primary data lake or content repository already lives in S3.
• Versus FSx (Lustre/Windows): FSx for Lustre and FSx for Windows are tuned for HPC and Windows file‑sharing scenarios, respectively, with their own protocols and integration patterns. S3 Files does not aim to replace those specialized services; instead, it targets the many workloads that already write to S3 but still need file access semantics for tools, agents, and legacy applications.

The key takeaway is that S3 Files lets you stop maintaining separate S3 and file‑system copies for the same data in the common case, while you still use EFS or FSx where protocol or performance characteristics truly demand them.

Key use cases for S3 Files

AWS and early adopters have already highlighted several classes of workloads where S3 Files shines. Some of the most compelling scenarios:

• Machine learning training and inference
  Point training clusters directly at S3‑resident datasets and checkpoints without copying data to block volumes or EFS, and let multiple GPU nodes share the same mounted file system. Checkpoints and model artifacts end up in S3 automatically for audit and reuse.
• Agentic AI and multi‑agent systems
  Multi‑agent workflows that expect a shared “scratch” filesystem can now use S3 Files as their working directory, while the same data lake remains accessible through object APIs, SQL engines, or vector search tools. This dramatically simplifies the storage story for AI pipelines that mix Python scripts, CLI tools, and managed services.
• Artifact storage, CI/CD, and build systems
  Build pipelines and artifact registries can treat S3 buckets as shared file trees while still benefiting from S3’s durability, lifecycle policies, and cross‑region replication. This reduces complexity in systems that historically had to sync artifacts between S3 and a separate file store.
• Legacy file‑based applications
  Existing applications that assume a POSIX file system – think older media processing stacks, ETL scripts, or configuration management systems – can be lifted into containers or serverless environments and pointed at S3 Files without rewriting their storage layer.

For Cloudwork clients, we see strong alignment with data‑heavy SaaS, analytics platforms, and domain‑intelligence pipelines that already depend on S3 as their primary data lake but still juggle extra file systems for specific tools or teams.

Architectural implications for platform and DevOps teams

The biggest shift with S3 Files is architectural: you can now design around a single authoritative storage layer in S3 without splitting object and file worlds. Object‑oriented services, query engines, and lakehouse systems still talk to S3 using APIs, while file‑based applications and agents mount the same underlying data as a file system.

This simplifies governance, because you manage one set of IAM policies, encryption keys, and lifecycle rules for both object and file access rather than keeping S3, EFS, and FSx copies in sync. It also cuts down on bespoke sync pipelines and one‑off connectors, which reduces failure modes and operational overhead for platform teams.l

From a DevOps perspective, S3 Files is also a powerful migration and modernization tool: you can containerize workloads that previously relied on local or NFS storage, mount S3 Files inside those containers, and gradually refactor them to native S3 APIs over time – or keep them file‑based if that is sufficient.

Getting started with S3 Files (high-level)

The basic getting‑started workflow is intentionally straightforward.

1. Create an S3 Files file system for your bucket or prefix
   In the S3 console, you choose a bucket (or sub‑prefix) and create an associated file system, which links it to the high‑performance storage layer.
2. Configure networking and mount targets
   AWS provisions mount targets in your VPC, and you ensure that your EC2 instances, containers, or on‑premises connections can reach these targets via appropriate subnets and security groups
3. Mount from your compute environment
   On a Linux‑based instance or container, you install the appropriate utilities and then mount the file system using the S3 Files NFS‑compatible mount type. For example (AWS’ documentation uses similar commands): mkdir -p /mnt/s3files sudo mount -t s3files fs-XXXXXXXXXXXX:/ /mnt/s3filesAfter that, you can list, read, and write files under /mnt/s3files with standard tools, and the changes propagate back to S3
4. Integrate with your IaC
   Over time, you’ll want to model S3 Files in Terraform/CloudFormation and codify IAM policies, mount targets, and security group rules, just as you do today for EFS or FSx. As the ecosystem matures, expect provider support and modules that make this repeatable across environments.

For production workloads, you’ll also want to tune file‑size thresholds, retention windows, and access patterns based on how your applications read and write data.

When S3 Files is not the right fit

As powerful as S3 Files is, it is not the universal answer to all storage problems, and AWS is clear that it complements rather than replaces other services.

• HPC with specialized semantics: For ultra‑low‑latency HPC workloads that rely on Lustre semantics, FSx for Lustre remains the recommended solution.
• Windows‑native workloads: Windows file shares and Active Directory‑integrated scenarios still point towards FSx for Windows File Server.
• Block‑level requirements: Databases or workloads that need block‑device semantics and consistent single‑digit millisecond latency will continue to use EBS.
• Offline or edge scenarios: If your workloads must operate with intermittent connectivity or fully on‑prem without direct S3 access, you’ll still need local storage or edge/appliance solutions.

For everything else that already stores primary data in S3 or will soon move there, S3 Files becomes a very attractive default for file‑semantics access, especially when data duplication has been a persistent pain point.

How Cloudwork can help you adopt S3 Files

At Cloudwork, we work with teams that are already deep into S3‑centric architectures – from SaaS platforms and content sites to analytics and domain‑intelligence pipelines. S3 Files gives us a new, cleaner building block for these systems.

We can help you:

• Evaluate whether S3 Files is a good fit for your current mix of S3, EFS, FSx, and on‑premises file storage.
• Design migration paths that eliminate redundant file systems and sync jobs without disrupting your existing workloads.
• Update your infrastructure‑as‑code to provision and manage S3 Files alongside your buckets, VPCs, and compute.
• Modernize legacy file‑based applications by lifting them into containers or serverless environments that mount S3 Files instead of local or NFS storage.

If you’re looking at your current S3 plus file‑storage setup and seeing a tangle of sync jobs, duplicated data, and special‑case exceptions, S3 Files is the moment to rethink that architecture – and we’d be happy to partner with you on that journey.