Elastic Storage Billing for Agent Workloads

Agent workloads break the whole premise behind fixed-capacity storage billing. You provision for a size you can predict, and agents never give you a predictable size to work with. Everything below is just the receipts on that one idea.

The scale of money flowing into AI infrastructure, and how little of it solves the storage problem

Global AI infrastructure spending crossed $250 billion in 2025. Storage and networking grew almost as fast as compute did, so this is an everything story, not just a GPU story. Total spend jumped roughly 166% in a single year, and bigger models, multimodal setups, real-time analytics, and retraining loops that never really stop running all played a part.

More than half of organizations say data and storage bottlenecks cap their AI performance, and only a quarter of AI projects deliver the return anyone promised the board. The pattern is consistent across organizations: the model sits on top of a constraint that was there the whole time, and nobody wanted to look at it before the compute bill arrived.

Companies buy the equivalent of race cars and park them on gravel. They spend big on compute, then inherit a storage setup built for a world where nobody's workload jumps from 10 megabytes to 10 gigabytes in the middle of a session. The billing model itself counts as architecture here, whether anyone treats it that way or not. Paying for capacity you never touch, or scrambling for more the moment a workflow balloons, isn't a side effect of bad infrastructure. It is the bad infrastructure.

How subagent fan-out turns storage consumption into a variable no one can pre-provision

Subagent fan-out is the technical term. The plain version: one agent spins up a bunch of smaller agents, and each one does its own reads, writes, and scratch work. Every sub-task leaves something behind, logs, half-finished outputs, checkpoints, cached context, and none of it piles up on a schedule anyone could forecast ahead of time.

Uber gave the industry a real data point on this one. The company said publicly it burned through its annual AI budget by April 2026, and one engineer's own token usage hit $40,000 in a single month. That's not a rounding error, and Uber isn't short on engineering talent. If a team with that much horsepower can't predict agent consumption at the session level, nobody can.

Storage isn't sitting off to the side quietly holding files, either. Agents read back their own outputs, rewrite context, and hand state between sub-tasks like a game of telephone played at machine speed. A narrow task might touch a few megabytes, and a task that fans out into a dozen sub-agents, each reading and rewriting shared context, can balloon into gigabytes before anyone notices the meter running.

So you're stuck picking a side, and both sides lose. Provision for the gigabyte ceiling and you pay for idle capacity on every small session, which is most of them. Or provision for the megabyte floor and your big sessions throttle or fail at runtime, usually at the worst possible moment. Neither bet holds up once you're running this at production scale.

What "elastic" actually means in storage billing, and where the term gets abused

Real elastic billing meters what you actually use, in fine increments, with no provisioned floor and no penalty for handing capacity back once you're done. Simple enough on paper. In practice, "elastic" has become one of those words vendors slap on a product page the way a diner slaps "artisanal" on a grilled cheese, hoping nobody asks what changed besides the label.

Take EFS elastic throughput. It scales I/O, which genuinely helps, but it doesn't touch how storage capacity gets billed. You still pay per gigabyte stored, not per gigabyte actually read or written. Tiered storage marketed as "elastic" often just means data shuffles between hot and cold tiers, manually or on a timer. That's provisioning with extra steps.

Serverless platforms run a version of the same trick. They charge per compute unit consumed, which sounds usage-based and feels modern, then quietly bill storage as a flat GB-month line underneath it. The compute half breathes, while the storage half doesn't move at all.

Here's a test that cuts through the marketing fast: if an agent session uses 200 MB for 40 minutes and then lets it go, does the bill reflect 200 MB for 40 minutes, or the size of whatever provisioned block happened to contain it? For agent workloads, the number that actually matters is active cache, meaning what's being read, written, and held in low-latency reach right now, not what's archived or cold.

The hidden inflation factors in current serverless and tiered storage pricing

Elastic Cloud Serverless went generally available across the big three clouds through 2025 (AWS in December 2024, Google Cloud in April 2025, Azure in June 2025), and it's a good case study in how complexity hides inside a pricing page that looks clean at first glance.

