What is Amazon SNS? A plain-English explainer
Amazon SNS, short for Simple Notification Service, is a fully managed publish/subscribe messaging service — one component publishes a message to a topic, and every subscriber to that topic receives its own copy, all at once, without the publisher needing to know who or how many subscribers there are. That fan-out pattern is what sets SNS apart from a queue, where a message is typically claimed by one consumer rather than broadcast to many. AWS runs the service itself, so there is no messaging infrastructure to size or maintain. Here is how the publish/subscribe model works, what SNS is commonly used for, and how it relates to Amazon SQS, its queueing sibling.
The publish/subscribe model
In a publish/subscribe (pub/sub) system, a publisher sends a message to a named topic without knowing or caring who, if anyone, is listening. Anything subscribed to that topic — an email address, a queue, a function, an application endpoint — receives its own copy of the message automatically. The publisher and subscribers never talk to each other directly; the topic is the only thing connecting them.
This is a different shape to a request that expects a direct response: publishing is fire-and-forget from the publisher’s side, and the number of subscribers can grow or shrink without the publisher ever changing.
What SNS is commonly used for
SNS is used for notifications and alerting — sending a message to a person or system when something happens — and for fan-out inside event-driven architectures, where one event needs to trigger several independent, unrelated pieces of downstream processing at once. Our what-is-a-message-queue explainer covers the broader messaging landscape SNS sits within, including how pub/sub compares with queueing generally.
A common example is a single event, such as an order being placed, published once to an SNS topic and then fanned out to several subscribers simultaneously — one that sends a confirmation, one that updates inventory, one that logs the event for analytics — each acting independently on its own copy of the same message.
SNS vs SQS
SNS and SQS solve related but different problems. SNS is publish/subscribe: a message fans out to every subscriber. SQS is a queue: a message generally waits to be pulled and processed once by a consumer, or one per consumer group. Our what-is-amazon-sqs explainer covers SQS in full.
The two are frequently combined: SNS publishes an event once, and fans it out to several SQS queues, each feeding a different downstream consumer that processes its copy independently and at its own pace — combining broadcast delivery with the durability and buffering a queue provides.
When you would use SNS
SNS fits anywhere an event needs to reach multiple independent recipients at once — notifications to end users, fanning a single event out to several backend processes, or alerting operational systems when something changes. It is the wrong tool when only one consumer should ever handle a given message, which is the pattern SQS is built for instead.
Pricing model, and where SNS appears in certification study
SNS is billed on a consumption basis — pay for the messages and notifications you actually publish and deliver, with no infrastructure to provision. Exact rates change over time, so treat that as the model and check AWS’s own pricing page for current figures.
SNS appears in the AWS Developer Associate and Solutions Architect Associate exams alongside SQS, as part of designing decoupled, event-driven architectures, and conceptually in the Cloud Practitioner exam as one of AWS’s application-integration services. As with the other services covered here, this article stays introductory — designing real fan-out and notification systems is exam-depth material our /revision study library is built to cover.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.