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.
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.
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.
Monthly cost by platform
| Platform | Sizing | Brokers or capacity | Storage | Data in and out | Cross-AZ traffic | Total | Prices |
|---|---|---|---|---|---|---|---|
| Confluent Cloud (Standard) | 2 capacity units | $1,095 | $2,076 | $5,562 | $0.00 | $8,733 | Partly estimated |
| Self-managed on EC2 | 6 brokers (m5.8xlarge) | $6,728 | $3,185 | $0.00 | $3,185 | $13,098 | Partly estimated |
| Amazon MSK (provisioned) | 6 brokers (m5.8xlarge) | $14,717 | $3,981 | $0.00 | $1,593 | $20,291 | Partly 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.
| Platform | Component | Billed quantity | Unit | Rate (USD) | Per month |
|---|---|---|---|---|---|
| Confluent Cloud (Standard) | capacity units | 1,460 | eCKU-hour | 0.75 | $1,095 |
| Confluent Cloud (Standard) | data in | 37,079 | GB | 0.05 | $1,854 |
| Confluent Cloud (Standard) | data out | 74,158 | GB | 0.05 | $3,708 |
| Confluent Cloud (Standard) | storage | 25,955 | GB-month | 0.08 | $2,076 |
| Self-managed on EC2 | broker hours | 4,380 | broker-hour | 1.536 | $6,728 |
| Self-managed on EC2 | storage | 39,813 | GB-month | 0.08 | $3,185 |
| Self-managed on EC2 | cross-AZ replication | 79,626 | GB | 0.02 | $1,593 |
| Self-managed on EC2 | cross-AZ client traffic | 79,626 | GB | 0.02 | $1,593 |
| Amazon MSK (provisioned) | broker hours | 4,380 | broker-hour | 3.36 | $14,717 |
| Amazon MSK (provisioned) | storage | 39,813 | GB-month | 0.1 | $3,981 |
| Amazon MSK (provisioned) | cross-AZ client traffic | 79,626 | GB | 0.02 | $1,593 |
| Stream | Average | Peak |
|---|---|---|
| Producers write | 15.36 MB/s | 30.72 MB/s |
| Into the brokers (writes × 3) | 46.08 MB/s | 92.16 MB/s |
| Out of the brokers (replication plus consumers) | 61.44 MB/s | 122.88 MB/s |
| Consumers read (2 groups) | 30.72 MB/s | 61.44 MB/s |
| Measure | Value |
|---|---|
| Stored per day, one copy | 1,327.1 GB |
| One copy for 7 days | 9.29 TB |
| All 3 replicas | 27.87 TB |
| Provisioned at 70% full | 39.81 TB |
| Cross-AZ replication per month | 79,626 GB |
| Cross-AZ producer and consumer traffic per month | 79,626 GB |
| Constraint | Brokers needed | Basis |
|---|---|---|
| Storage | 5 | 39.81 TB ÷ 8 TB per broker |
| Network | 1 | 0.98 Gbps at peak ÷ 5 Gbps usable per broker |
| Partition guidance | 1 | 6 partitions × 3 replicas ÷ 4,000 per broker |
| Replication and zone minimum | 3 | max(replication factor 3, 3 zones) |
| Brokers, rounded to a multiple of the zones | 6 | 5 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
| Size | Instance | vCPU | Memory GiB | Network Gbps | Disk cap TB | EC2 $/hour | MSK $/hour | Partitions per broker | Checked |
|---|---|---|---|---|---|---|---|---|---|
| 1tb-1.25gbps | m5.xlarge | 4 | 16 | 1.25 | 1 | 0.19 | 0.42 | 1,000 | Not verified |
| 2tb-2.5gbps | m5.2xlarge | 8 | 32 | 2.5 | 2 | 0.38 | 0.84 | 2,000 | Not verified |
| 4tb-5gbps | m5.4xlarge | 16 | 64 | 5 | 4 | 0.77 | 1.68 | 4,000 | Not verified |
| 8tb-10gbps | m5.8xlarge | 32 | 128 | 10 | 8 | 1.54 | 3.36 | 4,000 | Not verified |
| 12tb-12gbps | m5.12xlarge | 48 | 192 | 12 | 12 | 2.3 | 5.04 | 4,000 | Not verified |
| 16tb-20gbps | m5.16xlarge | 64 | 256 | 20 | 16 | 3.07 | 6.72 | 4,000 | Not verified |
| Platform | Component | Unit | Rate (USD) | Listed range | Checked |
|---|---|---|---|---|---|
| Self-managed on EC2 | broker hours | broker-hour | per broker size | Not verified | |
| Self-managed on EC2 | storage | GB-month | 0.08 | Not verified | |
| Self-managed on EC2 | Cross-AZ replication and clients | GB | 0.02 | Not verified | |
| Amazon MSK (provisioned) | broker hours | broker-hour | per broker size | Not verified | |
| Amazon MSK (provisioned) | storage | GB-month | 0.1 | Checked 2026-11-05 | |
| Amazon MSK (provisioned) | Cross-AZ clients | GB | 0.02 | Not verified | |
| Confluent Cloud (standard) | capacity units | eCKU-hour | 0.75 | Checked 2026-11-05 | |
| Confluent Cloud (standard) | data in | GB | 0.05 | 0.035 to 0.05 | Not verified |
| Confluent Cloud (standard) | data out | GB | 0.05 | 0.035 to 0.05 | Not verified |
| Confluent Cloud (standard) | storage | GB-month | 0.08 | Checked 2026-11-05 | |
| Confluent Cloud (enterprise) | capacity units | eCKU-hour | 2.25 | 1.75 to 2.25 | Not verified |
| Confluent Cloud (enterprise) | data in | GB | 0.05 | 0.02 to 0.05 | Not verified |
| Confluent Cloud (enterprise) | data out | GB | 0.05 | 0.02 to 0.05 | Not verified |
| Confluent Cloud (enterprise) | storage | GB-month | 0.08 | Checked 2026-11-05 |
| Codec | Typical ratio |
|---|---|
| none | 1 |
| snappy | 0.4 |
| lz4 | 0.4 |
| zstd | 0.3 |
| gzip | 0.32 |
| Constant | Value |
|---|---|
| Billed hours per month | 730 |
| Days per month for traffic volumes | 30 |
| Network share allowed at peak | 0.5 |
| Cross-AZ transfer, USD per GB | 0.02 |
| Topic | What catches people out |
|---|---|
| Replication | A replication factor of 3 writes every byte three times: three times the disk, and two extra copies crossing the network between brokers. |
| Consumer groups | Each group reads the full stream, so egress grows with the number of groups. Ten groups is ten times the reads. |
| Cross-AZ transfer | Replication 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. |
| Compression | Ratios depend on the payload. JSON compresses well, already-compressed or encrypted payloads barely compress. Small batches compress worse. |
| Partitions | More partitions raise recovery time and per-partition overhead. They can only be increased later, and doing so changes key-to-partition mapping. |
| Retention | Retention is by time and by size, and whichever limit is reached first deletes data. Plan disk for the larger of the two. |
| Disk headroom | Disks that run near full make brokers fail on a burst or on a slow consumer. The utilisation target is the headroom you pay for. |
Last updated 2026-11-05 (dataset 2026-11, refreshed monthly). Entries marked unverified or modelled could not be checked against an official page.
- https://aws.amazon.com/msk/pricing/
- https://aws.amazon.com/msk/faqs/
- https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html
- https://docs.aws.amazon.com/msk/latest/developerguide/limits.html
- https://aws.amazon.com/ec2/instance-types/m5/
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html
- https://aws.amazon.com/ebs/pricing/
- https://aws.amazon.com/vpc/pricing/
- https://instances.vantage.sh/aws/ec2/m5.8xlarge
- https://www.confluent.io/pricing/
- https://docs.confluent.io/cloud/current/billing/billing-dimensions.html
- https://docs.confluent.io/cloud/current/clusters/cluster-types.html
- https://cwiki.apache.org/confluence/display/KAFKA/KIP-780%3A+Support+fine-grained+compression+options
- https://blog.careem.com/posts/benchmarking-kafka-compression-for-increased-performance-and-reduced-cost
Three ways to reduce this number
- Compress on the producer with zstd or lz4: it cuts disk, replication and consumer traffic in proportion to the ratio you reach.
- Shorten retention, or tier cold data to object storage where your platform supports it, so you provision less disk.
- 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.