Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

SNS (Event broadcaster)

Amazon SNS (Simple Notification Service) is a managed publish/subscribe service. Publishers send messages to a topic; SNS pushes each message to every subscribed endpoint. Publishers know nothing about subscribers, and subscribers can be added or removed without touching the publisher.

Key features

Section titled “Key features”
  • Message size. Up to 256 KiB of text in any format. Larger payloads use the Amazon SNS Extended Client Libraries, which store the body in S3 and publish a pointer, up to 2 GB.
  • Encryption. In transit by default; at rest with a KMS key, which is optional and off unless enabled.
  • Access control. IAM policies for principals in the account, and topic access policies for cross-account publish and subscribe.

Subscribers

Section titled “Subscribers”

A single topic can deliver to a mixture of endpoint types:

  • Application integration — Amazon SQS queues, AWS Lambda functions, Amazon Data Firehose delivery streams
  • Direct messaging — HTTP/HTTPS endpoints, email, SMS, mobile push notifications and platform application endpoints

An HTTPS endpoint must confirm its subscription by returning the token SNS sends it before any message is delivered; the same handshake applies to email.

Message filtering

Section titled “Message filtering”

A subscription filter policy decides which messages that subscription receives, so consumers are not woken by traffic they will only discard. The FilterPolicyScope attribute controls what the policy matches against:

  • MessageAttributes (the default) — filter on the attributes attached to the message
  • MessageBody — filter on the JSON body of the message itself

There is a quota of 200 filter policies per topic and 10,000 per account.

Reliability

Section titled “Reliability”
  • Dead-letter queues capture messages that could not be delivered to a subscription
  • Custom retry policies are supported for HTTP/HTTPS endpoints
  • Messages are stored redundantly across multiple Availability Zones

Standard and FIFO topics

Section titled “Standard and FIFO topics”

Standard topics give best-effort ordering and at-least-once delivery, and scale to very large subscriber counts.

FIFO topics give strict ordering and deduplication within a five-minute window, at the cost of a narrower set of subscribers:

  • Subscribers must be SQS queues — FIFO queues to preserve ordering and deduplication end to end, or standard queues where best-effort ordering downstream is acceptable and the lower cost matters. Delivery to standard queues has been supported since 2023.
  • Email, SMS, mobile push and HTTP(S) endpoints cannot subscribe to a FIFO topic at all; attempts to subscribe them fail. Lambda is reached indirectly, by subscribing a queue and triggering the function from it.
  • FIFO topics also support archiving and replay through an archive policy and a replay policy — a capability standard topics do not have.

Fan-out

Section titled “Fan-out”

The fan-out pattern pushes one message to several subscribing endpoints at once, so that independent processes react to the same event in parallel with no coupling between them. It is covered in detail in SNS and fan-out architecture. Common uses are application alerts, monitoring, parallel workflow steps and cross-account or cross-Region delivery.

Four SNS patterns. First, a web application publishes to a topic whose two SQS subscriptions each carry a filtering policy on orderStatus. Second, the same publisher fans out to two queues, one feeding order processing and one order fulfilment. Third, an S3 event notification is the publisher instead of the application, with the same two queues. Fourth, the topic delivers to a Firehose stream that writes to an S3 bucket and a search service.
Four ways an SNS topic is wired: filtered subscriptions, fan-out to queues with separate workers, an S3 event as the publisher, and delivery to Firehose. The service labelled Kinesis Data Firehose is now Amazon Data Firehose.

How subscriptions are created

Section titled “How subscriptions are created”

The topic owner creates the subscription. Through the console, CLI or an SDK, the owner names the endpoint — an SQS queue, a Lambda function, an HTTP(S) endpoint, an email address. For endpoints that can refuse, SNS sends a confirmation message that the endpoint must acknowledge.

The subscriber requests the subscription. Used mainly across accounts: the subscriber calls Subscribe against the topic, which requires the topic’s access policy to permit it. Confirmation still applies.

Quotas worth knowing

Section titled “Quotas worth knowing”
  • 100,000 standard topics and 1,000 FIFO topics per account
  • 12,500,000 subscriptions per standard topic; 100 per FIFO topic
  • Firehose delivery streams are limited to 5 subscriptions per topic per subscription owner
  • Publishing is throttled per account per Region across all topics: 30,000 messages per second in US East (N. Virginia), 9,000 in US West (Oregon) and Europe (Ireland), 1,500 in a named set of Regions and 300 in the rest, all adjustable through Service Quotas

Practices worth adopting

Section titled “Practices worth adopting”
  • Use filter policies rather than filtering in the consumer
  • Subscribe SQS queues rather than consumers directly, so a slow or failing consumer cannot lose messages
  • Configure a dead-letter queue on every subscription that carries work
  • Watch NumberOfNotificationsFailed and the delivery-status logs in CloudWatch
  • Reach for FIFO topics only when ordering or deduplication is genuinely required — they cost throughput and rule out most endpoint types