Ingest metering runs on uncompressed, normalized, fully enriched data volume, a number that can dwarf the raw or compressed size that actually crossed the wire. An agent that ingests context, then re-ingests a slightly modified version of that same context a few minutes later, compounds this quietly, and nobody flags it until the bill shows up looking wrong.

Searchable snapshots, the frozen tier, cut storage cost by up to 90% versus the hot tier. Except the underlying object storage (S3, Azure Blob, GCS) gets billed separately, on its own line. Architects who miss that detail end up double-billed, wondering why the "90% savings" tier isn't saving what the brochure promised.

EFS has its own gotchas too. Cross-AZ access tacks on transfer charges that never show up next to the storage line item, and agents running distributed sub-tasks across zones trigger these silently, invoice after invoice. Pick elastic throughput mode when your traffic is actually sustained rather than bursty, and you end up paying more for the same performance provisioned throughput would give you at a lower rate. Replication charges stack up quietly too, if nobody's watching.

The pattern underneath all of it: pricing that looks simple at the tier level turns complicated fast, because agents generate exactly the access patterns, repeated re-reads, parallel writes, rapid state changes, that hit the expensive edges of every pricing model out there. Cost control for agent workloads means reading the access-pattern multipliers buried in the fine print, not memorizing the headline rate per gigabyte.

Why object storage has become the de facto data layer for AI, and what it still can't do alone

Object storage (S3, GCS, R2, Azure Blob) runs 5 to 10 times cheaper per terabyte than block storage, and it scales to exabytes without anyone provisioning ahead of time. The economics tilt so hard in its favor that most AI platforms have settled on it as the central layer, the place where compute and storage scale independently but still share the same data underneath.

Nearly 30% of cloud-based object storage deployments now sit at 10 petabytes or larger. That's the scale where small performance gaps stop being academic and start costing real money, fast.

There's a real gap here, though. For vector search, the kind that powers RAG, S3 Vectors runs 10 to 50 times higher latency than purpose-built alternatives, landing in the 200 to 500 millisecond range when interactive agent tasks need responses under 100 milliseconds. Optimized setups can push up to 5x the throughput of plain S3 over HTTP (over 100 GB/s aggregate read versus roughly 20 GB/s standard), but nobody gets there with a default config. Getting there means doing the actual work of building for it.

GPUs sit idle waiting on data more often than they sit idle waiting on more compute, and it's worth saying twice because it's the counterintuitive part: the pipe feeding the expensive chip is usually the real bottleneck, not the chip itself.

Agents need two things at once: low-latency reads for whatever's active right now, and cheap durable storage for everything that isn't. Object storage nails the second half but needs a caching layer in front to handle the first. The shape that actually works looks like this: object storage as the source of truth, an NVMe cache layer serving active reads at sub-millisecond speed, and a bill that reflects what's actively cached rather than the size of the whole bucket sitting behind it.

What the compute cost structure reveals about where storage billing reform has the most leverage

GPU compute eats about 55% of the total AI infrastructure bill. Storage and data transfer split the rest, which is still a big enough chunk that sloppy billing there adds up fast.

GPU pricing is all over the map heading into 2026: roughly $2.70/GPU/hr for a preemptible A100 on GCP, up to $13/GPU/hr for an on-demand H100 on Azure, with AWS landing around $12.29/GPU/hr for the same chip. AWS raised prices on its top-tier GPU instances by about 15% in early 2026 (its US West p5e rate moved from $43.26/hour to $49.75/hour), breaking a two-decade streak of cloud compute getting steadily cheaper. Compute has stopped being the reliably shrinking line item everyone assumed it would always be.

Which means the remaining share of the bill matters more every quarter, not less. Data egress and cross-region transfer are usually the multiplier nobody tracks, right up until it crosses 15% of total spend and somebody finally asks why. By that point the issue isn't billing anymore; it's a sign that compute and storage are sitting in the wrong regions relative to each other, and somebody drew the architecture diagram wrong a year ago.

