MSK vs Kinesis Cheatsheet (Cost & When to Choose) MSK vs Kinesis Cheatsheet (Cost & When to Choose)

Both Amazon MSK (managed Apache Kafka) and Amazon Kinesis Data Streams move high-throughput event streams. They overlap heavily, but they price very differently and pull you in different directions on lock-in and ops. This is the quick comparison, with the cost angle up front.

Note: Prices are early-2026 ballparks and change often. Treat them as relative comparisons, confirm on the AWS pricing pages.

What each one is

• Amazon MSK — real, open-source Apache Kafka, managed by AWS. Full Kafka API, ecosystem, and portability. Comes as Provisioned (you size brokers) or Serverless (no brokers to size).
• Kinesis Data Streams — AWS’s native streaming service. Proprietary API, deeply integrated with Lambda/Firehose/Flink. Comes as Provisioned (you set shards) or On-demand (auto-scales).

Cost comparison (the headline)

The one-line cost takeaway: Kinesis (especially on-demand or a single provisioned shard) is far cheaper at low or spiky volume; MSK carries a real always-on floor. At very high sustained throughput, MSK Provisioned’s per-GB economics can win.

Worked example: a ~1 MB/s stream

• Kinesis Provisioned: 1 shard handles 1 MB/s in → ~$11/mo + small PUT-unit cost. Cheapest.
• Kinesis On-demand: 1 MB/s sustained ≈ ~2.6 TB/mo × $0.04/GB → **$100+/mo**. On-demand is for spiky, not sustained.
• MSK: overkill at this size, you’re paying the broker/cluster floor regardless.

Lesson: on-demand for spiky, provisioned for sustained — within Kinesis that choice alone can be a 10x cost swing.

Feature comparison

Choosing like a senior DevOps engineer

The default

Default to Kinesis Data Streams (on-demand) for greenfield AWS work: lowest ops, near-zero idle cost, native Lambda/Firehose/Flink integration, automatic scaling. Move to MSK only when a concrete need pulls you there. Don’t adopt Kafka for its own sake, it’s a standing operational commitment even when “managed.”

Questions to ask before you pick

Each “yes” is a reason to leave the default and consider MSK:

1. Do we already run Kafka (apps, skills, tooling, a migration)? → MSK
2. Do we need the Kafka ecosystem (Connect connectors, Kafka Streams, MirrorMaker)? → MSK
3. Do we need portability / multi-cloud / no lock-in? → MSK
4. Are records ever larger than 1 MB, or do we need very long / unlimited retention? → MSK
5. Is throughput very high and sustained (24/7, many MB/s)? → MSK Provisioned can win on unit cost
6. Is volume low, spiky, or unknown? → Kinesis on-demand
7. Are consumers mostly AWS-native (Lambda, Firehose, Flink)? → Kinesis
8. How much ops do we want to own, and how mature is on-call? → less / smaller team → Kinesis (or MSK Serverless)
9. How budget-sensitive are we at low volume? → Kinesis (MSK has a real floor)

If the answers mostly point at AWS-native, low-ops, cost-sensitive, stay on Kinesis. It takes a couple of firm “yes → MSK” answers to justify Kafka.

Monolith vs microservices

• Monolith: you usually don’t need a streaming backbone at all, reach for SQS/SNS/EventBridge first. If you genuinely need a durable, replayable stream (analytics ingest, event sourcing), Kinesis is the low-friction pick; you don’t yet have the many independent consumers that justify Kafka.
• Microservices: many independent producers/consumers, event-driven choreography, per-consumer replay, this is where a durable log earns its keep. Kinesis fits AWS-native microservices well; MSK/Kafka grows compelling as the estate scales: many teams, a shared event backbone, rich Connect integrations to external systems. Kafka is the classic “central nervous system” for a large microservice org.

Server/containers vs Lambda consumers

• Lambda / serverless consumers → Kinesis. Native event source, no VPC wiring, scales and bills per use; on-demand + Lambda is the lowest-friction combo.
• Long-running server/container consumers (EC2/ECS/EKS) running Kafka clients, Kafka Streams, Flink, or Spark → MSK. Standard Kafka clients, consumer groups, and stateful stream processors feel native there.
• Rule: serverless/event-driven consumers → Kinesis; long-running stateful stream processors on servers → MSK.

First, is streaming even the right tool?

A senior instinct is not reaching for Kafka/Kinesis when something simpler fits:

• Just decouple + retry work → SQS
• Fan-out pub/sub → SNS
• Route/filter events across services → EventBridge
• Ordered, replayable, high-throughput log with multiple independent consumers / analytics → Kinesis or MSK

Don’t pay for a streaming platform when a queue solves it.

Quick decision

• Greenfield, AWS-native, cost- and ops-sensitive? → Kinesis (on-demand for spiky, provisioned for steady).
• Already Kafka, need its ecosystem/portability, >1 MB records, or huge sustained throughput? → MSK (Serverless to skip broker ops, Provisioned for max scale).

References and Further Reading

• Amazon Web Services. Amazon MSK pricing.
• Amazon Web Services. Amazon Kinesis Data Streams pricing.
• Amazon Web Services. Amazon MSK: provisioned vs serverless.
• Amazon Web Services. Kinesis Data Streams capacity modes.