If you’ve ever stared at the AWS console trying to decide between SQS, SNS, EventBridge, and Kinesis, you’re not alone.
Every senior engineer I know has made the wrong call at least once. Let me save you from that.
Here’s the breakdown you actually need.
SQS - The Reliable Workhorse
Amazon Simple Queue Service is your go-to when you need point-to-point communication between services. One producer, one consumer. It holds the message until someone picks it up.
Think of it like a task queue. You throw jobs in, workers pull them out. It’s battle-tested, durable, and scales without you thinking about it.
Best for: Decoupling microservices, async job processing, retry-safe workloads.
Key detail to remember: Messages are consumed and deleted. Only one consumer processes each message.
SNS - The Broadcaster
Amazon Simple Notification Service is a pub/sub model. One message, many subscribers. When something happens, SNS fans out that notification to every service listening: SQS queues, Lambda functions, HTTP endpoints, you name it.
Think of it as a megaphone pointed at multiple services at once.
Best for: Event fanout, multi-consumer notifications, triggering parallel processing pipelines.
Key detail to remember: It’s push-based and has no persistence. If nobody’s listening when the message arrives, it’s gone.
SNS + SQS Fan-out: The Classic Combo
Here’s a pattern that comes up in nearly every production system at scale: combine both. SNS broadcasts the event, and each downstream service has its own SQS queue subscribing to it.
This gives you the reliability of SQS with the fanout capability of SNS. Each consumer processes at its own pace, independently. This is a core pattern in fraud prevention pipelines at high-throughput systems, and for good reason.
EventBridge: The Smart Router
EventBridge is what happens when SNS grows up and gets a rules engine. It’s an event bus that routes events based on content, the actual payload of the message. You write filtering rules, and only matching events hit the right targets.
It’s deeply integrated with AWS services and third-party SaaS providers, making it the backbone of event-driven architectures that span beyond your own code.
Best for: Complex routing logic, cross-account event sharing, AWS-native integrations, event-driven microservices.
Key detail to remember: If your routing logic lives in code instead of infrastructure, you’re doing it wrong. Move it to EventBridge rules.
Kinesis: The Data Stream
Kinesis is a different beast entirely. It’s built for high-volume, real-time data streaming: think logs, clickstreams, IoT telemetry, fraud signals at scale.
Unlike SQS, records in Kinesis are retained for up to 7 days and can be replayed. Multiple consumers can read the same stream independently. It’s ordered within a shard, which matters for time-sensitive analytics.
Best for: Real-time data pipelines, log aggregation, analytics, fraud detection at volume.
Key detail to remember: You pay for shards, not messages. Capacity planning matters here.
The Decision Matrix
| SQS | SNS | EventBridge | Kinesis | |
|---|---|---|---|---|
| Pattern | Point-to-point | Pub/Sub | Event routing | Data streaming |
| Consumers | One | Many | Many (filtered) | Many (replay) |
| Persistence | Yes (up to 14d) | No | No | Yes (up to 7d) |
| Ordering | Optional (FIFO) | No | No | Yes (per shard) |
| Throughput | High | High | Moderate | Very high |
| Best use | Task queues | Fanout | Smart routing | Real-time streams |
The Real Talk
There’s no universal winner. The right choice depends entirely on your traffic pattern, your consistency requirements, and how many consumers need to react to the same event.
What I’ve seen trip up engineers most often is reaching for SQS when they actually need fanout, or using SNS when they need replay capability. Getting this right at the design phase saves you from painful refactors under production load.
Know your data flow. Know your consumers. Then pick your tool.