MSK vs Kinesis
Amazon MSK runs real Apache Kafka clusters that AWS operates for you, so existing Kafka clients, Connect plugins, and Streams jobs work unchanged. Kinesis Data Streams is AWS's own streaming service with a simpler shard model and tighter Lambda and Firehose integration. Pick MSK for Kafka compatibility, Kinesis for the smallest operational surface.
What each service actually is
MSK is Apache Kafka with the undifferentiated work removed. AWS provisions the brokers, patches them, replaces failed nodes, and manages the metadata layer, but the thing you talk to speaks the Kafka protocol. Anything already written against Kafka points at a new bootstrap server and keeps working: the Java client, librdkafka, Kafka Connect, Kafka Streams, and the whole ecosystem of tools built on top of them.
Kinesis Data Streams is not Kafka and does not pretend to be. It is a stream of records split across shards, read through the Kinesis API or the Kinesis Client Library, and wired into the rest of AWS by configuration rather than code. Firehose can load a stream into S3, Redshift, or OpenSearch with no consumer to write, and Lambda can be triggered directly from a stream. Kinesis Data Streams vs Firehose covers where the line between those two sits.
Throughput and scaling
A Kinesis shard is a fixed unit: 1 MB per second or 1,000 records per second in, and 2 MB per second out shared by the standard consumers on it. You scale by splitting and merging shards, or you use on-demand mode and let AWS resize the stream for you at a higher per-GB price. Individual records cap at 1 MB.
MSK scales the way Kafka does, by partition count and broker size. You choose instance types, replication factor, and partitions per topic, which means you can tune for a workload Kinesis would force into an awkward shard count, and it means those decisions are now yours to get right. MSK Serverless removes the capacity planning at the cost of the tuning knobs. Ordering works the same on both sides: guaranteed within a shard or a partition, never across them.
Retention and replay
Kinesis keeps records for 24 hours by default, extendable to 365 days. MSK retention is bounded by broker storage rather than a service limit, and tiered storage pushes older segments to cheaper storage so a topic can hold months of data without oversized brokers. If your consumers need to rebuild state by replaying from the beginning of time, that difference matters more than throughput does.
What it costs
Kinesis bills per shard-hour plus per million PUT payload units, so cost tracks the shape of your traffic and a stream sitting idle overnight still costs shard-hours. MSK bills per broker-hour plus provisioned storage plus data transfer, so cost tracks the cluster you asked for whether or not it is busy. Neither is reliably cheaper. At low, spiky volume Kinesis on-demand usually wins because there is no cluster to keep warm; at sustained high volume a right-sized MSK cluster usually wins because broker-hours stop scaling with throughput once the brokers are big enough.
Choosing between them
Take MSK when you already have Kafka code, when you need Kafka-specific features like compacted topics or exactly-once transactions, or when portability off AWS is a requirement someone will eventually hold you to. Take Kinesis when the consumers are Lambda functions and Firehose destinations, when nobody on the team wants to think about partitions, or when the stream is one part of an otherwise all-AWS pipeline. Kafka vs Kinesis compares the underlying technologies rather than the two managed services.
Both are internal plumbing. Neither is how you get events to your customers: that is an outbound webhook problem, with its own signing, retries, and per-endpoint delivery logs. A common pattern is to consume from MSK or Kinesis and hand the events to Svix, which owns the delivery side.
Frequently asked questions
Is MSK just Kafka?
Yes. MSK runs open-source Apache Kafka, so the Kafka protocol, clients, Connect plugins, and Streams applications all work unchanged. AWS operates the brokers and the metadata layer; the API you code against is Kafka's.
Can I migrate from Kinesis to MSK?
Not by swapping an endpoint. The APIs are unrelated, so producers and consumers have to be rewritten against Kafka clients. Teams usually dual-write to both streams for a period, cut consumers over one at a time, then retire the Kinesis stream.
Which is cheaper, MSK or Kinesis?
It depends on volume shape. Kinesis on-demand is usually cheaper for low or spiky traffic because there is no cluster to keep running. A right-sized MSK cluster is usually cheaper at sustained high throughput because broker-hours stop growing once the brokers are large enough.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis