What's the difference between AWS SNS vs SQS?Article by Brandon Burrus · Posted on September 5, 2022 · 4 min read

One of the most confusing subjects beginners run into when delving into the world of AWS is the difference between SQS vs SNS. If you're prepping for any of the AWS certification exams, you may have heard the following definitions:

SQS: A fully managed message queuing service that enables decoupled microservices, distributed systems, and serverless applications.
SNS: A fully managed messaging service for both app-to-app and app-to-person communication.

These definitions are technically accurate, but create confusion when trying to determine which service is the correct one to use.

Most of the confusion can be attributed to Amazon's use of the word "message" in reference to SNS. While this is technically accurate, a less confusing term might be "notification", which is what I'll be using when discussing SNS for the rest of this article.

The difference between a notification and a message is really what separates SNS from SQS. Using SNS, notifications are delivered via Pub/Sub topics. Pub/Sub is short for "Publisher-Subscriber"; a publisher publishes notifications to a "topic", and subscribers are able to subscribe to that topic to be notified of each notification.

In contrast, SQS enables messages to be sent to a queue from a sender which can then later be processed by a downstream receiver. Messages that are sent to the queue remain in the queue until they are marked as processed via message deletion (a key distrinction from SNS, where notifcations are simply "sent" but not retained in the topic).

The difference between the delivery of notifications vs messages is really what separates SNS from SQS. SNS uses "push" based delivery, where notifications are "pushed" to subscribers to handle however they like. On the other hand, SQS uses a "pull" based delivery, where messages are "pulled" by a receiver to process the message, then delete it from the queue.

So when should you use SNS over SQS?

SQS is designed as a message queue to represent a "queue" of work that needs to be processed. Messages can be processed by compute services such as a pool of EC2 autoscaling worker instances, a container on ECS, or a serverless Lambda function. Messages should contain all the necessary metadata needed for processing, and could represent all kinds of "processable" things. Common examples include images or other files stored in S3, records in a DynamoDB table, or async communication between two microservices.

SNS is more so meant to deliver notifications to subscribers. These notifications have a number of delivery mechanisms including as an HTTP request, an email, or as an SMS text. SNS is integrated into AWS far more extensively than SQS, and serves as the mechanism by which many services allow a subscriber to be notified of a change in the system. Examples include Billing service notices, EC2 autoscaling events, or build failures from Code Build.

SNS can even publish a notification into an SQS queue as a message. This is more common that you might think, as several queues can be connected to a single notification topic at the same time. This then allows a notification to be processed as a message by multiple consumers, each of which might handle the notification differently. This is called the "fan-out" pattern, and is a very useful tool to have at your disposal when it comes to building distributed systems on AWS.

In summary, SNS is a service designed for "push" based notification delivery, whereas SQS is a service designed for "pull" based message processing. Use SNS when you want to publish events that anyone with access to the topic can subscribe to. Use SQS when you want to represent a stream of work that needs to be processed in some way.