Skip to content

Kafka storage calculator: partitions, brokers and monthly cost on self-managed, MSK and Confluent Cloud

Size the partitions, brokers, network and disk a Kafka workload needs, then price it on self-managed Kafka, Amazon MSK and Confluent Cloud.

Runs in your browser. Your inputs are not uploaded.Open formulaPrices updated November 2026
How to verify this

Open your browser's network tab and change an input: nothing is sent. The page computes with the formulas and the dated price table below. Some entries in that table could not be checked against an official page and are labelled. The same engine answers the API and the MCP tool, so you can reproduce any scenario from code.

Jump to results

Your inputs

Workload
Average over the day.
Peak rate divided by the average. It sizes the network and the partitions, not the storage.
Uncompressed, key and value together.
Typical ratios in the data table are for JSON payloads. Measure your own.
Your measured ratio. It replaces the dataset's typical ratio for the chosen codec.
Retention and replication
Retention by time. If you also cap by size, whichever limit is hit first applies.
Each group reads the full stream.
How full you let the disks get. Lower means more headroom and more disk.
Partition limits
A conservative per-partition producer limit.
A floor, for the consumer parallelism you want.
Cluster
Brokers are rounded up to a multiple of this.
Disk cap and network bandwidth per broker.
Compare
Platforms to price
Used for analytics and the next-step suggestion only; it never changes the numbers.

50,000 messages/s at 1 KiB need 6 partitions on 6 brokers and 39.81 TB of disk. Storage is the limit.

  • Note:Used a typical zstd ratio of 0.3 (compressed ÷ original) for JSON payloads. Real ratios depend on payload type and batch size; measure yours and enter it as the override.
  • Note:Some prices or specifications behind this result could not be checked against an official page: Self-managed on EC2 broker hours; Self-managed on EC2 storage; cross-AZ transfer rate; Amazon MSK (provisioned) broker hours; Confluent Cloud data in; Confluent Cloud data out; Confluent Cloud billing rules; broker size 8tb-10gbps. Treat the totals as estimates and confirm them in the vendor's own calculator.
Partitions
6
6 needed, rounded to a multiple of 6 brokers
Brokers
6
Storage sets the limit
Provisioned disk
39.81 TB
9.29 TB per copy × 3, at 70% full
Cheapest platform
$8,733
Confluent Cloud (Standard) per month

Monthly cost by platform

Platform comparison, per month
PlatformSizingBrokers or capacityStorageData in and outCross-AZ trafficTotalPrices
Confluent Cloud (Standard)2 capacity units$1,095$2,076$5,562$0.00$8,733Partly estimated
Self-managed on EC26 brokers (m5.8xlarge)$6,728$3,185$0.00$3,185$13,098Partly estimated
Amazon MSK (provisioned)6 brokers (m5.8xlarge)$14,717$3,981$0.00$1,593$20,291Partly estimated

Each component is rounded to the cent on its own and the total is rounded once from the unrounded parts, so the columns can differ from the total by a cent.

What each platform bills
PlatformComponentBilled quantityUnitRate (USD)Per month
Confluent Cloud (Standard)capacity units1,460eCKU-hour0.75$1,095
Confluent Cloud (Standard)data in37,079GB0.05$1,854
Confluent Cloud (Standard)data out74,158GB0.05$3,708
Confluent Cloud (Standard)storage25,955GB-month0.08$2,076
Self-managed on EC2broker hours4,380broker-hour1.536$6,728
Self-managed on EC2storage39,813GB-month0.08$3,185
Self-managed on EC2cross-AZ replication79,626GB0.02$1,593
Self-managed on EC2cross-AZ client traffic79,626GB0.02$1,593
Amazon MSK (provisioned)broker hours4,380broker-hour3.36$14,717
Amazon MSK (provisioned)storage39,813GB-month0.1$3,981
Amazon MSK (provisioned)cross-AZ client traffic79,626GB0.02$1,593
Throughput
StreamAveragePeak
Producers write15.36 MB/s30.72 MB/s
Into the brokers (writes × 3)46.08 MB/s92.16 MB/s
Out of the brokers (replication plus consumers)61.44 MB/s122.88 MB/s
Consumers read (2 groups)30.72 MB/s61.44 MB/s
Storage and traffic
MeasureValue
Stored per day, one copy1,327.1 GB
One copy for 7 days9.29 TB
All 3 replicas27.87 TB
Provisioned at 70% full39.81 TB
Cross-AZ replication per month79,626 GB
Cross-AZ producer and consumer traffic per month79,626 GB
What set the broker count
ConstraintBrokers neededBasis
Storage539.81 TB ÷ 8 TB per broker
Network10.98 Gbps at peak ÷ 5 Gbps usable per broker
Partition guidance16 partitions × 3 replicas ÷ 4,000 per broker
Replication and zone minimum3max(replication factor 3, 3 zones)
Brokers, rounded to a multiple of the zones65 rounded up to a multiple of 3

