AWS just launched S3 Files. You can now mount any S3 bucket or prefix as a filesystem on EC2, containers, or Lambda. From your app’s perspective, it’s a mounted directory. Under the covers, it’s actual EFS (Elastic File System) integrated into S3. The S3 and EFS teams built this together, and Andy Warfield’s blog post on the design process is worth reading in full.
The sync model borrows from git: they call it “stage and commit.” Changes accumulate in the EFS layer and get committed back to S3 roughly every 60 seconds as a single PUT. Sync runs both directions, so if something else modifies the S3 objects, the filesystem view updates automatically. When there’s a conflict (both sides modified the same file), S3 wins and the filesystem version gets moved to lost+found with a CloudWatch metric.
When you first access a directory, only metadata is imported from S3. Files under 128 KB get their data pulled immediately; larger files are fetched on-demand when you actually read them. So you can mount a bucket with millions of objects and start working right away. Data not accessed in 30 days gets evicted from the filesystem view but stays in S3, keeping storage costs tied to your active working set.
For sequential reads, there’s a “read bypass” mode that reroutes the data path to perform parallel GET requests directly to S3, hitting up to 3 GB/s per client and scaling to terabits/s across multiple clients.
Some limitations worth knowing: renames are expensive because S3 has no native rename operation (it’s copy + delete for every object under a prefix). They warn you at 50 million objects per mount. Some S3 object keys can’t be represented as valid POSIX filenames, so they won’t appear in the filesystem view. And the 60-second commit window won’t work for every workload.
What I like about the design is that they stopped trying to pretend files and objects are the same thing. The explicit boundary between the two is the part that actually makes it work.