Amazon MSK vs Confluent Cloud: Which Should You Run Kafka On?

What is the difference between MSK and Confluent Cloud?

Amazon MSK (Managed Streaming for Apache Kafka) runs Apache Kafka brokers that AWS operates inside your VPC. You keep AWS Identity and Access Management, CloudWatch and networking next to the rest of your stack, and you choose how much control to keep. Confluent Cloud is Confluent’s multi-cloud Kafka service. Confluent operates the brokers for you, and you connect over public endpoints or private networking depending on the cluster type.

Both sides offer more than one cluster shape. On MSK you pick Provisioned (Standard or Express brokers that you size) or Serverless (capacity that scales with use, within documented quotas). On Confluent Cloud the general-purpose tiers are Basic, Standard and Enterprise, with Freight as a specialty tier for high-scale logging-style workloads, plus Dedicated clusters when you need pre-provisioned capacity. None of these is “just Kafka as a black box” in the same way: MSK stays closer to open-source Kafka in your account; Confluent Cloud leans on Confluent’s Kora engine and a wider managed data-streaming stack.

How do MSK and Confluent Cloud pricing models compare?

Neither vendor publishes a single “price of Kafka”. You compare billing dimensions, then model your own ingress, retention and connector load. Figures below are from the live Amazon MSK pricing and Confluent Cloud pricing pages as of 15 October 2026 (US East examples unless noted). Always re-check the vendor pages for your region before you commit.

MSK provisioned and serverless

MSK Provisioned bills broker instance-hours plus storage. Standard brokers charge for the Apache Kafka instance type (for example kafka.m7g.large at $0.204 per hour in US East (N. Virginia) in AWS’s published example) and for provisioned storage in GB-months (illustrated at $0.10 per GB-month). Express brokers bill a higher hourly rate (AWS’s example uses $0.408 per hour for express.m7g.large), plus a per-GB data-in charge (illustrated at $0.01 per GB) and storage. You also pay standard AWS data-transfer charges for traffic in and out of the cluster; replication between brokers is not charged separately.

MSK Serverless bills cluster-hours, partition-hours, data in, data out and storage used. AWS’s US East (Ohio) example lists $0.75 per cluster-hour, $0.0015 per partition-hour, $0.10 per GB in, $0.05 per GB out and $0.10 per GB-month of storage. Serverless is not unlimited: the MSK quotas page currently caps ingress at 200 MBps and egress at 400 MBps per cluster, and leader partitions at 2,400 for non-compacted topics (120 for compacted), unless you get a quota increase.

MSK Connect is billed separately in MSK Connect Units (MCUs) per hour (AWS’s example uses $0.11 per MCU-hour). MSK Replicator, when you use it, adds its own hourly and per-GB processed charges.

Confluent Cloud eCKUs and throughput

Confluent Cloud bills Elastic CKUs (eCKUs) by the hour, plus data in/out per GB and storage per GB-month. Published starting points on Confluent’s pricing page (15 October 2026):

eCKUs autoscale with load on the serverless-style tiers. Dedicated clusters are capacity-based and priced separately. Partition and throughput ceilings rise with tier (for example Basic lists 1,500 partitions and 250/750 MBps ingress/egress; Enterprise lists up to 96,000 partitions and 1,920/5,760 MBps on the features table).

Hidden costs: networking, storage, connectors

Treat Schema Registry, managed connectors and Flink as integrated but separately billed on Confluent Cloud, not as free add-ons. On MSK the same pattern holds: brokers are one line item; Connect, Replicator, Flink and registry choices are others. For a wider view of cloud Kafka spend, see the TCO of Kafka on public cloud.

Which is easier to operate day to day?

Upgrades and metadata. On MSK Provisioned you still choose broker size, partition layout and when to upgrade the Apache Kafka version. AWS now offers Standard and Express broker types; Express brokers constrain more Kafka configs so you get less rope to hang yourself, at the cost of flexibility. KRaft controllers on MSK are included with the cluster and are not a separate customer-managed fleet. Amazon MSK also supports in-place ZooKeeper-to-KRaft migration on provisioned clusters (after upgrading to a supported 3.9.x line; see current AWS MSK docs for region coverage). For tooling history around that path, see our note on automated MSK ZooKeeper-to-KRaft migration — and prefer the live AWS migration guide over older “no in-place path” claims.

