SNS vs SQS vs Kinesis vs MSK vs EventBridge vs RabbitMQ: An Architect's Decision Matrix

#aws #architecture #systemdesign #kafka

By Swetha Golla · 8 min read · Senior Application Architect

🔗 This post has a live interactive version with a clickable per-service verdict and the full comparison matrix: read it here

TL;DR

Need strict per-key ordering and replay? That's a log, not a queue — Kinesis or MSK. Pick MSK if you need real Kafka wire-protocol compatibility (existing clients, Kafka Streams, ksqlDB, Debezium); pick Kinesis if you'd rather AWS own shard mechanics and you're fine with its API.
Need routing logic based on event content, not raw throughput? EventBridge — pattern-matching rules to many differently-interested targets, not identical delivery to everyone.
Need a simple durable buffer between one producer and one consumer group? SQS. Need the same message fanned out to many independent subscribers? SNS — often paired with SQS underneath.
Already running RabbitMQ, or need AMQP-specific routing? Amazon MQ for RabbitMQ is a lift-and-shift, not a rearchitecture.
The expensive mistake isn't picking a slightly-suboptimal service — it's picking a queue when you needed a log, or the reverse. That's a rewrite, not a config change.

The setup

Scope note: this is a decision matrix for AWS's own catalog, not a survey of every messaging technology that exists. Self-hosted Kafka, Google Pub/Sub, Azure Service Bus, NATS, Pulsar, and plenty of others solve overlapping problems outside AWS's walls — worth knowing about, out of scope here.

A platform team is replacing a single overloaded RabbitMQ broker that has become the answer to every "how do services talk to each other" question for three years running: order events, fraud signals, audit trails, third-party webhooks, and a slow-growing analytics pipeline all queue through it. It works, until it doesn't — a queue depth spike during a promotion in 2025 backed up every consumer behind it, including ones that had nothing to do with the promotion. The team's instinct is to "move it all to AWS-native," as one service. That instinct is the mistake. These six AWS services solve different shapes of the same-sounding problem, and the broker that's currently drowning is actually the right tool for at least one of the workloads still queuing through it.

Six AWS services, six verdicts

SNS — fan-out, not storage. One event needs to reach many independent subscribers — SQS queues, Lambda, mobile push, email/SMS, HTTP endpoints — and you don't need to replay it later. SNS is the AWS-native answer for "one event, many uncoupled consumers."

Watch out: nothing is stored. If a subscriber's endpoint is down when you publish, that delivery is gone unless you attached a per-subscription dead-letter queue — and a DLQ catches failed deliveries, not a full replay of everything published.

MSK — you need real Kafka, not "Kafka-like." You already have Kafka clients, Kafka Streams jobs, ksqlDB, or Debezium CDC connectors in production, or you need strict per-partition ordering and full replay via consumer offset reset, at very high sustained throughput, with an ecosystem that assumes the actual Kafka wire protocol. MSK is that, managed — Cisco's Webex team runs 147 TB and roughly 100 billion messages a day across 12 MSK clusters and 66 brokers, a scale that specifically needed Kafka's partition and consumer-group model.

Watch out: "managed" narrows the operational surface, it doesn't remove it — worth stating plainly since it's not a comparison AWS's own marketing makes. You're still designing topics and partition counts, sizing brokers, planning consumer-group rebalances, and running version upgrades yourself; MSK Serverless narrows this but doesn't eliminate it. Of the six services here, that's more operational surface than any of the serverless options carry, and more than RabbitMQ's single-broker sizing task too — Kafka's partition/rebalancing model is simply a bigger job to own than a broker instance size.

Kinesis — AWS-native replay, without owning Kafka's model. You want a partitioned, replayable log — strict ordering per key, the ability to reset a consumer's iterator to the past and reprocess — but you'd rather AWS handle shard mechanics than run brokers yourself. LaunchDarkly's event-ingestion pipeline scaled from about 1 TB to more than 100 TB a day on Kinesis Data Streams, holding 99.99% availability and 99.99999% durability with end-to-end processing under 30 seconds.

