Confluent Cloud vs self-hosted Kafka: a TCO model

The decision nobody agrees on

Every team that runs Apache Kafka eventually has the same conversation: is the operational overhead of self-managed Kafka still worth it, or should we move to Confluent Cloud? It is a real trade-off, not a marketing question. The answer depends on numbers your team can compute, not on vendor claims or conference keynotes.

Here is what I have and have not run, so you can weigh this article accordingly. I have run Confluent Cloud in production, first over public endpoints and then over Private Service Connect. I have also operated a self-hosted Kafka Connect cluster. I have not run self-managed Kafka brokers. The broker-side figures below are a model built from documentation and published prices, and I have labelled them that way.

What self-hosted Apache Kafka actually means

Apache Kafka is open source software under the Apache 2.0 license, created at LinkedIn and donated to the Apache Software Foundation. You can run it on any hardware or cloud VM with no licence fee. That is the appeal. The catch is that running Kafka well in production is a specialised discipline, and it costs engineering time.

A production-grade self-hosted cluster needs active management across several areas:

• Sizing and capacity planning. Kafka performance is sensitive to disk I/O, network bandwidth and partition-to-broker ratios. Undersized clusters throttle producers. Oversized clusters waste money. Right-sizing means continuous monitoring and periodic partition rebalancing.
• The ZooKeeper to KRaft move. Apache Kafka 4.0 (March 2025) removed ZooKeeper. Clusters still on ZooKeeper mode are therefore on 3.x, and getting off it is a planned migration with rolling upgrades.
• Replication and rack awareness. A three-broker cluster with replication factor 3 tolerates one broker failure. Spreading replicas across availability zones needs explicit broker.rack configuration and careful replica assignment. Without it, a single zone outage can take the cluster down.
• Consumer lag monitoring. Unbounded lag is the most common silent failure in Kafka systems. You build or integrate lag dashboards (consumer group metrics, Burrow, kafka-lag-exporter) and alerts before a stuck consumer becomes a data freshness incident.
• Schema Registry and Connect. If you use Avro or Protobuf you run a Schema Registry. Connect clusters need their own deployment, configuration management and failure monitoring.
• TLS, SASL and ACLs. Encryption in transit, authentication and topic-level authorisation are recurring work: certificate rotation, credential management, access audits.
• Upgrades and patching. Each major release needs a rolling restart, client compatibility checks, and testing of connectors and the registry against the new brokers.

None of this is impossible, and plenty of teams do it well. It is simply real work, and it is routinely left out when people compare self-managed with managed.

What Confluent Cloud adds

Confluent was founded by Jay Kreps, Neha Narkhede and Jun Rao, who created Kafka at LinkedIn. Confluent Cloud runs Apache Kafka as its core and adds a managed infrastructure layer, extra capabilities and commercial support.

• Elastic scaling. Throughput scales in eCKU units. You do not pre-provision brokers or reassign partitions by hand during a spike.
• An uptime SLA that depends on the tier. Confluent publishes 99.5% for Basic, and 99.9% to 99.99% for Standard and Enterprise depending on configuration (99.9% on one eCKU, 99.99% on two or more). Read the SLA for the tier you would actually buy.
• Managed connectors. A catalogue of fully managed Kafka Connect connectors, so there is no Connect cluster to run.
• Schema Registry included. No separate deployment and no certificate management for the registry endpoint.
• Stream governance. Lineage, schema evolution tracking and tagging, sold as governance packages.
• Managed Apache Flink. Stream processing without a separate Flink cluster.

What the list prices look like

Confluent Cloud pricing is consumption based. At the time of writing, Confluent's published list prices are roughly as follows, and they vary by region, so check the pricing page for yours:

• Basic: first eCKU free, then $0.14 an hour. $0.05 per GB in and out, $0.08 per GB-month stored. 99.5% SLA.
• Standard: $0.75 an hour per eCKU, from about $385 a month. $0.035 to $0.05 per GB in and out, $0.08 per GB-month stored.
• Enterprise: $1.75 to $2.25 an hour per eCKU, from about $895 a month. $0.02 to $0.05 per GB in and out.

