# Queue, bus or stream? SQS, EventBridge, Kinesis or Kafka

> Events move between my services. Are SQS, SNS and EventBridge enough, or do I need a stream like Kinesis or Kafka, and at what scale does the answer change? Most streams are queues in disguise. SNS, SQS and EventBridge are production-grade at any volume and cost almost nothing at small scale; a stream starts at about $13 a month (Kinesis) or $558 (Kafka on MSK). Move to Kinesis when consumers need history, replay or order per key, or when steady volume with several consumers makes the fan-out expensive: at 100 events a second it costs 20 times a provisioned stream. Kafka when Kafka itself is required, or when many consumers read a week of history at volume.

- A choice between tools from The Stack by Nicolas Dao (Cloudless Labs, Sydney): when to pick each, and when to run both
- Last reviewed: 1 November 2026, by Nicolas Dao
- Web page: https://cloudlesslabs.com/stack/guides/queue-or-stream/. The whole stack in one file: https://cloudlesslabs.com/stack/brief.md
- Tools: [Amazon SQS](https://cloudlesslabs.com/stack/aws-sqs/index.md) (My default), [Amazon SNS](https://cloudlesslabs.com/stack/aws-sns/index.md) (Use when it fits), [Amazon EventBridge](https://cloudlesslabs.com/stack/aws-eventbridge/index.md) (My default), [Amazon Data Firehose](https://cloudlesslabs.com/stack/aws-firehose/index.md) (My default), [Amazon Kinesis](https://cloudlesslabs.com/stack/aws-kinesis/index.md) (Use when it fits), [Amazon MSK (managed Kafka)](https://cloudlesslabs.com/stack/aws-msk/index.md) (Use when it fits)

## When to pick which

Pick SQS, SNS or EventBridge when:

- Each consumer needs each message once, and nobody needs yesterday's: work queues, notifications, routing.
- Up to the low hundreds of events a second, or a single consumer at any volume.
- Per-message retries, a dead-letter queue per consumer and filtering per subscriber matter more than order.

Pick SNS with an S3 archive when:

- Every message must be kept, cheaply and for good, and replay happens once in a while.
- New consumers can start from today, and a script can re-feed history to one of them when needed.

Pick Kinesis when:

- Consumers read at their own pace, start from history, or replay as part of the job.
- Events for one key (a device, an account) must be processed one by one, in order, at volume.
- Steady volume with several consumers: from about 100 events a second, the SNS fan-out costs 20 times a provisioned stream.

Pick Kafka on Amazon MSK when:

- Kafka itself is the requirement: compacted topics, transactions across topics, Kafka Connect or Debezium.
- Many consumers and a week or more of history at volume: with ten consumers and seven days, MSK is the cheapest stream from about 1,500 events a second.

Both, when:

- A stream at the core and SQS behind the consumers that need per-message retries: a Lambda reads the stream and writes the work into a queue with its own dead-letter queue.
- SNS for notifications and EventBridge for AWS's own events, next to a stream for the high-volume data: three jobs, three tools in one system.
- Kinesis first and MSK later is a real path: Atlassian moved about 145 billion events a day from Kinesis to MSK in 2026, when cost and the number of consumers grew.

Questions that change the answer:

- Does any consumer need yesterday's events, or need to replay them? If not, you don't need a stream.
- How many events a second, sustained, and how many consumers read each one? That decides where the cost lines cross.
- Must events for one key be processed one by one, in order, at volume? That's a keyed stream.
- Is Kafka itself required: compaction, transactions, Connect, a Kafka estate? Then it's MSK, whatever the volume.

## What it costs before the first message

If your budget is five dollars a month, the answer is a queue: no stream on AWS costs that little.

| Option | Before the first message, per month | 1,000 events a second, three consumers |
|---|---|---|
| SNS → one SQS queue per consumer | $0 (1 million publishes and 1 million SQS requests free) | about $3,910 |
| EventBridge → one SQS queue per consumer | $0 | about $6,410 |
| Kinesis, provisioned | about $13 (one shard) | about $78 |
| Kinesis, on-demand | about $36 per stream | about $680 |
| Kafka on Amazon MSK, Standard brokers | about $558 (three brokers, the production minimum) | about $634 |
| MSK Serverless | about $684 | |
| MSK Express brokers | about $1,117 | |
| Kafka on EC2, run yourself | about $388, plus the people who run it | |

1 KB events, Sydney. Sources, checked on 1 November 2026: [SQS pricing](https://aws.amazon.com/sqs/pricing/), [SNS pricing](https://aws.amazon.com/sns/pricing/), [EventBridge pricing](https://aws.amazon.com/eventbridge/pricing/), [Kinesis Data Streams pricing](https://aws.amazon.com/kinesis/data-streams/pricing/), [Amazon MSK pricing](https://aws.amazon.com/msk/pricing/) and the AWS Price List for Sydney.

A stream starts at the price of a lunch (Kinesis) or a laptop every month (Kafka). Those minimums are the first filter: below them, the question is which queue, not which stream.

## Fan-out or stream: what happens after a message is read

Both designs move events from producers to consumers. The difference is what the pipe remembers.

| | SNS → SQS queues (fan-out) | Kinesis or Kafka (a stream) |
|---|---|---|
| After a consumer reads a message | It's deleted from that consumer's queue | It stays in the log until retention ends: 24 hours to 365 days on Kinesis, for good with compaction on Kafka |
| A consumer added next month | Sees messages from the day it subscribes | Can start from the oldest record kept and catch up |
| Reprocessing after a bug | The messages are gone, unless you archived them | The consumer moves back to Tuesday and reads again |
| Order | None; FIFO queues up to 300–3,000 messages a second each | Kept per key (a device, an account), at any volume |
| Retries and failures | Per message, with a dead-letter queue per consumer | Per shard: one bad record holds up the records behind it until you skip it |
| Filtering per consumer | Yes, free on SNS message attributes | No: every consumer reads everything |
| Lambda | Batches of up to 10 from SQS; one invocation per message straight from SNS | Batches per shard, up to 10,000 records |

A concrete case: order events go to billing, email and analytics.

- With SNS and SQS, each service gets its own copy, and that's all this job needs.
- Analytics had a bug last Tuesday. With SNS and SQS, Tuesday's events were deleted once processed; with Kinesis, the analytics consumer rewinds and reprocesses.
- A fraud service arrives next month and wants the last seven days. A queue can't give it that; a stream can.

If none of those three needs applies, you don't need a stream, whatever the volume. Most streams are queues in disguise.

## The same job, priced at every scale

**Chart: The same job at every scale: three consumers, events kept 24 hours.** Sydney list prices on 1 November 2026, 1 KB events, the pipe only (consumers' compute left out). Both axes are logarithmic: each step is ten times the last. The shaded band is where the default limits start: Firehose 1,000 requests a second, EventBridge 1,200 calls, SNS 1,500 publishes. USD a month, by events a second, sustained:

| Events a second, sustained | 1 | 10 | 100 | 1,000 | 10,000 | 100,000 |
|---|---|---|---|---|---|---|
| SNS → 3 SQS queues | $3.38 | $38 | $391 | $3.9k | $39k | $392k |
| SNS → 3 SQS queues + S3 archive (Firehose) | $4.45 | $49 | $498 | $5k | $50k | $499k |
| EventBridge → 3 SQS queues | $6.01 | $64 | $641 | $6.4k | $64k | $641k |
| Kinesis, provisioned | $13 | $14 | $19 | $78 | $714 | $7.1k |
| Kinesis, on-demand | $36 | $42 | $100 | $680 | $6.5k | $64k |
| Kafka on Amazon MSK | $566 | $566 | $569 | $634 | $1.3k | $9.8k |

Reading it from left to right:

- **Under about 10 events a second,** everything but Kafka costs less than a lunch a month. The lines cross (Kinesis provisioned undercuts the SNS fan-out from about 4 a second), but a few dollars either way is no reason to pick a design. Pick by shape: queues for work, a stream for history and replay.
- **Around 100 a second,** the gap becomes real: about $391 a month for the SNS fan-out and $641 for EventBridge, against $19 for a provisioned stream. Kafka on MSK crosses the fan-out at about 150 a second.
- **From about 1,000 a second,** the default limits start to bite (the shaded band) and the fan-out costs thousands a month against $78 for Kinesis. That's stream territory.
- **With three consumers, Kafka never becomes the cheapest stream:** at 100,000 events a second, Kinesis provisioned is about $7,100 and MSK about $9,800.

On-demand Kinesis is the easy button and the expensive one: it climbs like the fan-out lines, to about nine times provisioned at volume. Start on-demand while the volume is unknown, and switch to provisioned once it's steady. An archive on S3 adds about 27% to the SNS line: [A log without a stream](#a-log-without-a-stream).

## When consumers multiply

**Chart: When consumers multiply: ten consumers, events kept 7 days.** Sydney list prices on 1 November 2026, 1 KB events, the pipe only (consumers' compute left out). Both axes are logarithmic: each step is ten times the last. USD a month, by events a second, sustained:

| Events a second, sustained | 1 | 10 | 100 | 1,000 | 10,000 | 100,000 |
|---|---|---|---|---|---|---|
| SNS → 10 SQS queues | $12 | $127 | $1.3k | $13k | $127k | $1.27M |
| Kinesis, provisioned | $99 | $101 | $124 | $509 | $5k | $49k |
| Kinesis, on-demand | $38 | $54 | $213 | $1.8k | $18k | $177k |
| Kafka on Amazon MSK | $566 | $566 | $572 | $666 | $1.6k | $15k |
| Kafka on EC2, run yourself | $388 | $390 | $420 | $754 | $4.1k | $39k |

Ten consumers and a week of history change the order:

- **Kafka on MSK becomes the cheapest stream from about 1,500 events a second.** Its consumer groups cost nothing extra, while each Kinesis consumer pays for every GB it reads. At 100,000 a second: MSK about $15,300, Kinesis provisioned about $49,300, Kinesis on-demand about $177,400.
- **Kinesis on-demand beats provisioned below about 40 events a second** here, because provisioned bills extended retention and each fan-out consumer per shard-hour.
- **Kafka on EC2 is cheaper than MSK only below about 700 events a second,** by less than $200 a month and before anyone's time. Above that, the replication it pays for between AZs costs more than MSK's markup.
- **The SNS fan-out** to ten queues reaches about $12,700 a month at 1,000 a second.

So the scale where Kafka pays off isn't a throughput number. It's throughput times consumers times history. The details, and Kafka's other reasons, are in [Kinesis or Kafka on AWS?](https://cloudlesslabs.com/stack/guides/kinesis-or-kafka/index.md)

## A log without a stream

There's a middle design that covers most of what a log gives you: SNS fanning out to its consumers, plus one more subscriber, an [Amazon Data Firehose](https://cloudlesslabs.com/stack/aws-firehose/index.md) stream that writes every message to S3 as compressed hourly files. Every message is kept for good, at S3's price, and consumers can be added at any time.

What it doesn't give you is replay as a feature: re-feeding history to one consumer is a small script you write (read a time window from S3, drop duplicates by message ID, sort by timestamp, send to that consumer's own queue). It costs about $0.40 per million messages, against about $5.80 for a Lambda that writes each message to S3 itself. The whole design, priced and set up, is in [An event backbone that keeps everything](https://cloudlesslabs.com/stack/guides/event-archive/index.md).

EventBridge has the same idea built in: an archive keeps the events you choose (for good by default), and a replay resends a time window to the bus's rules, billed like new events.

## Order per key

A stream is split into lanes: shards on Kinesis, partitions on Kafka. Each record carries a key you choose (a device ID, an account ID), and every record with the same key goes to the same lane, in the order it was written. The consumer reads each lane in sequence and lanes in parallel. You get order where it matters (everything about account 123) and parallelism where it doesn't (account 123 against account 456).

A door sensor sends "opened" at 10:00:01 and "closed" at 10:00:03. Through SNS straight to Lambda, the first delivery fails and is retried after the second has been processed: the dashboard says the door is open. Through Kinesis keyed by device, "closed" can't be processed before "opened" has succeeded.

Without a stream, a version number or timestamp in each event and a consumer that ignores anything older than what it stored ("update only if newer") keeps the latest state right. It can't apply every step in sequence: a deposit, then a withdrawal, in that order. That's what a keyed stream is for.

## The limits you meet first

| Service, Sydney | Default limit | Can it be raised? |
|---|---|---|
| SNS standard topics | 1,500 publishes a second, per account | Yes, a soft quota |
| EventBridge (classic bus) | 1,200 PutEvents calls a second, up to 10 events each | Yes |
| Firehose (Direct PUT) | 1,000 requests a second and 1 MiB/s per stream | Raised automatically when it throttles, or on request |
| SQS standard queues | Nearly unlimited | |
| SQS FIFO queues | 300 calls a second (3,000 messages batched); 9,000 calls in high-throughput mode | |
| Kinesis on-demand | 200 MB/s written per stream | On request |
| MSK Serverless | 200 MB/s in, 400 MB/s out per cluster | Split the load across clusters |

Sources, checked on 1 November 2026: [SNS quotas](https://docs.aws.amazon.com/general/latest/gr/sns.html), [SQS quotas](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html), [Firehose quotas](https://docs.aws.amazon.com/firehose/latest/dev/limits.html), [Kinesis quotas](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html), [MSK quotas](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html).

## How the numbers were made

One cost model, the same for every line: 1 KB events, Sydney list prices on 1 November 2026, the pipe only (the consumers' own compute is left out; SNS calling a Lambda directly adds $0.20 per million messages per consumer, which SQS and streams avoid by batching). SNS publishes in batches of 10; each copy SNS or EventBridge puts into a queue is an SQS request, and Lambda receives and deletes in batches of 10. Kinesis provisioned picks the cheapest mix of shared reads and enhanced fan-out, without aggregating records (the producer library's aggregation cuts its PUT cost about 25 times). MSK uses Standard brokers sized to the traffic, fetch-from-follower and tiered storage beyond 24 hours. The archive is an SNS subscription to Firehose writing GZIP files. The model is a script in the site's repository, re-run whenever a price changes.

## Related

- [Event-driven plumbing](https://cloudlesslabs.com/stack/use-cases/events/index.md): the use case this guide works through
- [Amazon SQS](https://cloudlesslabs.com/stack/aws-sqs/index.md): the full entry (verdict, pricing, gotchas)
- [Amazon SNS](https://cloudlesslabs.com/stack/aws-sns/index.md): the full entry (verdict, pricing, gotchas)
- [Amazon EventBridge](https://cloudlesslabs.com/stack/aws-eventbridge/index.md): the full entry (verdict, pricing, gotchas)
- [Amazon Data Firehose](https://cloudlesslabs.com/stack/aws-firehose/index.md): the full entry (verdict, pricing, gotchas)
- [Amazon Kinesis](https://cloudlesslabs.com/stack/aws-kinesis/index.md): the full entry (verdict, pricing, gotchas)
- [Amazon MSK (managed Kafka)](https://cloudlesslabs.com/stack/aws-msk/index.md): the full entry (verdict, pricing, gotchas)
- [Messaging or streaming?](https://cloudlesslabs.com/concepts/messaging-or-streaming/index.md): the concept behind it
- [Every decision guide, the choices between tools first](https://cloudlesslabs.com/stack/guides/index.md)
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)