Overview

You've just processed a payment. Now three things need to happen:

The naive approach, call each service directly from your payment service:

This works until it doesn't. Adding a fourth subscriber means changing the Payment Service. If Email Service is slow, payment processing slows. If Audit Service is down, the whole payment fails. Every subscriber is a dependency of the producer. SNS breaks this coupling:

Payment Service publishes one message to the topic and returns. SNS delivers it to all subscribers simultaneously. Adding a fourth subscriber requires no change to the Payment Service, you just add a subscription. If Email Service is slow, it doesn't affect the others. This is fan-out: one event, many independent reactions.

Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service. A producer publishes a message to a topic. SNS immediately pushes that message to all subscribers of that topic. Key properties:

A topic is the channel through which messages flow. Producers publish to a topic. Subscribers receive from a topic. A topic has an ARN: arn:aws:sns:ap-south-1:123456789:my-topic. Topics are either Standard (high throughput, best-effort ordering) or FIFO (strict ordering, exactly-once delivery, lower throughput, mirrors SQS FIFO).

Any AWS service or application that calls Publish on the topic. One publisher, or many. Publishers don't know who the subscribers are.

An endpoint registered to receive messages from a topic. Supported subscriber types:

A message is a string up to 256KB. SNS wraps it in an envelope when delivering:

The Message field is what you published. The envelope is added by SNS. Your subscriber receives the full envelope, you must parse it to get the original payload. This is a common source of confusion: SQS consumers reading from an SNS-subscribed queue receive the SNS envelope, not just the raw message.

SNS pushes messages to subscribers. The moment you call Publish, SNS attempts delivery to every subscriber concurrently. Subscribers don't check in periodically. SNS comes to them.

For HTTP/HTTPS subscribers, SNS retries failed deliveries with exponential backoff. By default: 3 immediate retries, then 20 retries with delay up to 20 minutes, totalling 23 delivery attempts before giving up. For SQS and Lambda subscribers, the retry semantics are handled by those services (SQS visibility timeout, Lambda retry policy).

SNS does not store messages. If all retries to a subscriber fail, the message is lost from SNS's perspective. This is why SNS → SQS is the standard pattern for anything that needs durability: SQS holds the message until the consumer confirms processing.

By default, every subscriber receives every message published to the topic. Message filtering lets subscribers declare which messages they care about, using filter policies on message attributes. Example: a payment topic publishes both successful and failed payments. The fraud detection service only cares about failures. The email service cares about both but sends different emails.

SNS evaluates the filter policy before delivery. Messages that don't match are never delivered to that subscriber, they're not billed for it either. This keeps each subscriber's queue or Lambda clean, processing only the messages it cares about.

Filter policy scope: by default, filtering is on message attributes. You can also enable filtering on the message body (JSON), but this requires FilterPolicyScope: MessageBody.

This is the most important SNS pattern. Used everywhere.

Why SQS between SNS and the consumer, instead of SNS → Lambda directly?

The only reason to use SNS → Lambda directly (without SQS) is when you need the lowest possible latency and can tolerate message loss under Lambda throttling.

Message attributes are metadata attached to a message, key-value pairs with a data type. They're used for:

Message body is the actual content. SNS delivers it as a string. Structure it however you want (JSON is standard). Attributes are more efficient for filtering because SNS can evaluate them without deserialising the body.

SNS is the delivery mechanism for CloudWatch Alarms. When an alarm transitions to ALARM state, it publishes to an SNS topic. The topic delivers to email, SMS, Lambda, PagerDuty (via HTTPS), Slack (via Lambda), or any combination. This is the standard AWS alerting pattern:

You've seen this in the CloudWatch Alarms lab. The SNS topic is the fan-out layer that lets one alarm notify multiple channels simultaneously.

Use SNS when: one event needs to go to multiple systems simultaneously, and you want simplicity. The fan-out pattern.

Use SQS when: one unit of work needs to be processed exactly once by one worker. The work queue pattern.

Use EventBridge when: you need content-based routing with complex rules, or you're reacting to events from AWS services (S3 object created, EC2 state change, etc.).

For HTTP/HTTPS and email subscribers, SNS requires subscription confirmation before delivering messages. When you create the subscription, SNS sends a confirmation request to the endpoint. The endpoint must respond by visiting a confirmation URL (email) or replying with the token (HTTP). This prevents SNS from being used to spam arbitrary endpoints. If you've set up billing alerts and wondered why emails didn't arrive, it's almost always an unconfirmed subscription. SQS and Lambda subscriptions don't require confirmation. IAM policy is sufficient.

SNS is extremely cheap for the fan-out it provides. The cost is almost always dominated by the downstream services (SQS, Lambda) rather than SNS itself.