II · 10 · Cost Engineering

Source: Apache Kafka 4.4.0-SNAPSHOT (git 04bfe7d, 2026-06-15), KRaft mode. Operational guidance grounded in source code and cited benchmarks.

In the cloud, a Kafka bill is rarely what an engineer expects. The instinct is "more brokers = more money," and compute is real, but on a well-utilised cluster it is usually the smallest of the three line items. The two giants are storage (ingress × retention × replication factor, sitting on local disk that the RF multiplies) and, almost always the largest, cross-AZ network transfer, because Kafka's replication protocol copies every byte RF−1 times between brokers, and in a multi-AZ deployment those copies, plus the producer write to a leader in another zone and every consumer fetch from a leader in another zone, all cross zone boundaries that the cloud provider meters per gigabyte in each direction. Confluent's own teardown of a 100 MBps cluster splits it roughly $2.3k compute / $14.5k storage / $24.2k networking per month, networking "likely over 50%," rising to ~90% once tiered storage shrinks storage (Confluent, empirical). This chapter roots every cost driver in a concrete mechanism you have already met in Part I, gives each lever its dial and its tradeoff, and ends with a worked cost model and an effort/impact-ranked lever table. The cardinal rule here is unusually literal: each dollar has a why, and the why is a byte that some piece of source code decided to copy, store, or compress.

The three cost drivers, each rooted in a mechanism

Kafka's architecture fixes the shape of the bill before you tune anything. Three mechanisms, log persistence, ISR replication, and broker-owned compute, each generate one of the three line items. Internalise the mechanism and the cost becomes predictable arithmetic rather than a surprise.

Driver 1, Storage: ingress × retention × RF

Every byte a producer sends is appended to the leader's log and, because Kafka persists to disk by design (Part I Storage & the Log Engine), written to broker-attached block storage. The log retains it for the configured window, and the replication factor copies the whole log onto RF brokers. The storage bill is therefore the cleanest formula in the chapter:

Storage (GB on disk)

ingress (MB/s) × 86,400 (s/day) × retention (days) × 0.001 (GB/MB) × RF, the two literals are pure unit conversions: 86,400 s/day = 60×60×24 (turns a per-second rate into bytes/day), and 0.001 GB/MB converts MB→GB. Units cancel to GB: (MB/s)·(s/day)·(days)·(GB/MB) = GB.

Storage cost/mo

(GB on disk) × $/GB-month, at the assumed $0.08/GB-mo EBS gp3 rate (Confluent, empirical; an illustrative cloud price, check your bill).

The three multipliers are all operator-controlled, and each maps to a config with a source-verified default:

Driver 2, Network: replication amplification + cross-AZ transfer

This is the one that surprises people, and it is structural. Two distinct things make up the network bill, and both come straight from how Kafka moves bytes.

(a) Replication amplification. When a producer writes 1 GB to a partition leader, the ISR mechanism (Part I Replication & the ISR) copies that GB to each of the RF−1 followers via their replica-fetcher threads. So RF−1 GB of inter-broker traffic is generated per GB ingested, at RF=3, 2 GB of replication per 1 GB written. This shows up on the brokers as kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec / ReplicationBytesOutPerSec (storage/.../BrokerTopicMetrics.java:37–38), watch those to see the amplification directly.

(b) Cross-AZ billing. Inside a single AZ, inter-broker traffic is free. The cloud meters traffic that crosses AZ boundaries, and Kafka's placement guarantees a lot of it crosses:

• Clients (producers and consumers) talk only to the partition leader. With brokers spread across 3 AZs, a leader is in a different AZ from the client ~⅔ of the time. So ~⅔ of produce bytes and ~⅔ of consumer-fetch bytes cross a zone boundary.
• All replication crosses zones when RF spans AZs (the whole point of multi-AZ RF is that the replicas are in different failure domains). That is the ingress × (RF−1) term, and it dominates.

Cross-AZ throughput (3 AZ)

(ingress × ⅔) + (egress × ⅔) + (ingress × (RF−1)), Confluent / AutoMQ formula (empirical). The ⅔ is a probability, not a tunable: with brokers evenly spread over 3 AZs, a randomly placed client shares the leader's AZ 1 of 3 times, so 1 − ⅓ = ⅔ of produce and of fetch bytes cross a zone boundary. The (RF−1) replication term carries no ⅔ because every follower copy is placed in a different AZ on purpose (that is the point of multi-AZ RF).

Effective AWS rate