To make that concrete, take a workload with 100 GB a day ingested, 200 GB a day read (two consumer groups) and 30-day retention, priced on Standard at the top of the published rate range:

• Base cluster: about $385/month
• Ingress: 100 GB × 30 days × $0.05 = $150/month
• Egress: 200 GB × 30 days × $0.05 = $300/month
• Storage: 3,000 GB-month × $0.08 = $240/month
• Subtotal: about $1,075/month, before private networking, support tier and any additional eCKUs

For a self-managed cluster of similar size, a rough model is three general-purpose VMs at around $280 a month each at on-demand rates (about $840), plus storage for log segments, a monitoring stack and cross-zone network transfer. That lands around $1,500 to $2,000 a month. The infrastructure bills are in the same range. The engineering cost is where the two diverge.

The biggest variable in this decision is not the infrastructure bill. It is the engineering time needed to keep Kafka healthy at your scale.

TCO: the full picture

Total cost of ownership has three parts: infrastructure, engineering time and incident cost. Most comparisons stop at the first. The numbers below are an illustrative model, not measurements from a system I ran, and the engineering line is the assumption that matters most.

The engineering cost assumes $150K to $180K a year per engineer. The conclusion is only as strong as the FTE assumption, so replace my numbers with your own. If your team already runs Kafka with spare capacity and nobody is being pulled off other work, the gap narrows. If operating brokers means pulling engineers off product work, the model understates the cost.

A decision framework

Price self-managed seriously when:

• Sustained throughput is very high. I use roughly 5 TB a day as a rule of thumb, which is a prompt to run your own numbers and not a measured threshold.
• Data residency rules require on-premises or self-managed deployment
• You need broker-level tuning that a managed service does not expose
• You depend on a Confluent Platform feature that Cloud does not offer
• Your team has deep Kafka expertise and real spare operational capacity

Start on Confluent Cloud when:

• Your highest-value work is building pipelines and product features, not operating brokers
• You want managed connectors, Schema Registry or Flink without adding operational surface
• Elastic scaling without pre-provisioned headroom matters to the business
• A vendor SLA is worth more than one your team has to build and defend internally

What I have actually run

My experience sits on the managed side. At Rocket India my team runs Confluent Cloud as the backbone of the Customer Data Platform and the mortgage servicing workloads around it. We moved the estate from public endpoints to Private Service Connect without changing the application layer. That migration is written up in Moving Confluent Cloud Kafka to Private Service Connect.

The one component we operated ourselves was Kafka Connect, as a self-hosted cluster. That is the piece of this article I know first hand. For the broker side, the comparison above is a model, and the honest advice is to build the same model with your own team size, your own throughput and your own on-call reality before you decide.

Frequently asked questions

Is Confluent Cloud just Apache Kafka?

The core event streaming engine in Confluent Cloud is Apache Kafka. Confluent adds managed infrastructure, Schema Registry, managed connectors, stream governance and managed Apache Flink on top of the open source core. Standard Apache Kafka clients work with Confluent Cloud without vendor-specific dependencies.

Can I use open source Kafka clients with Confluent Cloud?

Yes. Applications using standard Apache Kafka producers and consumers work with Confluent Cloud without code changes. Only the bootstrap server addresses and the security configuration need to be updated.

How does Confluent Cloud handle Kafka version upgrades?

Broker upgrades are handled by Confluent. You still need to keep your client library compatible with the protocol versions the service supports, but patching, rolling restarts and broker-level upgrade planning are not your work.

At what scale should I consider self-hosting?

There is no fixed number. At high sustained throughput the per-GB charges start to dominate a managed bill, and that is when it is worth pricing a self-managed cluster seriously. Count the engineering time as well as the VM bill, because that is where most of the cost sits. The 5 TB a day figure in this article is a rough rule of thumb, not a measured threshold.

Have you run self-managed Kafka brokers?

No. I have run Confluent Cloud in production, first over public endpoints and then over Private Service Connect, and I have operated a self-hosted Kafka Connect cluster. The broker-side cost in this article is a model built from documentation and public pricing, not a record of something I ran.