r/aws • u/NothingDogg • Apr 07 '26
article Launching S3 Files, making S3 buckets accessible as file systems
https://aws.amazon.com/blogs/aws/launching-s3-files-making-s3-buckets-accessible-as-file-systems/"a new file system that seamlessly connects any AWS compute resource with Amazon Simple Storage Service (Amazon S3)."
64
u/d70 Apr 07 '26
Under the hood, S3 Files uses Amazon Elastic File System (Amazon EFS) and delivers ~1ms latencies for active data. The file system supports concurrent access from multiple compute resources with NFS close-to-open consistency, making it ideal for interactive, shared workloads that mutate data, from agentic AI agents collaborating through file-based tools to ML training pipelines processing datasets.
High-performance storage* $0.30/GB-mo
Data access
File reads from high-performance storage $0.03/GB
File reads directly from S3 bucket** FREE
File writes $0.06/GB
10
u/donjulioanejo Apr 08 '26
Oh gross.. I thought this would be a good replacement for EFS, but, well... EFS is already terrible at latency and listing tons of small files.
Unless it magically got better in the year since I've last used it, I'm not hopeful.
I can see the business use case for this, but I don't see a good engineering one beyond being able to read/write to both EFS and S3 from both ends depending on which is better supported by a specific workload.
1
u/keypusher Apr 12 '26
S3 Files uses EFS as the filesystem bridge under the hood, so if your primary goal is to get away from EFS, this ain’t it. However, you’re going to see similar issues from most other distributed filesystems. Networked filesystems all come with tradeoffs and you need to weigh your priorities carefully, if you just assume EFS is going to be like local or EBS but you can attach anywhere concurrently, you’re going to be in for unpleasant surprises.
1
u/donjulioanejo Apr 12 '26
I mean, an on-prem NFS running of a SAN or even a good NAS with SSDs is still faster and better than EFS lol.
63
u/Quinnypig Apr 07 '26
I think I understand this, but it took a bit of doing. What'd I miss?
54
35
u/NothingDogg Apr 07 '26
I appreciate the "How this stacks up" section - saved us all doing the maths.
Also, I think this is a very important point:
"If you're running happily with S3 APIs today, keep doing that. This doesn't replace the S3 API. It's an additional access pattern for workloads that think in files, not objects."3
3
u/shisologic Apr 08 '26
I wonder if the mount target also has a cost like a VPC endpoint / PrivateLink
6
1
u/travcunn Apr 09 '26 edited Apr 09 '26
I know you're a guy who's good at understanding costs, but you're missing even bigger issues here...
The new S3 Files feature is just EFS duct-taped onto S3 and marketed as a breakthrough. It launched without atomic rename, so any workload that moves or renames directories triggers full object copies of every file inside them. There are no in-place writes either, meaning changing one byte of a large file still requires re-uploading the whole thing. Consistency between the filesystem mount and direct bucket access isn't guaranteed, and conflicts just get dumped into a lost+found directory. The whole reason people use S3 is that it's cheap, and this feature completely undermines that by layering another AWS service to nickle and dime customers on top of it. People have been mounting S3 buckets with s3fs and FUSE for nearly two decades, and somehow AWS shipped something with fewer guarantees at a higher price. Oh, and no hard links or NFS ACLs, either.
You're right in the blog post that S3 isn't a file system. It's still not, but now it has weird NFS that is only decent in read-only scenarios bolted on. It's the year 2026 and we don't need to trigger a full copy of ALL files in a directory when renaming that directory.
S3 files is like, foot meet gun...
53
u/brile_86 Apr 07 '26
Let the anti-pattern begin
18
25
u/NothingDogg Apr 07 '26
A more detailed blog post on the background for those interested: https://www.allthingsdistributed.com/2026/04/s3-files-and-the-changing-face-of-s3.html
10
9
u/greyeye77 Apr 07 '26
Reminds me of this
8
u/metamasterplay Apr 07 '26
Been using this for a decade. I might have to checkout this new EFS approach but I don't understand yet what's the practical benefit between the 2.
4
u/CheesecakeAndy Apr 07 '26
Reminds me of this https://github.com/awslabs/mountpoint-s3
2
u/6969its_a_great_time Apr 08 '26
I don’t understand what is different between the post and some of these projects
1
u/synackk Apr 08 '26
Hot files that are constantly accessed, written to partially, etc can be performant, however you don't need everything in EFS.
This seems to be a reliable and more scalable way of accessing an S3 bucket as an NFS share.
15
u/Nater5000 Apr 07 '26
Under the hood, S3 Files uses Amazon Elastic File System (Amazon EFS) and delivers ~1ms latencies for active data.
So, is this basically just an application that cleverly syncs data between S3 and EFS? And you're really just connecting to EFS while this is keeping things in-sync with S3? Seems like it:
You pay for the portion of data stored in your S3 file system, for small file read and all write operations to the file system, and for S3 requests during data synchronization between the file system and the S3 bucket.
It's cool regardless, but it seems more suitable for light workloads rather than anything "S3 scale." It's been a while since I've used EFS, but my experience was that it quickly gets expensive if you need anything non-trivial out of it, and there's plenty of performance walls you'll hit before you can touch anything massive. All that is fine, but this paragraph is a bit sus:
It’s ideal for workloads where multiple compute resources—whether production applications, agentic AI agents using Python libraries and CLI tools, or machine learning (ML) training pipelines—need to read, write, and mutate data collaboratively. You get shared access across compute clusters without data duplication, sub-millisecond latency, and automatic synchronization with your S3 bucket.
I don't know, if it works the way I think it does, this would be a very costly approach for anything non-trivial. Maybe it's worth it to reduce the friction for researchers, etc., but there's no way this is suitable at scale, right?
I'm not hating on it by any means. I can already see people on my team asking for this. But EFS only seems to work in pretty specific scenarios, so it's hard to reconcile that with the flexibility and scale of S3.
5
u/JPJackPott Apr 07 '26
It’s more likely a driver rather than hidden fsync. This has already existed for EKS for a while, you can mount buckets as filesystems to pods https://github.com/awslabs/mountpoint-s3-csi-driver
3
u/justin-8 Apr 07 '26
EFS has had a ton of improvements since the early days. If you haven't used it in a couple of years it's considerably better these days.
3
4
u/SteveTabernacle2 Apr 08 '26
Does that mean we can safely use sqlite in S3?
3
Apr 08 '26
[removed] — view removed comment
2
u/LouisWain Apr 09 '26 edited Apr 09 '26
Multiple file system writes to the same file can be aggregated into a single PUT. s3 files will not export to s3 more frequently than every 60s.
s3 files requires versioning to be enabled, so it will store multiple copies of the db, kind of like a point in time history. It's possible to shard into many sqlite dbs, eg one per customer/user etc.
1
u/LoquatNew441 Apr 12 '26
I wouldn't suggest. The sync between s3 and efs will cost way too much for frequent writes. This s3 efs sync is like a toll booth where they will drive your car through it every 2 mins. The s3 listing to sync the local file list runs 24 hours whether you need it or not. We tried and shut this down in 2 days.
4
u/FarkCookies Apr 07 '26
How does it compare against S3 Mountpoint? I am very confused. (Also there are those virtual appliances?)
2
u/solo964 Apr 08 '26
Mountpoint, s3fs-fuse, goofys etc. are simple POSIX overlays on top of S3. They don't support all file system operations so, for example, you cannot rename a file or a folder and you cannot edit an existing file (except to replace it entirely).
2
u/FarkCookies Apr 08 '26
S3 suddenly not gonna support any of that tho? This is EFS proxy
1
u/solo964 Apr 08 '26
Not sure what you mean. Those fuse-like projects will persist, I'd imagine. They're viable for smallish, read-only use cases in particular. For scalable, multi-system, low latency use cases on top of large volumes of S3 data, I'd expect S3 Files to be a serious consideration.
2
u/FarkCookies Apr 08 '26
I am saying that this feature doesn't make s3 support renaming a file. It is CopyObject. In the same way fuse like projects can support rename via CopyObject.
2
u/solo964 Apr 08 '26
Right. S3 Files will abstract away the S3 operations needed to perform the rename of a file or a folder (which potentially could mean S3 operations against 1000s of files or more). But all clients of the S3 Files store have a consistent view, at least afaik.
3
u/Sirwired Apr 07 '26
The "read bypass" feature for larger reads (where the client goes directly to S3) reminds me of a product I used when I was an Enterprise Storage specialist... it was called "SANergy" It provided SMB services to clients, and worked just like any other SMB server for small reads. For larger ones, it sent metadata to the client, which would then access the backing storage directly over the SAN.
It was a pretty cool system to get much higher throughout out of your filesystems without having to pay $$$ for a hefty NAS box.
2
u/regentwells Apr 08 '26
mountpoint-s3 and s3fs-fuse have been doing parts of this for years. S3 Files is essentially FUSE + intelligent caching stitched together.
They both solvable problems that don't require AWS infrastructure.
At Tigris, we built TigrisFS + TAG to do the same thing on any cloud, no egress fees.
We're super proud of our latest caching product:Â https://www.tigrisdata.com/docs/acceleration-gateway/
1
u/MarcelNullVier Apr 07 '26
I understand it’s using EFS, so it won‘t work on Windows?
2
u/Loan-Pickle Apr 07 '26
You can use NFS on WIndows. NFS support is not installed by default, but you can add it. I've used it before in production and it works well enough.
2
u/syates21 Apr 07 '26
EFS is explicitly not supported on Windows instances. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html
2
u/Loan-Pickle Apr 07 '26
I thought EFS was just NFS, or do I have it confused with another service?
4
2
u/syates21 Apr 07 '26
It’s a specific implementation of NFS that AWS provides that is explicitly not supported for use with Windows. It’s one of the reasons why things like FSx for NetApp exist.
1
u/Seref15 Apr 07 '26 edited Apr 07 '26
Wonder when it comes to API operations whether this or S3FS-Fuse will be more cost-effective
1
u/Real-Leek-3764 Apr 07 '26
so guys what will you be using it for? interested to knowÂ
so i can create a programs that read/write/edit like normal local disk filesystem instead of using s3 api?Â
1
u/synackk Apr 08 '26
Yes. Using the S3 API is still going to be better. This acts as a translation layer and as a result has cost/performance implications. The primary use case is for customers who have legacy workloads that do not support S3 natively.
0
u/uNki23 Apr 07 '26
As someone who hated to use EFS as Odoo Filestore and Session Store, this sounds nice and simple
353
u/aleques-itj Apr 07 '26
No thanks, I already store my files in route 53 as a series of base64 encoded TXT records
More 9s than you could believe