What Is Amazon SNS? Simple Notification Service Explained for Beginners

Simple explanation

Think of SNS like a public address system in a building. One person picks up the microphone (the publisher) and speaks into it. Everyone in the building with a receiver (the subscribers) hears the announcement at the same time. The speaker doesn’t hand-deliver the message to each person individually — the PA system handles broadcast.

In SNS terms: your application publishes a message to a topic. SNS fans it out to every registered subscriber immediately. The publisher fires once and moves on. SNS handles all the delivery.

Here is the key difference from a queue like SQS: SNS does not store messages. If no one is listening when the announcement happens, it is gone. That matters a lot — and it shapes every architecture decision you make with SNS.

Why this matters

Without a messaging layer, sending one event to multiple downstream systems means your application makes individual calls to each of them. If one system is slow, your application waits. If one is down, your request fails. The more services you add, the more fragile and tightly coupled the design becomes.

SNS removes that coupling. Your application publishes to a topic and stops caring about delivery. Each downstream service subscribes to that topic and processes messages on its own schedule. This is the core idea behind event-driven architecture in AWS, and SNS is often the first service you reach for when building it.

How Amazon SNS works

The flow from publish to delivery has four steps:

1. Publisher calls Publish. Your application, a Lambda function, or another AWS service calls the SNS Publish API with a message and the target topic ARN.
2. SNS receives the message. SNS briefly holds the message and identifies all active subscriptions on that topic.
3. SNS fans out in parallel. SNS delivers the message to each subscriber simultaneously using that subscriber’s configured protocol: SQS, Lambda, email, and so on.
4. Subscribers process independently. Each subscriber gets its own copy. If one subscriber is slow or fails, it does not affect the others.

A practical example: an order service publishes an “order placed” event to an SNS topic. The inventory service (subscribed via an SQS queue), the confirmation email service (subscribed via Lambda), and the analytics pipeline (subscribed via a second SQS queue) all receive the same message and process it in parallel. None of them know the others exist.

For a deeper look at message structure and delivery mechanics, see the SNS messaging model guide.

Core concepts

• Topic: a named broadcast channel. Publishers send to a topic; subscribers listen on it. Topics are identified by an ARN (Amazon Resource Name) that you use in API calls.
• Publisher: any code or service that calls Publish on a topic. This can be your application, a Lambda function, an S3 event trigger, or the AWS CLI.
• Subscriber: an endpoint registered on a topic. SNS pushes every published message to every active subscriber. A single topic can have up to 12.5 million subscriptions.
• Subscription: the record that links a topic to a specific endpoint, including the delivery protocol and any filter policy applied to that subscriber.
• Message attributes: optional key-value metadata you attach to a message at publish time, used for filtering and routing without modifying the message body itself.

Supported subscription protocols

Each subscriber on a topic can use a different protocol. One published message can reach all of them in the same delivery pass.

A single topic can have subscribers on all these protocols at once. One “order placed” message could enqueue in SQS, trigger a Lambda, and send an email alert all in the same delivery pass.

Common use cases

• Application alerts. CloudWatch detects a CPU spike and publishes an alarm to an SNS topic. The ops team gets an email; a Lambda logs it to a ticketing system. CloudWatch alarms integrate with SNS out of the box.
• Fan-out to multiple workers. An S3 upload event publishes to SNS. A thumbnail-generation queue, a virus-scan queue, and a metadata-extraction queue each subscribe via SQS. Each worker processes its own copy independently.
• Order event pipeline. An e-commerce platform publishes one “order placed” event. Inventory, billing, email confirmation, and analytics services all receive it with no coordination between them.
• Mobile push notifications. SNS integrates with APNs and FCM natively. Publish to a platform application endpoint and SNS handles delivery to iOS or Android devices without you managing the platform SDKs.
• Webhook delivery. Use HTTP/HTTPS subscribers to deliver webhooks to partner systems. Add a filter policy so each partner only receives the event types they registered for.
• Cross-account event distribution. An SNS topic in one AWS account can deliver to SQS queues in other accounts, making SNS a practical way to distribute events across teams or microservices in separate accounts.

For architecture patterns that combine SNS with other services, see event-driven systems in AWS.

Message filtering

By default, every subscriber on a topic receives every message. Message filtering lets you attach a subscription filter policy so a subscriber only receives messages that match specific criteria, reducing unnecessary processing in downstream services.

Think of it like inbox rules in an email client. You set up conditions once, and only the messages that match actually land in your inbox. Everything else is skipped before delivery even starts.

Filter policies can match on message attributes (key-value metadata attached to the message at publish time) or on the message body itself, depending on the filter scope you configure on the subscription. Attribute filtering is simpler and more common. Body-based filtering gives you more flexibility when routing decisions depend on the JSON payload directly.

For example, if you publish order events for different regions, your EU processor subscribes with a filter that only delivers messages where region = “EU”:

