If you’ve ever looked at your AWS bill and wondered why your S3 "Request" charges are creeping up to meet your actual storage costs, you’ve likely hit the small-file wall.
Everyone talks about S3 being cheap per gigabyte. That’s the "hook." But the "tax" is in the API calls. For anyone running a modern data lakehouse, using tools like Apache Hudi or Delta Lake, real-time commits create a massive trail of small files. In a standard setup, every one of those tiny files is a billable PUT or GET event.
The math gets ugly fast. If you’re writing millions of small objects, you aren't just paying for data; you’re paying for the privilege of the cloud talking to itself.
The 4MB Logic: Why Aggregation Wins
There is a way to fix this without rewriting your entire ingest pipeline. It comes down to how Amazon FSx for NetApp ONTAP (FSxN) handles the "warm" layer of your data.
Most systems try to move data to S3 at the file level. If you have a thousand 4KB files, that’s a thousand requests. FSxN uses a trick called block aggregation through its FabricPool engine.
Instead of treating every file as a separate trip to the S3 bucket, it works at the 4KB block level. It waits until it has collected 1,024 of these blocks, bundles them into one single 4MB object, and then sends it to S3.
To the S3 bill, that looks like one request, not a thousand. You’ve just cut your API overhead by 99% without touching a single line of application code.
Building a "Hot/Warm/Cold" Reality
We often hear about data tiering, but most of it is clunky. You usually have to pick between high-speed flash (expensive) or object storage (latency-heavy). Using FSxN as your front-end creates a smoother spectrum:
The Hot Tier: Your active Hudi commits stay on the SSDs. Everything is sub-millisecond and fast.
The Warm Tier: As data "cools," it moves to the Capacity Pool. It’s still in the same file system, still accessible to your apps, but it’s sitting on S3-backed storage.
The Cold Tier: Truly historical stuff sits in native S3 for those massive once-a-quarter audits.
The beauty is that the "Warm" layer is transparent. Your developers don't have to know where the data lives. They just see a file path.
It’s Not Just About the Bill
I’ve seen plenty of teams focus only on the cost, but the operational "sanity" is the real win here.
Think about FlexClone. If your data scientists need to test a new model against a 20TB production partition, usually you’d have to copy that data (taking hours) and pay for a second 20TB of storage. With ONTAP, you just clone it. It’s instant, and it costs zero extra space until they start changing data.
The Architect's Take
We need to stop thinking about storage as a "bucket" and start thinking about it as a management layer. If your lakehouse is creating a "small file" nightmare, pointing it directly at S3 is a recipe for a budget disaster.
By putting FSx for NetApp ONTAP in front of your S3 bucket, you’re basically adding an "IQ" to your storage. You get the speed your apps need, the enterprise features (like snapshots and clones) that IT needs, and the S3 prices that Finance wants.
It’s time to stop paying the "API Tax" and start architecting for the real world.
Top comments (0)