SQS vs SNS: queue vs pub/sub explained
Amazon SQS is a message queue where messages wait to be pulled and processed by consumers, while Amazon SNS is a publish/subscribe service that pushes each message out to many subscribers at once — queue versus fan-out. They sound similar because both move messages between parts of a system, but they solve different delivery problems and are frequently used side by side rather than as alternatives. This guide sets out what each service actually does, the differences worth knowing before you pick one, and the well-known pattern where they are deliberately combined.
What each service is
Our what is Amazon SQS explainer and what is Amazon SNS explainer cover each service individually; the underlying idea behind both — decoupling parts of a system with a message queue rather than calling each other directly — is covered in what is a message queue, and this comparison does not repeat that ground. In short: SQS holds messages until something asks for them, and SNS delivers a copy of each message to every current subscriber as soon as it is published.
The key differences
The two services are built around a different delivery model:
- Delivery model — SQS is pull-based: consumers poll the queue and take messages off it; SNS is push-based: it sends each message out to subscribers as soon as it is published.
- Consumers — SQS is designed around one message being processed once, typically by workers in a single processing pool; SNS is designed to fan a single message out to many independent subscribers at once.
- Use cases — SQS suits decoupling a producer from a pool of workers that process a backlog at their own pace; SNS suits broadcasting an event to several different systems that all need to know about it.
- Ordering and retention (conceptually) — SQS retains messages until they are processed or expire, giving consumers time to catch up; SNS is built for immediate delivery to whoever is currently subscribed, rather than holding messages for a later reader.
- Coupling — SQS couples a producer to "a queue", with consumers hidden behind it; SNS couples a producer to "a topic", with the number and identity of subscribers free to change without the publisher knowing.
When to choose SQS
Choose SQS when you need to smooth out a spike of work, let a pool of workers process a backlog independently of how fast it arrives, or make sure a message is retried until it is successfully handled. It is the natural fit whenever "something needs to happen to this message, exactly once, eventually" is the requirement.
When to choose SNS
Choose SNS when the same event needs to reach multiple, independent destinations at once — for example notifying several different services, or sending both an email and a push notification, from a single published event. SNS is the right tool when the point is broadcast, not processing by one worker pool.
Often used together, not either/or
SQS and SNS are frequently combined rather than chosen between: the fan-out pattern publishes a single message to an SNS topic, which then delivers a copy to several SQS queues, each feeding its own independent group of consumers. This gets the best of both — one publish event, and each downstream system processing its own copy at its own pace, decoupled from every other subscriber. Recognising this pattern matters more, in practice, than treating SQS and SNS as if you must pick a side.
Where this appears in cert study
Messaging and decoupling patterns, including SQS, SNS and the fan-out combination, are core material in the Developer Associate and Solutions Architect Associate exams, and the underlying "why decouple components" reasoning is introduced as early as Cloud Practitioner.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.