{
  "region": ["EU"],
  "orderType": ["standard", "express"]
}

Standard vs FIFO topics

Standard topics are like shouting across a busy room: messages get there quickly, and everyone hears them, but the exact order is not guaranteed and occasionally someone hears the same thing twice. FIFO topics are like a numbered ticket system at a deli counter: strict order, one at a time, no repeats.

When to use Amazon SNS

• You need to deliver one event to multiple independent consumers simultaneously.
• Delivery should be immediate and your consumers can be online to receive it.
• You are building alerts, notifications, or mobile push campaigns.
• You want to decouple a producer from downstream services so they evolve independently.
• You need cross-account or cross-service event broadcasting.
• You want fan-out with durability: SNS delivers to multiple SQS queues, each consumed independently. See the SNS push vs SQS pull guide for how to combine both patterns.

When not to use Amazon SNS

• Single consumer. If only one service consumes the message, SQS alone is simpler and more direct. SNS earns its place when there are multiple subscribers.
• Consumer needs to pull at its own pace. SNS pushes immediately. If your consumer processes more slowly than messages arrive and needs a buffer, use SQS — optionally with SNS feeding it.
• Rich content-based routing is the primary requirement. If you need to route events by schema, match complex patterns, or react to events emitted by AWS services automatically, Amazon EventBridge is a better fit.
• Multi-step workflow orchestration. If you need retries, timeouts, branching logic, and state across multiple steps, use AWS Step Functions instead.
• Long message retention is required. SNS does not persist messages. If a subscriber is unavailable when a message is published, it misses it. Use SQS (retention up to 14 days) or Kinesis if durability and replayability matter.

SNS vs SQS

SNS and SQS are often confused because both involve messages moving between services. The difference comes down to one question: do you need to broadcast to many consumers, or buffer for one?

See the full SNS vs SQS comparison for detailed decision criteria, but here is the short version:

The most reliable production pattern is SNS and SQS together: SNS fans out to multiple SQS queues, and each worker consumes from its own queue. You get broadcast delivery from SNS and durable buffering from SQS with no message loss if a consumer is temporarily down.

SNS vs EventBridge

Amazon EventBridge is a serverless event bus. Both SNS and EventBridge push events to targets, but they solve different problems at different layers.

Use SNS when you need high throughput, straightforward fan-out, or direct notification delivery (email, SMS, mobile push). Use EventBridge when you need content-based routing, want to react to events from AWS services like EC2 state changes, or are connecting to SaaS platforms.

In many production architectures the two work together: EventBridge routes and filters events, then delivers matching events to SNS topics for fan-out to multiple consumers.

Reliability, retries, DLQs, and monitoring

SNS is not guaranteed delivery by default. You need to configure it correctly for critical pipelines.

Retries. For HTTP/HTTPS and Lambda subscribers, SNS retries failed deliveries using an exponential backoff policy. The number of attempts and the retry window are controlled by the delivery policy on the subscription. After all retries are exhausted, SNS discards the message unless a dead-letter queue is configured.

Dead-letter queues. A DLQ is an SQS queue you attach to a subscription. When SNS gives up retrying, it sends the failed message to the DLQ instead of dropping it. You can then inspect the message, diagnose the failure, and replay it once the issue is resolved. The SNS message delivery failures guide walks through diagnosing delivery problems in detail.

SQS subscribers are inherently more resilient. When SNS delivers to SQS, the message enters the queue and stays there until your consumer retrieves it. The SQS queue’s visibility timeout and redrive policy manage retry behavior independently of SNS. This is the main reason the SNS + SQS fan-out pattern is preferred for critical pipelines.

CloudWatch monitoring. SNS publishes metrics to CloudWatch automatically. Watch NumberOfMessagesPublished, NumberOfNotificationsDelivered, and NumberOfNotificationsFailed. Set a CloudWatch alarm on NumberOfNotificationsFailed so you are alerted when delivery problems start. Those alarms can themselves publish to an SNS topic, which closes the loop neatly.

Creating a topic and publishing a message

A quick walkthrough with the AWS CLI: create a topic, add two subscriber types, and publish a test message.

# Create a standard topic
aws sns create-topic --name order-events
# Returns: { "TopicArn": "arn:aws:sns:us-east-1:123456789012:order-events" }

# Subscribe an SQS queue
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:order-events \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:us-east-1:123456789012:order-processing

# Subscribe an email address (requires confirmation click before delivery starts)
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:order-events \
  --protocol email \
  --notification-endpoint alerts@example.com

# Publish a message — both subscribers receive it immediately
aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:order-events \
  --message '{"orderId": "abc-123", "amount": 49.99}' \
  --subject "New Order"

After subscribing the email address, AWS sends a confirmation link. Until the recipient clicks it, SNS does not deliver messages to that address. This is a common source of confusion when notifications appear to “not work.”