$0.01/GB in EACH direction → ~$0.02/GB effective (AutoMQ, 2minutestreaming, empirical; illustrative, verify against your cloud bill). GCP ≈ $0.01/GB once; Azure inter-AZ historically free.

Driver 3, Compute: brokers

Compute is CPU, RAM, and NIC on the broker fleet. The CPU-heavy paths are compression/decompression (Part I The Record & Batch Format), TLS handshakes and per-record encryption (Part I Security), request handling across the network/IO thread pools (Part I Network & Threading), and replication fetch. RAM is split: keep the JVM heap small, ~6 GB, and leave the rest of the box to the OS page cache, which is the real read/write accelerator via zero-copy sendfile (Confluent, empirical; the page-cache fetch path is Part I The Fetch Path). On a well-utilised, well-batched cluster, compute is usually the smallest of the three line items; it becomes material only when TLS + high message rates + heavy compression saturate cores, or when over-provisioned brokers sit idle. Right-sizing compute is the subject of Capacity Planning; here we note only that throwing brokers at a throughput problem is cheap, while throwing them at a network-cost problem does nothing, cross-AZ is per-GB, not per-broker.

The levers, each with its mechanism, dial, and tradeoff

Five levers, in roughly increasing order of effort and architectural disruption. The first is nearly free; the last restructures the cost model. Each is grounded in a specific Kafka feature you can point to in source.

Lever 1, Compression: compression.type (cuts storage AND network at CPU cost)

Compression is the highest-leverage, lowest-effort move, because Kafka compresses per record batch on the producer and then stores and replicates the batch still compressed, the broker does not recompress on the happy path, and zero-copy fetch ships the compressed bytes to consumers untouched. So a single producer config simultaneously shrinks storage, replication bytes, cross-AZ transfer, and consumer-fetch bytes. The cost is CPU on the producer (and on any consumer that decompresses).

The source enumerates exactly five codecs and their level ranges in clients/.../record/internal/CompressionType.java:

Ratios and speeds above are Cloudflare's production measurements on ~1 MB / 600-record HTTP-request batches (empirical), they are data-dependent, not guarantees: text/JSON compresses ~10–12×, pre-compressed or binary payloads barely at all. The operational defaults that fall out:

• compression.type=lz4 when CPU/latency matter most, fastest codec, ~1.8–2× shrink, smallest CPU tax. The throughput recipe's default.
• compression.type=zstd when bytes (and therefore cross-AZ + storage cost) matter most, markedly better ratio for moderately more CPU. Cloudflare chose zstd and saved "hundreds of gigabits of internal traffic and terabytes of flash storage," cancelling a hardware expansion (empirical); Trendyol reported ~70% message-size reduction at zstd level 3 (empirical). Tune the level via compression.zstd.level (added with fine-grained level control, KIP-390/KIP-780).

Lever 2, Fetch-from-follower: rack-aware replica selection KIP-392 (kills consumer cross-AZ)

By default, a consumer always fetches from the partition leader, which is in another AZ ~⅔ of the time, generating the cross-AZ consumer-read term. KIP-392 lets a consumer instead read from a same-AZ follower replica, eliminating that term entirely. It is a configuration change, not an architectural one, and on consumer-read-heavy clusters it is the single biggest networking win after compression.

Three configs turn it on; all are source-verified:

The mechanism is worth seeing in source, because its constraints are the tradeoff. The broker resolves the preferred replica in ReplicaManager.findPreferredReadReplica (core/.../ReplicaManager.scala:1964–2013), which builds the candidate set and hands it to the selector. Two guards in that code define the behaviour:

• A follower is a candidate only if it is in the ISR and its logEndOffset ≥ fetchOffset ≥ logStartOffset (ReplicaManager.scala:1985–1987). The comment is explicit: excluding out-of-sync replicas prevents the leader from "continuously pick[ing] the lagging follower … indefinitely."
• RackAwareReplicaSelector then filters to replicas whose endpoint().rack() equals the client's rackId; if the leader is in-rack it returns the leader, otherwise the most caught-up in-rack replica; if none are in-rack it falls back to the leader (clients/.../replica/RackAwareReplicaSelector.java:35–52).

Lever 3, RF and retention as cost dials

Before reaching for new architecture, the two oldest dials give linear savings with no latency penalty, only a durability/availability tradeoff:

