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

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 — that's an assessment worth stating plainly since it's not the kind of 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 fully 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.

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, specifically because they needed durability, per-consumer isolation, and replay without adopting Kafka.

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. On-Demand mode auto-scales shards for you at a cost premium; Provisioned mode is cheaper at steady volume but the resharding is on you.

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 — and you'd rather express that as a rule than as consumer-side filtering. EventBridge's pattern matching (up to 5 targets per rule, input transformers to reshape the payload per target) is built for exactly this, across 20+ native AWS targets plus third-party SaaS event sources.

Watch out: it is a router, not a log. There's no built-in replay — Archive & Replay is a separate, additionally-billed feature, and it can only replay what you explicitly chose to archive. It's also not sized for the sustained multi-GB/s throughput Kinesis or MSK are built for; it optimizes for routing logic, not raw volume.

You're migrating an existing RabbitMQ deployment and don't want to rewrite producers and consumers written against AMQP client libraries, or you specifically need RabbitMQ features SQS doesn't have — priority queues, complex exchange-based routing (direct/topic/fanout/headers), delayed-message plugins. Amazon MQ for RabbitMQ exists precisely 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, and not to RabbitMQ being "just a queue."

Watch out: there's no serverless tier here. You pick a broker instance size (the mq.m7g family), size its storage, and plan for cluster-mode HA yourself — AWS patches the host and manages failover, but capacity planning is still yours, and there's no native replay once a message is acknowledged.

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, don't need strict global ordering, and just want messages to survive until something processes them, SQS is the least operationally demanding option on this entire list, and it's 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 SQS has no native fan-out to multiple independent consumer groups; if several different systems all need the same message, put SNS in front of it.