Estimate Amazon MSK or Confluent Cloud costs based on broker count, storage, and data throughput. Budget your managed Kafka streaming platform.
Managed Kafka services like Amazon MSK, Confluent Cloud, and Azure Event Hubs provide scalable event streaming without the operational overhead of managing ZooKeeper, brokers, and topic rebalancing. However, costs depend on broker count and size, data retention storage, and data throughput — making accurate estimation essential.
Amazon MSK charges per broker-hour based on instance type, plus storage and data transfer. Confluent Cloud uses a consumption-based model charging for CKUs (Confluent Kafka Units). Both can range from $200/month for a small cluster to $10,000+/month for production workloads.
This calculator models the core cost components of a managed Kafka deployment: broker instances, storage per broker, data ingress, and data egress. Use it to compare self-hosted Kafka on EC2 against managed alternatives and to right-size your cluster for expected throughput.
This measurement provides a critical foundation for capacity planning and performance budgeting, helping teams align infrastructure resources with application requirements and growth projections.
Kafka infrastructure is often one of the most expensive components in a streaming architecture. A poorly sized MSK cluster can cost thousands per month in waste. This calculator helps you right-size broker count and instance type based on throughput requirements, compare managed vs self-hosted costs, and forecast how costs scale with data volume growth.
Broker Cost = brokers × broker_hourly_rate × 730 Storage Cost = brokers × storage_GB × storage_rate Data In Cost = data_in_GB × data_in_rate Data Out Cost = data_out_GB × data_out_rate Total Monthly = Broker + Storage + Data In + Data Out
Result: $1,159.90/month
Three kafka.m5.large brokers at $0.21/hr running 730 hours cost $459.90. Storage of 1,000 GB per broker at $0.10/GB adds $300. Data ingress is free. Data egress of 15,000 GB at $0.02/GB adds $300. Total: $1,059.90/month plus additional minor costs.
Amazon MSK Provisioned charges per broker-hour plus storage and networking. MSK Serverless charges per topic-partition-hour, data in, and data out. Confluent Cloud uses CKUs (Confluent Kafka Units) as the primary billing unit. Each model has different sweet spots based on workload characteristics.
Key factors for broker sizing include throughput (MB/s), partition count, replication factor, and consumer group count. A kafka.m5.large handles ~100 MB/s per broker. For 500 MB/s with replication factor 3, you need at least 5–6 brokers. Over-provisioning by 30–50% provides headroom for traffic spikes.
Self-hosting Kafka on EC2 saves the management premium (roughly 20–40%) but adds significant operational overhead: patching, monitoring, rebalancing, security configuration, and ZooKeeper management. Most teams find managed Kafka worthwhile for production, reserving self-hosted for cost-sensitive environments with strong Kafka expertise.
Start with 3 brokers as the minimum for production. Size based on throughput: each kafka.m5.large broker can handle approximately 100 MB/s. For 300 MB/s throughput, you need at least 3–4 brokers with headroom.
Provisioned is cheaper for steady, high-throughput workloads. Serverless is cheaper for variable or low-throughput workloads where brokers would sit idle. Serverless charges per GB of data and partition-hours.
Amazon MSK includes ZooKeeper nodes at no additional charge. The cost is bundled into the broker pricing. MSK is transitioning to KRaft mode, eliminating ZooKeeper entirely.
Confluent Cloud charges per CKU (basic starts at ~$0.70/hr) plus storage and networking. For small clusters, Confluent can be cheaper. For large clusters, MSK provisioned is usually more cost-effective. Confluent includes additional features like Schema Registry and ksqlDB.
MSK supports EBS gp3 (default), gp2, and io1/io2 storage. GP3 offers the best price-performance for most workloads with baseline 3,000 IOPS. IO1 is for ultra-high-throughput clusters exceeding GP3 capabilities.
Reduce retention periods for non-critical topics, compress messages (LZ4 or zstd), use tiered storage for cold data, right-size broker instances based on actual CPU and network utilization, and consider reserved instances for 1–3 year discounts. Keeping detailed records of these calculations will streamline future planning and make it easier to track changes over time.