SNS vs SQS vs Kinesis: Stop Guessing, Start Choosing

SNS vs SQS vs Kinesis: Stop Guessing, Start Choosing

Let me be honest: the first time I had to pick between SNS and SQS, I stared at the AWS console for 40 minutes, opened seven tabs, and still second-guessed myself. That was years ago, and today AWS has six—yes, six—different event delivery services. It's overwhelming even for senior architects.

The thing is, this isn't actually a hard problem once you stop thinking about the services and start thinking about the *shape* of the data. Do you need push or pull? Replay? Fan-out? Content-based routing? That's the real decision.

Let me break it down with the framework I wish I'd had back then.

The Contenders (A Quick, Opinionated Primer)

SNS — The Loudspeaker
SNS (Simple Notification Service, https://aws.amazon.com/sns/) is a pub/sub push service. You publish a message, and SNS immediately pushes it to every subscriber—Lambda functions, SQS queues, HTTP endpoints, email, even mobile push. It's fire-and-forget by design: SNS doesn't retain messages and barely retries. If nobody's listening, the message is gone.

**Use it when:** one event should trigger many actions simultaneously.

SQS — The Reliable Queue
SQS (https://aws.amazon.com/sqs/) is a pull-based queue. Producers drop messages in, consumers poll and process at their own pace. It's not pub/sub—it's point-to-point. Messages live up to 14 days, and FIFO queues give you strict ordering and exactly-once processing.

**Use it when:** you're decoupling a producer from a consumer and need reliability without complex routing.

Kinesis — The Time Machine Tape
Kinesis (https://aws.amazon.com/kinesis/) is a streaming data platform. Unlike SQS, where a message is consumed and deleted, Kinesis lets multiple consumers read the same stream independently and replay data for up to 365 days. You get rock-solid ordering per shard and massive throughput.

**Use it when:** you have high-volume streaming data and need replayability.

MSK — Kafka Without the Headache (Okay, Less of It)
MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) is managed Kafka. You get the full Kafka ecosystem—topics, partitions, consumer groups, Kafka Connect, ksqlDB—without building the cluster yourself. But you're still responsible for sizing brokers, tuning, and patching operating systems.

**Use it when:** you already have Kafka skills, need Kafka Connect, or are migrating an existing Kafka deployment.

EventBridge — The Smart Router
EventBridge (https://aws.amazon.com/eventbridge/) is the new kid that grew up fast. It's an event bus with powerful content-based filtering and routing. You don't just publish and pray—you can filter, transform, and route events to different targets depending on their content. It also handles scheduled events (a built-in cron) and natively integrates with 140+ AWS services.

**Use it when:** routing logic depends on the event's content, or you're building a serious event-driven architecture.

RabbitMQ — The Battle-Tested Veteran
RabbitMQ (https://www.rabbitmq.com/) is the decade-old open-source broker. It supports multiple protocols (AMQP, MQTT, STOMP), offers flexible routing with exchanges and bindings, and runs anywhere. On AWS, you'd typically run it on EC2 (https://aws.amazon.com/ec2/) or use a managed third-party service.

**Use it when:** you need complex routing patterns like topic exchanges with wildcards, or multi-protocol support.

The Decision Matrix (Your Cheat Sheet)

Stop comparing feature tables. Ask these six questions instead:

| Question | Best Choice |
|---|---|
| One-to-one decoupling? | SQS |
| One-to-many fan-out? | SNS or EventBridge |
| Multiple independent consumers? | Kinesis |
| Already Kafka-literate or need Kafka ecosystem? | MSK |
| Routing based on message content? | EventBridge |
| Complex/existing routing + many protocols? | RabbitMQ |

My philosophy: **default to AWS-native services unless you have a reason not to.** Running your own broker is operational toil you don't need in 2026.

Real-World Scenarios

Scenario 1: E-Commerce Order Pipeline

You run an online store. When an order is placed, you must send a confirmation email, update inventory, trigger shipping, and notify fraud detection.

Classic fan-out. My pick: **SNS or EventBridge**. Publish one "order.placed" event, and SNS pushed it to an email Lambda, an inventory SQS queue, and a shipping service simultaneously. But if you want filtering (like *only* notifying fraud for orders over $100), EventBridge's content-based rules win. You get simpler consumers—they only receive what they should.

Scenario 2: Clickstream Analytics

Your platform gets millions of clicks per hour, and three teams—analytics, ML, and security—need to consume that data independently. Every team wants replay for at least a week.

This is **Kinesis** territory. With SQS, one consumer reading a message means it's gone for everyone else. Kinesis Data Streams lets three independent consumers read the same data stream simultaneously, each at their own pace. If your analytics team already speaks Kafka, MSK is a fair alternative—but Kinesis requires less operational care.

Scenario 3: Legacy System With Complex Routing

You're modernizing an old point-of-sale system that uses RabbitMQ with topic exchanges like `order.created.retail` and `warehouse.stock.low`. There are hundreds of routing keys wired into backend services.

Porting that logic to SNS would be brutal—SNS only supports basic subscription filtering, not complex patterns. **RabbitMQ** or **EventBridge** both work. EventBridge gives you native AWS integration and a schema registry, but rewiring all those routing rules takes time. Keeping RabbitMQ means less migration effort but leaves you managing EC2 instances for the foreseeable future. I'd choose EventBridge only if the team has the bandwidth; otherwise, run RabbitMQ and focus on bigger fish.

Practical Tips From the Trenches

1. **Start with SQS + Lambda.** It's the simplest asynchronous pattern in AWS. It handles 90% of backend decoupling needs. Add SNS when you need fan-out, EventBridge when you need routing smarts.

2. **Think about replay from day one.** The hard question isn't "can my service handle a failed message?" It's "can my service handle *re-reading the same message twice*?" Kinesis and MSK make replays natural. SQS FIFO gives you exactly-once semantics but limits throughput.

3. **Respect retention limits.** SNS retains nothing. SQS caps at 14 days. Kinesis reaches 365 days with extended retention. MSK defaults to 7 days (configurable higher). If you need audit trails or reprocessing, choose accordingly.

4. **Use long polling on SQS.** It queues up 20 seconds of messages instead of constantly polling empty queues. This single change can slash your SQS bill by 90%.

5. **Avoid the kitchen sink.** I've seen a Lambda trigger an SNS topic, which publishes to an SQS queue, which pushes to another Lambda, which dumps to Kinesis—for a simple file upload. Each hop adds latency and a new failure mode. Just because you *can* chain everything doesn't mean you *should*.

FAQ

Can SNS and SQS be used together?
Absolutely—and it's one of the most powerful patterns in AWS. SNS fans out to multiple SQS queues, and each queue gets processed independently by different services. It combines SNS's fan-out power with SQS's reliability, retention, and retries. This is the pattern behind most serious AWS event-driven architectures.

Is EventBridge replacing SNS?
Not entirely, but it's getting close. EventBridge does everything SNS does—pub/sub, fan-out—plus content-based filtering, schema discovery, and deep AWS integration. For new projects, I default to EventBridge. But if you have a simple push-to-Lambda use case, SNS is still simpler to understand and operate.

When should I choose MSK over Kinesis?
Choose MSK when your team already knows Kafka, when you need Kafka Connect or ksqlDB, or when you're migrating existing Kafka infrastructure. Kinesis wins when you're starting fresh, want less operational overhead, and don't need Kafka's ecosystem.

Is RabbitMQ dead in the AWS world?
No, but it's niche. It shines for complex routing logic and multi-protocol support. Plenty of enterprises still run RabbitMQ in production. But if you're building greenfield on AWS, I'd strongly prefer EventBridge or Kinesis. Manage the migration once and thank yourself later.

Final Thoughts

The "best" messaging service isn't the one with the most features. It's the one that matches the shape of your problem: SQS for simple decoupling. SNS for fan-out. Kinesis for streaming with replay. MSK for Kafka at scale. EventBridge for smart routing. RabbitMQ for old-school complexity.

You now have a mental decision matrix that would have saved me 40 minutes and seven tabs on that first day. Go build something.