Provisioned storage as retention grows

Monthly cost as retention (or message rate) changes

Calculating the range…

How it is calculated

Throughput

W      = m × s × ρ            bytes per second on the wire and on disk
W_peak = p × W
In     = R × W_peak           into the brokers (producers plus replication)
Out    = (R − 1) × W_peak + G × W_peak   out of the brokers (replication plus consumers)

Storage

per copy    = W × 86,400 × retention days
all replicas = per copy × R
provisioned = all replicas ÷ u        u = disk utilisation target

Partitions

minimum    = max( ceil(W_peak ÷ producer ceiling), ceil(W_peak ÷ consumer ceiling), minimum partitions )
partitions = minimum rounded up to a multiple of the broker count

Brokers

by storage = ceil(provisioned ÷ disk per broker)
by network = ceil(max(In, Out) ÷ (NIC bandwidth × 0.5))
brokers    = max(by storage, by network, R, AZ count) rounded up to a multiple of the AZ count

Cross-AZ traffic per month

replication = followers in other AZs × W × seconds per month     (R − 1 followers when R ≤ AZ count)
clients     = (1 + G) × W × seconds per month × (AZ − 1) ÷ AZ

Platform cost

each component = (quantity − free allowance) × rate
broker hours = brokers × 730         storage = provisioned GB, or stored GB where usage-priced
Confluent: capacity units = max(peak in ÷ in per unit, peak out ÷ out per unit, partitions ÷ partitions per unit)
monthly total = sum of the unrounded components, rounded once

Assumptions

  • m is messages per second, s the uncompressed message size, ρ the compression ratio (compressed ÷ original), p the peak factor, R the replication factor and G the number of consumer groups. MB is 10^6 bytes, GB is 10^9 bytes and TB is 10^12 bytes (Confluent bills binary gigabytes, 2^30 bytes).
  • Compression ratios in the data table are typical for JSON payloads and are modelled, not measured. They depend on payload type, batch size and codec settings. Measure yours and enter it as the override.
  • Network is planned at half of line rate at peak. Broker sizes use the sustained bandwidth, not the short 'up to' burst some instance sizes advertise.
  • Each consumer group reads the full stream once. Followers are assumed to sit in other availability zones (rack awareness); clients are assumed to be spread evenly over the zones, so a client reaches a leader in another zone with probability (AZ − 1) ÷ AZ.
  • Partition guidance counts partition replicas (leaders plus followers) per broker, as the MSK guidance does. The partition constraint expresses the brokers needed to stay within it. It warns but does not add brokers.
  • Hourly components bill 730 hours a month; traffic volumes use a 30-day month. Confluent capacity is sized for the peak and billed for every hour, which is conservative.
  • Not included: reserved or savings-plan discounts, volume discounts, support plans, taxes, KRaft controllers on self-managed clusters, monitoring, operations staff, and cloud-provider network charges on Confluent Cloud (PrivateLink, peering).

The data behind it