Day-to-day toil. MSK leaves more of broker tuning, partition counting and client networking in your hands. Confluent Cloud removes broker instance management: you watch eCKU usage, partition limits and network type instead. That usually means fewer 2 a.m. broker pages, and more attention on cost curves and Confluent-side quotas.

Monitoring and support. MSK plugs into CloudWatch and optional open monitoring. Confluent exposes a Metrics API and console views. Support follows your AWS or Confluent plan. AWS-native teams usually prefer MSK; teams that want one vendor for the streaming platform prefer Confluent.

Partition and throughput ceilings. MSK Serverless quotas (200 MBps in / 400 MBps out, 2,400 leader partitions for non-compacted topics) are hard stops until AWS raises them. Provisioned MSK and Confluent Cloud scale with broker count or tier. Match the ceiling to peak, not average, traffic.

What do you get beyond the brokers?

MSK is the better fit when “beyond the brokers” already lives in AWS (IAM, PrivateLink, Glue, Managed Flink). Confluent Cloud is the better fit when you want connectors, governance and Flink in one commercial stack — and you are willing to pay those line items. OSO also runs Confluent consulting for teams that stay on Confluent Platform or Cloud but need production hardening.

How hard is it to move between them later?

Client compatibility is the easy part: both speak the Kafka protocol, so producers and consumers usually move with configuration changes (bootstrap servers, auth, maybe serializers). The hard parts are networking, identity, schemas, connectors and operational muscle memory.

• MSK → Confluent Cloud: you leave VPC-local brokers for Confluent networking; re-map IAM/SASL; rebuild connector and Flink jobs on Confluent’s managed services; watch eCKU and partition limits during cutover.
• Confluent Cloud → MSK: you bring brokers back into an AWS account; provision Standard or Express (or Serverless if quotas fit); replace Confluent Schema Registry/Connect/Flink with AWS or self-managed equivalents; plan storage and broker sizing that Confluent previously hid behind eCKUs.

For replication during a move, use MirrorMaker 2 or Cluster Linking (on Confluent) / MSK Replicator (MSK-to-MSK). MirrorMaker 1 was removed in Apache Kafka 4.0 (Kafka 4.0 upgrade notes); do not design new pipelines on MM1. OSO’s guide to migrating Kafka to Amazon MSK covers the AWS-side patterns.

Lock-in differs by vendor: MSK ties you to AWS networking and billing; Confluent Cloud ties you to Confluent’s control plane and add-on SKUs. Budget a mirrored traffic phase and a clear offset cutover — neither move is a weekend flip for a large estate.

Which should you choose? A decision checklist

Use this as a working checklist with your platform and finance owners:

1. Are you AWS-only for the next two years? If yes, and your team already runs VPC networking well, start with MSK. If you need Azure/GCP too, Confluent Cloud (or another multi-cloud option) avoids a second Kafka stack.
2. How small is the Kafka-owning team? A two-person platform team usually prefers Confluent Cloud’s lower broker toil. A larger SRE group that already owns Kafka may prefer MSK’s lower unit price and deeper control.
3. Do you need managed connectors and Flink on day one? Count the Confluent Connect/Flink/Governance line items, or the MSK Connect + Managed Flink equivalents. “Included in the console” is not the same as “included in the bill”.
4. Will MSK Serverless quotas fit peak load? If you need more than 200 MBps ingress or 2,400 leader partitions without a quota increase, plan Provisioned (Standard or Express) instead.
5. Is private networking mandatory? On Confluent that points at Enterprise, Freight or Dedicated. On MSK you get VPC-native brokers by default.
6. Compliance and data residency. Map both vendors’ certifications and region coverage to your policy — do not assume parity.
7. Exit plan. Write down how you would mirror out with MirrorMaker 2 or Cluster Linking before you sign the annual commit.

Self-managed Kafka (for example Strimzi on Kubernetes) still wins when you need exotic broker configs or a cost model that beats both managed options at very high, steady throughput — if you can staff it. For production help while you decide, see OSO’s Kafka support.

Key takeaway: MSK keeps Kafka in your AWS account at a lower unit price; Confluent Cloud trades a higher price for less operational work and more managed extras.

Frequently asked questions