Kafka vs Kinesis cost: streaming pricing models compared

Quick answer

Kafka and Kinesis price streaming on different models. Kinesis Data Streams bills per shard per hour (about a few cents an hour each) plus per-record and retention charges, so cost scales with provisioned shards or, in on-demand mode, with throughput. Self-managed Kafka or MSK bills for the broker instances, storage, and cross-AZ replication transfer, so cost scales with cluster size regardless of throughput. Kinesis tends to win at low and spiky volume with minimal ops; Kafka or MSK tends to win at high sustained throughput where broker economics beat per-shard pricing.

Streaming platforms all move records from producers to consumers, but they charge for it in very different ways, and the cheapest option flips depending on your throughput profile. Kinesis prices the abstraction (shards or throughput), while Kafka prices the machinery (brokers, storage, and replication). Understanding which model matches your workload is the whole game.

The two pricing models

Option	Billed on	Scales with
Kinesis Data Streams (provisioned)	Shards per hour, records, retention	Provisioned shard count
Kinesis Data Streams (on-demand)	Throughput ingested and retrieved	Actual throughput
Amazon MSK	Broker instances, storage, transfer	Cluster size
Self-managed Kafka on EC2	EC2 instances, EBS, transfer	Cluster size

A Kinesis shard costs about a few cents an hour and provides a fixed slice of throughput, so provisioned Kinesis cost is essentially shard count times hours plus small per-record and retention fees. MSK and self-managed Kafka cost whatever the broker fleet costs (compute plus EBS storage), independent of how much data actually flows, which ties the decision to EC2 pricing fundamentals.

The hidden replication charge

Kafka replicates every message across brokers for durability, and when those brokers sit in different availability zones, that replication crosses paid links. As covered in inter-AZ data transfer cost, cross-AZ traffic runs about a cent per GB each way, and a Kafka cluster with a replication factor of three across three AZs multiplies its write volume over those paid links. This replication transfer is a real part of Kafka economics that a naive broker-only estimate misses, and it partly explains why Kinesis, which handles replication internally in its pricing, can look simpler.

When Kinesis is cheaper

Kinesis tends to win at low, spiky, or unpredictable throughput and where you want zero cluster operations. On-demand mode in particular means you pay for actual throughput with no idle broker fleet, which suits bursty workloads. If your stream sits mostly idle and spikes occasionally, paying per throughput beats paying for always-on brokers sized for the peak. It also avoids the operational cost of running Kafka, which is real even if it does not appear on the cloud bill.

When Kafka or MSK is cheaper

At high sustained throughput, broker economics tend to beat per-shard pricing. A well-utilized Kafka cluster pushing large steady volume can cost less per GB than the equivalent number of Kinesis shards, especially once you apply commitment discounts to the broker instances. Kafka also gives you longer retention and richer ecosystem features that may be worth the operational overhead. The tradeoff is that you now own capacity planning, patching, and the cross-AZ replication bill. Fold both options into your cost forecasting at your expected steady and peak throughput before committing.

Making the call

Estimate your sustained and peak throughput, your retention needs, and your appetite for operations. Spiky, low-volume, ops-averse workloads lean Kinesis (on-demand especially). High-volume, steady, retention-heavy workloads with a team willing to run brokers lean Kafka or MSK, remembering to price the cross-AZ replication transfer. There is no universal winner: the cheapest streaming platform is the one whose pricing model matches your throughput shape, and that is a design-time decision worth pricing carefully.

FAQ

Is Kafka or Kinesis cheaper?

It depends on throughput shape. Kinesis bills per shard per hour or per throughput on-demand, so it wins at low, spiky, or unpredictable volume with minimal operations. Kafka and MSK bill for broker instances, storage, and cross-AZ replication regardless of throughput, so they win at high sustained volume where well-utilized broker economics beat per-shard pricing. Match the pricing model to your workload.

How is Kinesis Data Streams priced?

In provisioned mode you pay per shard per hour (about a few cents each) plus small per-record and retention charges, so cost scales with the number of shards you provision. In on-demand mode you pay for actual throughput ingested and retrieved with no shard management, so cost scales with real usage. On-demand suits bursty workloads; provisioned suits steady, predictable throughput.

Why does Kafka have cross-AZ transfer cost?

Kafka replicates every message across brokers for durability, and when brokers sit in different availability zones, that replication crosses paid inter-AZ links at about a cent per GB each way. A replication factor of three across three AZs multiplies write volume over those paid links, so a broker-only cost estimate that ignores replication transfer understates real Kafka cost.

Does MSK remove the operational cost of Kafka?

MSK removes much of it by managing broker provisioning, patching, and coordination, but you still pay for the broker instances, storage, and cross-AZ replication transfer, and you still do capacity planning. It sits between fully self-managed Kafka on EC2 (most operational work, most control) and Kinesis (least operational work, per-throughput pricing). MSK trades some control for less operational burden at a broker-based cost.

When should I choose Kinesis over Kafka?

When throughput is low, spiky, or unpredictable and you want zero cluster operations. On-demand Kinesis charges for actual throughput with no idle broker fleet, so a stream that sits mostly idle and spikes occasionally is cheaper than always-on brokers sized for the peak. Kinesis also avoids the operational cost of running Kafka, which is real even though it does not appear on the cloud bill.

Does C3X compare streaming costs before deploy?

C3X reads your Terraform and prices streaming resources (Kinesis shards, MSK brokers, associated storage) against a live catalog before deploy, so the cost difference between a shard-based and a broker-based design is visible in the pull request. That helps you evaluate the two pricing models at your expected scale before committing to either.

What to do next

Compare streaming architectures by cost before you commit. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.