Storing 10 terabytes of training data in standard cloud storage runs roughly $2,000 to $2,300 a year before you touch access or transfer fees. That base cost scales in a straight line with your data, but transfer costs don't. They scale with how the data actually gets used, and for agents that means unpredictably, and often. An elastic billing model that kills idle provisioned capacity and keeps cache physically close to compute trims more than the storage line. It trims the egress and transfer charges riding along on top of it.

The architectural requirements that make elastic billing work in practice for agent storage

Elastic billing only works if the architecture underneath actually backs it up. A handful of things need to be true at once, and none of them are optional extras.

Billing needs to start at zero and scale from the first byte cached, no floor, because nobody, not even the agent itself, knows ahead of time whether a session needs 1 megabyte or 1 gigabyte. Pair that with active-use metering: the billable unit should be whatever's actually being read or written right now, not whatever's sitting at rest. A dataset untouched for three hours shouldn't cost the same per hour as one getting hammered with reads.

The bucket has to stay the source of truth. Nobody should have to migrate data out of their own S3 or GCS bucket to get any of this working. Archil, for instance, mounts those buckets as a native filesystem without copying data anywhere. The agent reads and writes through a mounted filesystem backed by the bucket the customer already owns. On top of that, the filesystem needs full POSIX behavior, atomic rename, file locking, mmap, hard links, because agents and the tooling around them assume all of it just exists. Skip a piece and you're forcing rewrites that cost time and money nobody budgeted for.

Multiple agent runs need to read and write the same data at once without stepping on each other. A filesystem that serializes access defeats the entire point of fan-out. Compute should attach to the filesystem, not the other way around: running agent-written code against files shouldn't require spinning up a separate sandbox or shuffling data somewhere else first. And the whole setup should mount S3, GCS, R2, and Azure Blob the same way, so a team doesn't get locked into whatever one cloud happens to call its elastic offering this year.

How to evaluate elastic storage billing options against agent workload reality

Every option here has an honest use case and an honest limit, and it's worth being straight about both.

Native object storage billed per gigabyte stored is the cheapest thing at rest and genuinely elastic on capacity. Yet the latency is too high for active agent context, there's no POSIX layer, and API call volume at agent-level query rates adds up faster than people expect. EFS and similar managed elastic filesystems bring POSIX compatibility and auto-scaling, but you have to guess right on throughput mode up front, cross-AZ charges punish distributed agent runs, and there's no clean way to sit it in front of a bucket you already have without bolting on a separate sync layer.

Serverless search platforms meter indexing and search consumption in a genuinely usage-based way, and they fit retrieval specifically pretty well. They're not built for general agent storage, though, and that frozen-tier discount only pays off once you're retaining 50 terabytes or more. Purpose-built AI object storage with local caching on GPU nodes solves the latency problem for training and inference throughput. It's S3-compatible and fast, but not really shaped for general-purpose POSIX agent work.

Cloud filesystem layers that mount object storage as POSIX with NVMe caching in front hit sub-millisecond reads on cache hits, bill on actively cached capacity instead of provisioned or total size, keep the bucket as source of truth with zero migration, and let multiple nodes mount at once. Of everything on this list, that's the one shape that checks every box above.

Before signing anything, run it through a few blunt questions. Does the bill track active use or provisioned capacity? Does it require moving data out of the bucket you already have? Does it give you the POSIX behavior your code already assumes exists? Can more than one agent write to it at the same time? And where does the cache physically sit relative to your compute? Somebody's paying for that distance whether it shows up on the invoice or not.

The throughput gap is a cost gap wearing a different outfit. Teams that benchmark storage against the workloads actually running on it, instead of the specs on a vendor's slide, tend to find that GPU idle time from I/O latency is the most expensive line item that never gets its own line. If idle compute hours cross 20% of total runtime, buying more GPUs won't fix a thing. Storage and compute are sitting too far apart, and closing that gap usually pays off more than squeezing the per-gigabyte rate ever will.