Broker sizes
SizeInstancevCPUMemory GiBNetwork GbpsDisk cap TBEC2 $/hourMSK $/hourPartitions per brokerChecked
1tb-1.25gbpsm5.xlarge4161.2510.190.421,000Not verified
2tb-2.5gbpsm5.2xlarge8322.520.380.842,000Not verified
4tb-5gbpsm5.4xlarge1664540.771.684,000Not verified
8tb-10gbpsm5.8xlarge321281081.543.364,000Not verified
12tb-12gbpsm5.12xlarge4819212122.35.044,000Not verified
16tb-20gbpsm5.16xlarge6425620163.076.724,000Not verified
Platform prices
PlatformComponentUnitRate (USD)Listed rangeChecked
Self-managed on EC2broker hoursbroker-hourper broker sizeNot verified
Self-managed on EC2storageGB-month0.08Not verified
Self-managed on EC2Cross-AZ replication and clientsGB0.02Not verified
Amazon MSK (provisioned)broker hoursbroker-hourper broker sizeNot verified
Amazon MSK (provisioned)storageGB-month0.1Checked 2026-11-05
Amazon MSK (provisioned)Cross-AZ clientsGB0.02Not verified
Confluent Cloud (standard)capacity unitseCKU-hour0.75Checked 2026-11-05
Confluent Cloud (standard)data inGB0.050.035 to 0.05Not verified
Confluent Cloud (standard)data outGB0.050.035 to 0.05Not verified
Confluent Cloud (standard)storageGB-month0.08Checked 2026-11-05
Confluent Cloud (enterprise)capacity unitseCKU-hour2.251.75 to 2.25Not verified
Confluent Cloud (enterprise)data inGB0.050.02 to 0.05Not verified
Confluent Cloud (enterprise)data outGB0.050.02 to 0.05Not verified
Confluent Cloud (enterprise)storageGB-month0.08Checked 2026-11-05
Typical compression ratios for JSON payloads (compressed ÷ original, modelled: measure your own)
CodecTypical ratio
none1
snappy0.4
lz40.4
zstd0.3
gzip0.32
Constants
ConstantValue
Billed hours per month730
Days per month for traffic volumes30
Network share allowed at peak0.5
Cross-AZ transfer, USD per GB0.02
Hidden gotchas
TopicWhat catches people out
ReplicationA replication factor of 3 writes every byte three times: three times the disk, and two extra copies crossing the network between brokers.
Consumer groupsEach group reads the full stream, so egress grows with the number of groups. Ten groups is ten times the reads.
Cross-AZ transferReplication across zones is billed on a self-managed cluster but not on Amazon MSK, and Confluent Cloud lists no such charge. Client traffic across zones is billed on MSK and on self-managed clusters.
CompressionRatios depend on the payload. JSON compresses well, already-compressed or encrypted payloads barely compress. Small batches compress worse.
PartitionsMore partitions raise recovery time and per-partition overhead. They can only be increased later, and doing so changes key-to-partition mapping.
RetentionRetention is by time and by size, and whichever limit is reached first deletes data. Plan disk for the larger of the two.
Disk headroomDisks that run near full make brokers fail on a burst or on a slow consumer. The utilisation target is the headroom you pay for.

Three ways to reduce this number

  1. Compress on the producer with zstd or lz4: it cuts disk, replication and consumer traffic in proportion to the ratio you reach.
  2. Shorten retention, or tier cold data to object storage where your platform supports it, so you provision less disk.
  3. Let consumers read from followers in their own availability zone (fetch from closest replica) so client traffic stops crossing zones.

Use it from code

The same engine is available as a REST endpoint and as an MCP tool named calc_kafka_throughput_storage_planner. Your scenario as an API call:

curl -X POST 'https://api.x12i.com/v1/calc/kafka-throughput-storage-planner' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
  "input": {
    "messages_per_second": 50000,
    "peak_factor": 2,
    "avg_message_bytes": 1024,
    "compression": "zstd",
    "replication_factor": 3,
    "retention_days": 7,
    "consumer_groups": 2,
    "disk_utilization_target_pct": 70,
    "per_partition_producer_mb_s": 10,
    "per_partition_consumer_mb_s": 20,
    "min_consumer_parallelism": 6,
    "az_count": 3,
    "broker_profile": "8tb-10gbps",
    "platforms": [
      "self_managed",
      "msk",
      "confluent_cloud"
    ],
    "architecture_style": "event_driven"
  },
  "options": {
    "explain": false
  }
}'

Schema: GET /v1/calc/kafka-throughput-storage-planner/schema

Frequently asked questions

How much disk does Kafka need?

Take the compressed bytes per second, multiply by 86,400 seconds and your retention in days to get one copy, multiply by the replication factor, then divide by the share of the disk you are willing to fill (70% is a common target). This planner does that and then divides by the disk you put on each broker to count brokers. Add headroom for bursts and for retention by size.

How many partitions should a topic have?

At least enough that no partition exceeds your producer and consumer throughput ceilings at peak, and at least as many as the consumers you want to run in parallel. The planner takes the largest of those, then rounds up to a multiple of the broker count so leaders spread evenly. Avoid far more than you need: partitions add recovery time and per-partition overhead, and vendor guidance caps partition replicas per broker.

Is MSK or Confluent Cloud cheaper?

It depends on the shape of the workload. MSK bills brokers by the hour and storage as you provision it, plus inter-AZ client traffic, so you pay for headroom and idle capacity. Confluent Cloud bills capacity units, every gigabyte in and out, and the data you actually store, so a quiet or spiky workload can cost less while a high, steady throughput with many consumer groups can cost more. Run your numbers above and check the prices behind them: some rows are flagged as not checked against an official page.