When an AWS architecture stops being a single block and splits into services that must talk to each other, the question appears: do I connect them with Amazon SQS, Amazon SNS or Amazon EventBridge? All three decouple components and all three are fully managed — no servers to patch or operate — but they solve different problems. Choosing without criteria is paid for later in latency, in lost events, or in an integration that becomes hard to maintain.
This guide compares the three with decision criteria for technology managers and architects, not just developers.
What each one is, in a sentence
- Amazon SQS (Simple Queue Service) is a message queue: one component drops a message and another picks it up when ready. Communication is point-to-point and the consumer polls the queue (pull model). It is for decoupling and buffering load between parts of a system.
- Amazon SNS (Simple Notification Service) is a publish/subscribe service: a message published to a topic is pushed instantly to all its subscribers (push model). It is for broadcasting the same fact to several destinations at once.
- Amazon EventBridge is a serverless event bus: it receives events from AWS services, your own applications and third-party SaaS, and routes them to the right targets using content-based rules. It is for building event-driven architectures and broad integrations.
The confusion is understandable: all three move messages around. But each one’s communication model is different, and that difference is what decides.
The criteria that actually decide
1. One consumer or many? (coupling)
This criterion filters first. If each message must be processed by a single consumer — an order billed only once, a job run once — SQS is the natural choice: the queue delivers the message, the consumer processes it and removes it.
If the same fact must reach several destinations in parallel — notify inventory, billing and analytics at the same time — you need broadcast: SNS or EventBridge. SNS pushes the same copy to all subscribers; EventBridge routes by rules. This is where the fan-out pattern appears: publish once and react on several fronts.
2. Pull vs push: who controls the pace
SQS works by polling: the consumer asks for messages when it has capacity. That makes it ideal as a buffer: if a spike arrives, messages pile up in the queue and the consumer processes them at its own pace without falling over. It is free backpressure.
SNS and EventBridge push the message to the destination as soon as it happens. They win on latency and on the simplicity of immediate reaction, but the destination has to be ready to receive — which is why an SQS queue is often placed in front of the final consumer, even when the broadcast is done by SNS or EventBridge.
3. Filtering: does each destination get everything or only its share?
With SQS each queue is its own stream: there is no filtering, the consumer receives whatever was put in its queue.
SNS allows filter policies per subscription: each subscriber can receive only the messages whose attributes matter to it, instead of the whole topic.
EventBridge takes filtering further: its rules evaluate patterns over the full event content, not just loose attributes. If your routing depends on “what the event says inside” — type, source, payload values — EventBridge is the most expressive of the three.
4. Persistence and retries
SQS stores messages durably until they are processed, with configurable retention of up to 14 days, and offers dead-letter queues (DLQ) to isolate what fails repeatedly. It is the most robust option when you cannot lose a message.
SNS does not retain the message beyond its delivery retries; to avoid losing events, it is combined with an SQS queue that does keep them. EventBridge can archive and replay events, useful to reprocess history or to debug.
5. Third-party SaaS integrations
Here EventBridge is unique: it receives events directly from partner sources (SaaS applications) and brings them into your architecture without glue code. SQS and SNS do not have that SaaS connector ecosystem. If your integration crosses AWS boundaries toward external tools, EventBridge is the entry point designed for it.
Side by side
| Dimension | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| Model | Queue (point-to-point) | Pub/sub (notifications) | Event bus (routing) |
| Delivery | Pull: the consumer polls | Push: to subscribers | Push: to targets by rules |
| Relationship | 1 message → 1 consumer | 1 message → N subscribers | N sources → N targets |
| Filtering | No (each queue, its stream) | Subscription filter policies | Patterns over the event |
| Persistence | Yes, up to 14 days | No (retries + DLQ) | Archive and replay |
| Ordering | FIFO available | FIFO available | No ordering guarantee |
| Third-party SaaS | No | No | Yes (partner sources) |
| Typical use | Decouple and buffer | Fan-out and notifications | Event-driven architecture |
The three together: the most common case
In real architectures you rarely pick “one of the three”. They are combined based on what each leg needs:
- SNS + SQS (classic fan-out): an event is published once to SNS and reaches several SQS queues; each consumer processes its copy at its own pace, with DLQ for what fails. It is the most used broadcast pattern in AWS.
- EventBridge as a business router: EventBridge receives events from several sources — including SaaS — and, based on content rules, sends them to Lambda, to Step Functions, to an SQS queue or to an SNS topic.
- SQS as a buffer in front of everything: when the final consumer is sensitive to spikes, an SQS queue is placed before it to absorb the burst.
If your architecture must also orchestrate a sequence of steps (not just move messages), the piece that joins in is an orchestrator like AWS Step Functions to coordinate the flow, one more serverless service. And if you are deciding the compute model that will consume these events, we cover it in EKS vs ECS vs Lambda.
How we choose at Caleidos
Messaging and events are the tendons of a decoupled architecture: chosen poorly, they couple what they were meant to separate. At Caleidos we start from the business question — what should happen when this fact occurs, and how many systems react? — before naming a service. From there we design the pattern: a queue to decouple, pub/sub to broadcast, an event bus to route and integrate. It is part of how we build cloud-native applications on AWS, together with microservices and serverless architectures that scale without your team managing servers.
In short
There is no absolute winner among SQS, SNS and EventBridge: there is a fit for the problem. SQS decouples and buffers with durability; SNS broadcasts the same fact to several destinations with low latency; EventBridge routes by content and integrates with the SaaS world. A solid architecture almost always uses more than one, each in the leg where it performs best. If you are defining how your services communicate on AWS, let’s talk: the right decision is made on your real workload, not on a generic table.