Watch out: each shard is a hard ceiling — 1,000 records or 1 MiB/s in, 2 MiB/s out — so a hot partition key becomes a bottleneck you shard around, not tune away.

EventBridge — content-based routing is the whole point. Different consumers care about different slices of the same event stream — a fraud service wants only high-risk-flagged orders, a warehouse integration wants only orders from one region. EventBridge's pattern matching (up to 5 targets per rule, input transformers) is built for exactly this, across 20+ native AWS targets plus third-party SaaS event sources.

Watch out: it's a router, not a log. There's no built-in replay — Archive & Replay is a separate, additionally-billed feature that only replays what you explicitly archived. It's also not sized for the sustained multi-GB/s throughput Kinesis or MSK are built for.

RabbitMQ (Amazon MQ) — lift-and-shift, or you need AMQP specifically. You're migrating an existing RabbitMQ deployment and don't want to rewrite producers/consumers written against AMQP client libraries, or you need features SQS doesn't have — priority queues, exchange-based routing, delayed-message plugins. Amazon MQ for RabbitMQ exists so that migration is "point your existing client at a new endpoint," not "rebuild the messaging layer."

Worth untangling: a single RabbitMQ queue is point-to-point, same as SQS — once one consumer reads and acks a message, it's gone from that queue, so two consumers on the same queue split the work rather than both seeing everything. Fan-out to multiple independent subscribers happens one level up, at the exchange: a fanout or topic exchange copies the message into several separate queues, each with its own consumer(s). So RabbitMQ-the-broker (exchange + queues) is the closer analog to SNS+SQS combined — not to SQS alone.

Watch out: there's no serverless tier — you pick a broker instance size, size storage, and plan cluster-mode HA yourself, and there's no native replay once a message is acknowledged.

SQS — the simplest durable buffer that works. A producer and a consumer group shouldn't be coupled in time — the classic decoupling pattern behind most well-built AWS backends. If you don't need replay or strict global ordering, SQS is the least operationally demanding option on this list, and usually the right default before reaching for anything fancier.

Watch out: it's a queue, not a log — once a message is deleted (or ages out after up to 14 days) it cannot be replayed, and there's no native fan-out to multiple consumer groups (pair with SNS for that).

The comparison matrix

Dimension	SNS	MSK	Kinesis	EventBridge	RabbitMQ (Amazon MQ)	SQS
Model	Pub/sub fan-out (push)	Partitioned log, Kafka API (pull)	Partitioned log, AWS-native (pull)	Serverless event bus, content routing (push)	Broker queue, AMQP exchanges	Point-to-point queue (pull)
Ordering	None (standard); strict on FIFO topics	Strict per-partition, by key	Strict per-shard, by partition key	None guaranteed	Per-queue FIFO by default; needs Single Active Consumer for strict order with >1 consumer	None (standard); strict per message-group on FIFO
Delivery semantics	At-least-once; FIFO adds dedup	At-least-once by default; exactly-once with transactional/idempotent producer	At-least-once; consumer owns dedup/offsets	At-least-once	At-least-once (manual ack + publisher confirms)	At-least-once (standard); effectively exactly-once on FIFO with dedup ID
Retention / Replay	None — DLQ catches failed deliveries, not replay	Operator-set (commonly 7+ days); full replay via offset reset	24h default, extendable to 365 days; replay via shard iterator	None by default; Archive & Replay is a separate paid add-on	None — gone once acked, no native replay	Up to 14 days, no replay — deleted on ack/expiry
Throughput ceiling	No fixed headline number, raisable soft quota	Broker/cluster-bound (147 TB/day across 12 clusters at Cisco Webex)	1,000 records or 1 MiB/s per shard in, 2 MiB/s out	10,000 PutEvents/sec + 18,750 invocations/sec (us-east-1 default)	Broker-instance bound (mq.m7g family), no elastic auto-scale	Standard effectively unbounded; FIFO high-throughput up to 3,000 msg/sec per partition batched
Routing	Topic → many subscribers, filter policies	Possible via Kafka Streams/consumer-relay (read → filter → re-produce) — app code, not a broker-native rule engine	None — lives in the consumer app	Rich pattern-based routing, up to 5 targets/rule	Exchange types (direct/topic/fanout/headers)	Single queue → competing consumers, no native fan-out
Operational overhead	Near-zero, serverless	High — topic/partition/broker design is yours	Low-medium — shard planning (or On-Demand)	Near-zero, serverless	Medium — broker sizing, HA, upgrades	Near-zero, serverless
Cost model	Per-request + per-delivery	Per-broker-hour + storage, idle or not	Per-shard-hour or per-GB + PUT charges	Per-event + per-target invocation	Per-broker-hour + storage, idle or not	Per-request, no idle cost
Ecosystem	Deep AWS integration	Full Kafka wire compatibility	AWS-native (KCL/KPL, Firehose, Flink)	20+ AWS targets + SaaS sources	Standard AMQP — broad non-AWS ecosystem	Deep AWS integration, universal SDK
Event size limit	256 KB	1 MB default, tunable	1 MiB default, up to 10 MiB (Oct 2025)	1 MB (raised from 256 KB, Jan 2026)	128 MB per message	256 KB standard (2 GB via Extended Client Library)

