That's one way to do it.

> When you create or modify files, changes are aggregated and committed back to S3 roughly every 60 seconds as a single PUT. Sync runs in both directions, so when other applications modify objects in the bucket, S3 Files automatically spots those modifications and reflects them in the filesystem view automatically.

That sounds about right given the above. I have trouble seeing this as something other than a giant "hack." I already don't enjoy projecting costs for new types of S3 access patterns and I feel like has the potential to double the complication I already experience here.

Maybe I'm too frugal, but I've been in the cloud for a decade now, and I've worked very hard to prevent any "surprise" bills from showing up. This seems like a great feature; if you don't care what your AWS bill is each month.

Sell the benefits.

I have around 9 TB in 21m files on S3. How does this change benefit me?

Single PUT per file I assume?

— All writes cost $0.06/GB, since everything is first written to the EFS cache. For write-heavy applications, this could be a dealbreaker.

— Reads hitting the cache get billed at $0.03/GB. Large reads (>128kB) get directly streamed from the underlying S3 bucket, which is free.

— Cache is charged at $0.30/GB/month. Even though everything is written to the cache (for consistency purposes), it seems like it's only used for persistent storage of small files (<128kB), so this shouldn't cost too much.

> For example, suppose you edit /mnt/s3files/report.csv through the file system. Before S3 Files synchronizes your changes back to the S3 bucket, another application uploads a new version of report.csv directly to the S3 bucket. When S3 Files detects the conflict, it moves your version of report.csv to the lost and found directory and replaces it with the version from the S3 bucket.

> The lost and found directory is located in your file system's root directory under the name .s3files-lost+found-file-system-id.

Built in cache, CDN compatible, JSON metadata, concurrency safe and it targets all S3 compatible storage layers.

we run datalakes using DuckLake and this sounds really useful. GCP should follow suit quickly.

For most applications, this is actually a better outcome than the old model. It forces you to think about your actual access patterns instead of choosing a service based on name recognition.

The dangerous case is when teams deploy this without properly profiling. If you provision a large EFS cache assuming "everything will be cached efficiently" without validating that assumption, the bill surprise is real.

This is an architectural pattern that works great once, and then becomes a gotcha once. AWS's fault here isn't the product, it's the documentation — they need a pricing impact section that shows representative costs for different workload types, not just the raw rates.

Same lesson as many AWS products: the service works well when you've thought it through. It works badly when you haven't.