At 100 MiB/s of continuous ingest, your Kafka platform handles about 8.24 TiB of new data each day. A low hourly cluster price tells you little about the full streaming infrastructure cost.
Kafka cloud pricing depends on capacity, retained data, reads, network paths, and the services around the cluster. To compare providers fairly, you need one workload forecast and a separate bill for each architecture. The pricing units come first.
Key takeaways
- Confluent Cloud, Amazon MSK, and Google Cloud bill different combinations of compute, storage, data movement, and add-on services. Their headline rates aren’t interchangeable.
- A replication factor of three increases the resources needed to hold data, but it doesn’t create the same transfer charge on every platform.
- Forecast steady and peak throughput separately. Then price retention, consumer reads, connectors, processing, and private connectivity before discussing discounts.
How Kafka cloud pricing differs across providers
Each provider defines a different boundary around its managed Apache Kafka service. This table shows where the bill starts, not what a production deployment will ultimately cost.
| Service | Primary compute charge | Other costs to model |
|---|---|---|
| Confluent Cloud | CKUs for fixed-capacity dedicated clusters; eCKUs for elastic cluster types | Ingress, egress, storage, connectors, Flink, Schema Registry, and networking |
| Amazon MSK Provisioned | Broker instance hours | Storage, optional provisioned storage throughput, and applicable data transfer |
| Amazon MSK Serverless | Cluster hours | Partition hours and data charges |
| Google Cloud Managed Service for Apache Kafka | Data Compute Unit (DCU) hours | Local storage, long-term storage, and inter-zone transfer |
A CKU, broker hour, and DCU don’t describe equivalent throughput or availability. Compare production workloads with similar data throughput, not unit prices. Record the region and pricing date with every quote; verify regional assumptions, since rates and available options can change.
Confluent Cloud: capacity is only one part of the bill
Fixed CKUs and elastic eCKUs
Confluent Cloud pricing depends on whether you choose dedicated-cluster CKUs (Confluent Kafka Units) or an elastic option. Confluent bills dedicated-cluster CKUs by configured capacity over time. Elastic cluster types use eCKUs that respond to usage, subject to tier capacity limits and minimum billing conditions. The choice matters when peak traffic is brief: fixed capacity remains on the bill between peaks, while elastic capacity depends on how the workload uses the tier.
Confluent’s Cloud billing dimensions also separate cluster capacity from ingress, egress, and storage. Check the current tier-specific rate card rather than treating an eCKU price as a complete cluster price.
Charges outside the stream cluster
Beyond cluster capacity, Confluent Cloud pricing can include charges for managed connectors, based on task time and data processing. Flink uses CFUs and can add stream processing costs, while Schema Registry pricing is a separate billing dimension. Itemize Schema Registry pricing and other add-ons according to the applicable tier and usage.
Also map how applications reach Confluent Cloud. Depending on setup, private networking surcharges and related cloud-provider resources may add charges outside the Confluent invoice. Ask for an itemized estimate covering production, disaster recovery, and nonproduction environments, rather than relying on a single blended streaming rate.
Amazon MSK: provisioned and serverless need separate models
Provisioned clusters
For MSK Provisioned, broker instance hours anchor the estimate. Storage and optional provisioned storage throughput add charges; traffic in and out can incur standard AWS data-transfer fees. Provisioned MSK has no separate partition fees or partition-hour line item, but more partitions can increase broker resource needs.
One exception matters when comparing network bills: the Amazon MSK pricing page says data transfer isn’t charged for broker-to-broker replication traffic within the cluster. Replicas still consume broker and storage resources. Don’t add a generic cross-AZ data transfer fee to an MSK estimate without checking the actual traffic path.
Serverless clusters
MSK Serverless replaces broker sizing with a consumption-based pricing model based on cluster-hour, partition-hour, and data charges. That changes the forecasting problem rather than removing it. Track partition fees, billed by partition-hour, alongside read/write volumes, especially for applications with many topics or consumer groups.
For AWS MSK vs Confluent, compare equivalent throughput and partition layouts, then test both MSK modes against that workload. Provisioned capacity may fit a predictable, heavily utilized workload; serverless may better fit variable demand. Neither result follows from the label alone.
Google Cloud: DCUs, storage, and zone traffic
Compute and storage
Google Cloud bills managed Kafka compute in Data Compute Units (DCUs), measured in DCU-hours. The linked managed Kafka pricing page illustrates six DCUs at $0.09 per DCU-hour, or $0.54 per hour. At an assumed 730 hours, compute alone would cost $394.20. These are illustrative figures, not a complete monthly quote or a universal regional rate.
Local and long-term storage are separate cost dimensions. Google also specifies a minimum of 100 GB of billed local storage per CPU, so even a short-retention cluster needs a storage allowance.
Inter-zone transfer
Google lists inter-zone data transfer separately. At the illustrated rate of $0.01 per GiB, 10 TiB of billable inter-zone traffic would cost $102.40. This example assumes 1 TiB equals 1,024 GiB and excludes all other charges.
Placement and traffic patterns determine whether that volume reflects your deployment. Check which producer, consumer, and replication flows the service meters before applying an inter-zone rate to all bytes.
The bill changes with replication, reads, and retention
Three copies don’t mean three identical charges
A replication factor of three creates a storage replication multiplier of three across brokers. This supports availability but increases storage needs and broker work compared with one copy. Providers meter storage and network traffic differently, so the invoice depends on how each resource is measured.
Three replicas create three copies of the data, but they don’t imply three identical network charges.
Cross-AZ data transfer is a major line item in some architectures. Yet MSK excludes its in-cluster broker replication from data-transfer charges, while Google publishes an inter-zone transfer rate. Producer placement, consumer location, cross-region links, and private endpoints can introduce different charges. Separate each route when forecasting data egress fees.
Reads and retention can outgrow ingest
An ingest-only estimate misses applications that read the same events repeatedly. Measure consumer data throughput by group, including replay and recovery jobs. A new analytics consumer can increase read traffic without adding a single producer.
Retention changes the storage bill too. Seven days of logs, tiered storage, long-term storage, and a recovery copy don’t have identical costs or behavior. Model each retention policy against actual data volume, compression, and replica requirements. For Provisioned MSK, also test whether storage throughput needs its own provisioned charge.
Build a forecast around measured traffic
Describe the workload before choosing prices
Start with data throughput, measured in bytes written per second at steady state and peak. Add peak duration, consumer-read volume, partition count, retention, replication factor, and the zones or regions required for an enterprise deployment. Specify whether throughput is measured before or after compression; mixing the two produces misleading storage estimates.
For scale, 100 MiB/s sustained ingest produces about 8.24 TiB per day. Seven days at that rate leaves roughly 57.7 TiB of logical data before replication, assuming no compaction and that the measured rate reflects stored bytes. This is a workload assumption, not a provider price. Bursts, compression, and retention limits will change it.
Translate the workload into each bill
For an always-on environment, multiply hourly capacity charges by the hours in the month. Use data throughput to estimate metered storage, writes, reads, and applicable transfer. Price connectors, Flink, Schema Registry, and network attachments separately where used.
Run at least three cases to support cloud cost optimization: a typical month, a peak month, and a recovery month. Recovery can combine elevated ingest with consumer replay. Keep service-level and availability requirements consistent across provider quotes; a cheaper single-zone configuration isn’t an equivalent substitute for a multi-zone production cluster.
The result should show both total monthly spend and cost per TiB ingested. That second measure makes growth easier to discuss with finance, provided the supporting workload assumptions remain visible.
Where S3-native architecture changes the comparison
Conventional Kafka brokers maintain local log copies and replicate records between brokers. Adding storage can therefore mean paying for more broker-attached capacity. Tiered storage changes where older data lives, but it doesn’t erase the resources needed for hot data or active replication.
An S3-native architecture such as AutoMQ takes a different approach, separating durable object storage from broker compute. This may reduce some inter-broker replication traffic and make compute scaling less dependent on attached disks. These savings are implementation-specific, depend on the design and workload, and aren’t a property of every Kafka-compatible service.
Compare the full path before switching architectures. Object-store requests, cache capacity, recovery behavior, cross-zone network access, consumer latency, and infrastructure overhead can offset a lower broker or transfer bill. Ask vendors to demonstrate performance and recovery at your partition count and replay rate, using the same availability target as the managed Kafka quote.
Reduce spend without weakening availability
Tune what the workload actually uses
Remove unused topics and connectors, but don’t cut replicas or required zones to meet a cost target. For cloud cost optimization, review overallocated dedicated capacity, excessive retention, unnecessary consumer rereads, and partition counts that no longer match throughput needs.
Set alerts on write and read volume as well as total spend. For shared clusters, assign costs to owning teams using agreed drivers such as throughput, storage, or dedicated capacity. Pixlodo’s FinOps chargeback and showback guide explains how to keep shared infrastructure costs visible without burying them in an arbitrary allocation.
Negotiate against a credible baseline
Bring vendors a twelve-month forecast with steady use, seasonal peaks, and planned growth. Ask them to itemize capacity, storage, networking, data movement, support, and add-ons. Compare published list rates with negotiated estimates. Google publishes one-year and three-year committed use discounts for its managed Kafka service; confirm eligible usage and regional terms before applying a discount.
For Confluent, ask how credits, minimums, and overages apply to each billing dimension. For MSK, evaluate Amazon MSK pricing, AWS charges, and any commercial arrangements against the workload rather than assuming a commitment discounts every line item. Confluent’s comparison with Amazon MSK can help frame feature questions, but validate any vendor cost claim with your own volumes and service requirements.
Frequently asked questions
Is Confluent Cloud or Amazon MSK cheaper?
Neither has a universal price advantage. Confluent spreads charges across capacity and managed capabilities; MSK’s bill depends on its cluster mode and AWS resource usage. Include engineering effort and required features only after producing comparable infrastructure estimates.
Does three-zone replication triple Kafka cloud pricing?
No. It raises resource needs, but providers meter storage and replication traffic differently. In particular, MSK doesn’t charge data transfer for in-cluster broker replication. Calculate replicas and billable network flows separately.
What should an enterprise quote include?
Require the region, uptime assumption, peak throughput, retention, replica count, consumer reads, partition count, networking, and add-ons. Ask for typical and recovery-month estimates, plus the unit rates behind each total.
Conclusion
A 100 MiB/s workload’s Kafka streaming cost rises when retained data, repeated reads, and availability requirements are missing from the first quote. Workload shape is the strongest basis for comparing managed Kafka services.
Price the same production requirements across providers, then test the estimate against a peak and a recovery month. The lowest credible bill is the one that still meets your throughput and reliability targets.