One mapping worth keeping in mind while reading the RabbitMQ column: a single RabbitMQ queue is point-to-point, the same model SQS uses — it's the exchange sitting in front of RabbitMQ's queues that does fan-out, which makes RabbitMQ-the-broker closer to "SNS + SQS combined" than to SQS alone.

Real-world use cases

Kinesis — LaunchDarkly scaled event ingestion from ~1 TB/day to 100+ TB/day, holding 99.99% availability and 99.99999% durability, specifically for per-consumer isolation and replay.
MSK — Cisco Webex runs 147 TB/day (~100B messages/day) across 12 MSK clusters/66 brokers, migrated in ~6 weeks.
SNS + SQS — the standard AWS fan-out pattern: one topic, one queue per interested consumer, so a slow consumer never blocks the others.
EventBridge — a bus fed by AWS services plus 20+ SaaS partner sources, with rules routing by event content rather than raw volume.
Amazon MQ for RabbitMQ — positioned specifically for lift-and-shift of an existing RabbitMQ/ActiveMQ deployment without rewriting producers/consumers.
SQS — the default decoupling buffer: a producer drops work, an independently-scaled worker fleet drains it.

Rule of thumb

Ask two questions before anything else: do you need replay, and do you need strict per-key ordering? Both yes → Kinesis or MSK. Neither → SQS (add SNS in front only if you need fan-out) is simpler and cheaper. If the actual problem is "route by content to different targets," that's EventBridge, not a throughput question. If you already run RabbitMQ, migrating it as-is beats rebuilding what wasn't broken.

Where I actually stand

The team in the setup above didn't need to replace their RabbitMQ broker — they needed to stop routing everything through one instance of it. The audit trail and analytics pipeline belonged on a log (Kinesis) from day one, because someone was always going to ask "replay last Tuesday" eventually. The webhook fan-out belonged on SNS/SQS, because those consumers never needed to see each other's failures. What was actually fine on RabbitMQ — the order-event routing with its exchange-based rules — stayed on RabbitMQ, just on its own dedicated broker instead of sharing one with everything else. The mistake wasn't the broker they picked three years earlier — RabbitMQ was a reasonable choice at the time, and still is for the workload that kept it. The mistake was answering every later "we need messaging for X" request the same way — bolt it onto the existing broker — instead of asking, each time, which of these models actually fits that workload.

See the decision-advisor POC → A small CLI that takes your ordering/replay/routing/throughput requirements and walks through which of the six it actually points to. Disagree with a cell in the matrix? Tell me which one and why.