• Replication factor. RF multiplies both storage and cross-AZ replication. RF=3 is the durable standard (tolerates one broker loss with min.insync.replicas=2, two losses before unavailability). RF=2 cuts both costs by ⅓ but leaves zero headroom: a single failure drops you to one replica, and min.insync.replicas=2 then blocks all writes to that partition (Part I Replication & the ISR). Reserve RF=2 for explicitly non-critical, reproducible topics. Set via default.replication.factor (default 1) or per-topic.
• Retention. retention.ms (default 7 days, LogConfig.java:134) cuts storage linearly, 3-day retention is half the disk of 6-day. Use retention.bytes (default −1) to cap per-partition size as a hard backstop. Shorter retention is free until someone needs to replay further back than the window allows, which is exactly the gap that Lever 4 fills.

Lever 4, Tiered storage KIP-405 (cheap object store for cold data)

Tiered storage (Part I Tiered Storage) lets a topic keep only a small local tail on broker disk while offloading older segments to object storage (S3/GCS/ABS) via the RemoteLogManager (storage/.../RemoteLogManager.java). Because the RF-multiplied copy lives only on the cheap, single-copy object store, this attacks the storage line item hard, object storage runs ~$0.02/GiB-mo vs ~$0.08–0.10/GiB-mo for EBS, ~4–5× cheaper, and decouples retention from broker disk (so you can keep weeks or months without growing the fleet). Enable it cluster-wide with remote.log.storage.system.enable=true (default false, RemoteLogManagerConfig.java:55,58) and per-topic with remote.storage.enable=true (default false, LogConfig.java:142,253); set the local tail with local.retention.ms / local.retention.bytes (default −2 = "derive from retention.ms/retention.bytes", LogConfig.java:145,146,255,257).

Lever 5, Diskless / object-store-native designs KIP-1150 (restructure the model)

The newest direction attacks the networking floor directly. Diskless designs (WarpStream and AutoMQ commercially; KIP-1150 "Diskless Topics" in Apache Kafka) write produce batches directly to object storage instead of replicating between brokers. With no inter-broker replication and no local-disk RF, the ingress × (RF−1) cross-AZ term, the dominant one, drops to ~0, and durability comes from the object store's own cross-AZ replication (which the provider does not bill back to you as inter-AZ transfer). KIP-1150 was accepted ~March 2026, but acceptance is not a production-ready OSS implementation, treat it as a roadmap item, not a deployable feature, in mid-2026.

A worked cost model

Put it together on one concrete workload so the arithmetic, and the dominance of networking, is unmistakable. Every number below is introduced first as a labeled assumption, then used; the rates are the empirical reference's cited cloud figures (AWS, RF=3, 3 AZs); treat them as illustrative and version-dependent, not a quote, substitute your own measured ingress and your own cloud bill's transfer rates.

Assumptions. Each constant carries its value with units, a one-line why/source, and its kind (workload / config / illustrative cloud rate). Nothing in the derivation uses a number that is not listed here.

Derived: monthly ingress volume. This single quantity feeds every line below, so derive it once:

Derivation. Each row takes the formula from its Driver section, substitutes the assumptions above (so every literal traces to the Assumptions table), and multiplies by the relevant rate. Storage is a stock (bytes resident on disk), so it uses ingress-per-day × retention × RF; the cross-AZ rows are flows over the month, so they scale the monthly volume I. Units are shown so they cancel to dollars.

Adding the three cross-AZ rows: $10,100 + $3,400 + $10,200 ≈ $23,700 of networking. So networking is $23,700 ÷ $32,100 ≈ 74% of the bill; compute is $2,300 ÷ $32,100 ≈ 7%; storage is the remaining ~19%. Why networking dominates: the cross-AZ multiplier (RF−1) + ⅔ + (fanout × ⅔) = 2 + 0.67 + 2.01 ≈ 4.7 applies to the monthly volume at $0.02/GiB each, whereas storage applies a 3× RF to only the resident tail (3 days, not the whole month) at $0.08/GiB-mo, so bytes-in-motion × ~4.7 beats bytes-at-rest × 3 even though the per-GiB storage rate is 4× higher. These figures align with Confluent's published 100 MBps teardown (~$24.2k networking / ~$14.5k storage / ~$2.3k compute); our storage line is lower only because this example assumes 3-day rather than longer retention. (Small differences from the round empirical figures, e.g. ~$10,100 vs the often-quoted ~$10,360, are pure rounding of the ⅔ probability and the $0.02 rate; carry more decimals if you need them to match a vendor sheet.) Now apply the levers in order and watch the bill collapse:

The lever table, ranked by effort vs impact

Decision rule for picking the next lever: identify which line item dominates your bill (measure BytesInPerSec, ReplicationBytesInPerSec, and your cloud cross-AZ transfer report), then pick the lowest-effort lever that targets it.