The diskless-Kafka claim, priced

«5–10× cheaper than Kafka in the cloud» is the most-repeated number in streaming right now. It originates with WarpStream, whose argument is that inter-zone networking is over 80% of the infrastructure cost of a Kafka deployment at scale, and it is disputed publicly by AutoMQ, a competitor with its own diskless product.

I cannot settle it with a measurement — the claim is about production-scale, multi-availability-zone traffic, and I have one machine. But the cost half is arithmetic on published prices, and arithmetic does not need a rig. This is a field note, not a benchmark: there are no latency numbers here, because I have not measured any.

The model, and every assumption in it

One AWS region, three availability zones. Cross-AZ transfer is billed at $0.01/GB in each direction, so a gigabyte crossing an AZ boundary costs $0.02 — the same arithmetic that makes 10 TB of inter-AZ traffic cost about $200 a month.

For a Kafka cluster with replication factor 3, brokers spread across the three zones, and neither rack-aware producers nor rack-aware fetch configured, one gigabyte produced crosses a zone boundary roughly three and a third times:

Written out, so you can substitute your own replication factor and consumer count:

cross_AZ_GB_per_GB_produced
  = 0.67                      # producer to a leader in another zone (2 of 3)
  + 2.00                      # leader to two followers, both elsewhere
  + 0.67 * consumer_groups    # fetch, same two-in-three
  = 3.34                      # at one consumer group

cost_per_GB = 3.34 * $0.02    # $0.01 per GB, billed in each direction
            = $0.067

At 10 TB produced per month with one consumer group, that is roughly $670 a month in cross-AZ charges alone — before compute, before storage, before anything you would think of as the cost of running Kafka.

Now the object-storage design. Traffic to S3 within a region carries no transfer charge, so that $670 line goes to zero and is replaced by request costs. Using published rates of $0.005 per thousand PUTs and $0.0004 per thousand GETs — the same rates that make five million PUTs plus fifty million GETs come to about $45 — the bill depends entirely on how many objects you write:

What the arithmetic says

Three things, and the third is the one I did not expect.

The structural claim is right. Inter-zone replication genuinely is the dominant networking cost of a multi-AZ Kafka cluster, and an object-storage design genuinely does eliminate that line rather than reduce it. This is not marketing; it follows from the rate card.

The headline multiple understates this line and overstates the whole. On networking alone, at a sane batch size, the ratio here is closer to 40× than to 5–10×. The published claim is smaller because it covers total infrastructure — and compute does not disappear when storage moves to S3. Somebody still decodes, batches, indexes and serves. A 5–10× total in the presence of a 40× networking line implies compute is a large share of what is left, which is worth knowing if you are modelling your own bill.

The whole advantage is a function of batch size, and nobody says so. At 4 MB objects the design is dramatically cheaper. At 64 KB objects it costs more than the cross-AZ traffic it replaced. The crossover in this model sits somewhere around 200–300 KB per object. That is not a footnote; it is the entire result. A workload with strict latency requirements cannot batch aggressively, which means the systems least able to wait are the ones for which this architecture is least attractive — and that is precisely the workload people are usually trying to serve with Kafka.

What this does not tell you

The part I cannot supply, stated as plainly as I can.

Latency. Object-storage designs trade it away deliberately; figures around half a second get quoted for the S3-backed path against single-digit milliseconds for a tuned Kafka cluster. I have measured neither. If your application cares about the difference, this note has told you nothing about the thing you actually need to know.

Compute. My model prices networking and requests. It does not price the instances doing the work, and the previous section shows that gap is where the difference between 40× and 5–10× lives.

Operational cost. Two systems with the same monthly bill are not the same expense if one of them wakes you up.

Whether the rates still hold. Every figure here is a published price read in August 2026, in one region, with no committed-use discounts. Substitute your own and the arithmetic still works; the shape of the answer is the durable part, not the totals.

And one thing worth holding in view while reading any of this: WarpStream was acquired by Confluent in 2024, and Confluent by IBM in 2026. The loudest critique of the claim comes from a direct competitor. I have no position in any of it, which is the only reason this note is worth more than either of theirs — not because the arithmetic is better, but because nothing rides on where it lands.