TL; DR – S3 Files eliminates data duplication and copy pipelines. It lets EC2, Lambda, ECS, and EKS access existing buckets directly with NFS semantics and sub-millisecond latency for active data.
Amazon S3 turned 20 in March 2026. What started as simple object storage in 2006 now stores hundreds of exabytes and serves hundreds of billions of requests daily.
On April 7, 2026, AWS introduced S3 Files, the first cloud object store to expose any general-purpose bucket as a fully featured, shared file system. No migration. No code changes. Data stays in S3 while compute resources mount it natively.
Two Decades of S3 Evolution
S3 launched with a one-paragraph announcement on March 14, 2006. Its original design focused on web-scale object access (simple PUTs and GETs, 99.999999999 percent durability, and virtually unlimited capacity).
Over time, AWS expanded the model without breaking it. S3 Tables (launched at re:Invent 2024) added Apache Iceberg support with automatic compaction and transactional guarantees. We then saw the introduction of S3 Vectors which brought native similarity search for embeddings. S3 Files completes the feature set beautifully because S3 now supports objects, tables, vectors, and files from the same authoritative data store.
Werner Vogels, AWS CTO, describes the driver as data friction. Tools and agents expect local files. Data lives in S3. The gap forces pipelines that copy terabytes or petabytes. Early internal experiments (internally called EFS3) showed the pitfalls. Engineers scrapped compromises and rebuilt around a clean stage-and-commit boundary. The nine-month customer beta refined the design based on real workloads in genomics, media, and machine learning.
How S3 Files Works Under the Hood
S3 Files links any general-purpose bucket (or a scoped prefix) to a file system built on Amazon EFS technology. You create the file system once, add mount targets in your VPC, and mount it on Linux-based compute with a standard NFS command. Objects appear as files and directories. Changes flow both ways automatically.
Some of the key mechanics of S3 Files include:
- Intelligent caching loads actively used files and metadata onto high-performance storage. A configurable file-size threshold (default 128 KB) decides full hydration. Smaller files land immediately. Larger ones load lazily on first read.
- Direct S3 bypass streams sequential reads of 1 MiB or larger (or files above threshold) straight from S3 at maximum throughput. Only requested byte ranges transfer.
- The write path lands changes first on high-performance storage, then batch-syncs to S3 (typically within about 60 seconds, visible in minutes). S3 remains the source of truth.
- Eviction expires data unused for the retention window (default 30 days, configurable from 1 to 365) from high-performance storage. The authoritative copy stays in S3.
- Consistency follows NFS close-to-open semantics for concurrent access. S3 changes appear in the file system within seconds to a minute. Conflicts move filesystem versions to lost+found.
You control synchronization with IAM policies, prefixes, and POSIX permissions stored as S3 object metadata. Encryption uses TLS 1.3 in transit and SSE-S3 or KMS at rest. Monitoring flows through CloudWatch metrics and CloudTrail logs.
Performance numbers published by AWS show sub-millisecond to low single-digit millisecond latency for cached active data, up to 10 million plus IOPS per bucket, 25,000 concurrent connections, and multiple terabytes per second aggregate read throughput. A single client can pull 3 GiB/s on large sequential reads by bypassing to parallel S3 GETs. There is no doubt that performance was top of mind in the design.
Pricing and Billing Model
You pay only for the active working set on high-performance storage plus file-system access charges during import or export operations. Large direct-S3 reads incur standard S3 GET request costs only (no file-system charge). There is no provisioned capacity and no minimums. Costs stay proportional to actual usage rather than full dataset size. AWS claims up to 90 percent lower total cost versus maintaining separate file systems and copy pipelines.
Getting Started in Minutes
- In the S3 console, choose File systems then Create file system and select your bucket (or prefix).
- The console provisions mount targets in your VPC.
- On your EC2 instance (or container), install the latest amazon-efs-utils if needed, then run this:
sudo mkdir /mnt/s3files
sudo mount -t s3files fs-0123456789abcdef:/ /mnt/s3files- Read, write, and list with standard tools. New files appear in S3 within minutes.
The same mount works on Lambda, ECS, EKS, Fargate, and Batch. Access points simplify large-scale deployments. Full CLI equivalents exist for IaC workflows.
Use Cases Practitioners Will Want to Test First
We have lined up a few of our ideal start points for putting S3 Files to the test.
Machine learning training pipelines
Mount massive datasets directly. Multiple GPU nodes read and write checkpoints without copying data or managing EBS volumes. Changes sync back to S3 for versioning and audit.
Agentic AI and multi-agent systems
Agents using Python, CLI tools, or scripts now share a common workspace. Write logs, intermediate results, state files, and checkpoints to the mounted drive. Deloitte’s AI teams already highlight this for collaborative analytics pipelines.
Scientific and genomics workloads
Researchers at places like UBC previously copied terabytes of sequencing data between NFS and S3. S3 Files lets analysis containers mount the bucket, run tools like bunnies-style workflows, and leave results in place. No more download everything first.
Package and artifact processing
Platforms like Cloudsmith process hundreds of thousands of artifacts daily. Containers and Lambda functions can now treat S3 as a local filesystem for synchronization logic, cutting custom code and latency.
Any existing file-based application
Lift legacy apps onto containers or Lambda without rewriting storage layers. Media transcoding, ETL jobs, and configuration management all gain direct access.
What This Means for Builders and Platform Teams
S3 Files doesn’t replace purpose-built file systems like FSx for Lustre (HPC) or FSx for Windows (enterprise file shares). It targets workloads that already live in S3 and need file semantics without the overhead of duplication or sync.
The bigger shift is architectural. Teams can now design around one authoritative data store. Object-based pipelines continue unchanged. File-based agents and applications join the same namespace. Storage boundaries stop dictating application architecture.
For platform engineers, this simplifies governance: one set of IAM policies, one encryption key, and one durability model. If you’re a developer, it means fewer bespoke connectors and faster iteration. And for all of you cost-conscious leaders, it means measurable reduction in duplicated storage and data-movement pipelines.
S3 Files is generally available today in 34 AWS Regions. Start with an existing bucket, mount it, and run your next ML job or agent workflow against real data (no copies required). The friction that defined two decades of cloud storage just got a lot smaller.
Congratulations to the S3 team on a fantastic new offering for AWS customers. I am looking forward to putting this to good use.
