Cloud Parts

Amazon SNS

AWS’s managed pub/sub topics, which push each message to queues, functions, webhooks, phones and inboxes.

What it is
Pub/sub
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026
Website

What it is

You publish a message to an SNS topic, and SNS pushes a copy to every subscription: SQS queues, Lambda functions, HTTPS endpoints and Amazon Data Firehose streams, or, for people, SMS, email and mobile push. Subscribers don’t poll; SNS calls them and retries failed deliveries. A filter policy on each subscription, matched against the message attributes or the JSON body, lets a subscriber receive only the messages it cares about.

Standard topics allow up to 12.5 million subscriptions each, with best-effort ordering. FIFO topics keep order within a message group and remove duplicates, but allow 100 subscriptions, and SQS is the main AWS service that can subscribe to them; in return they can archive messages and replay them. Messages are up to 256 KiB. A standard topic keeps nothing, so a new subscriber never sees earlier messages, which is why the usual pattern is SNS-to-SQS fan-out: each consumer gets its own durable queue.

Why teams pick it

  • Fan-out to millions of subscribers with push delivery and no polling
  • One service for both application messages and notifications to people (SMS, email, push)
  • Per-subscription filter policies on attributes or message body, so publishers don’t need to know who wants what
  • Nothing to run or size: up to 30,000 messages per second per account in US East (N. Virginia) by default, and more on request

Watch out for

  • Messages top out at 256 KiB, smaller than the 1 MiB that SQS and EventBridge now accept
  • Standard topics store nothing: no history and no replay
  • FIFO topics allow only 100 subscriptions and mostly deliver to SQS
  • Routing is limited to filter policies (200 per topic by default); for richer content-based routing, use EventBridge

Alternatives

What all pub/sub have in common →
Google Cloud Pub/SubGoogle CloudGoogle Cloud’s serverless messaging service: fan-out across subscriptions, work sharing within each one.

How it fits with other technologies

Fan out to an SQS queue that only wants paid orders, plus an email alert · bash

TOPIC_ARN=$(aws sns create-topic --name order-events --query TopicArn --output text)

# the queue’s access policy must allow sns.amazonaws.com to send to it
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs \
  --notification-endpoint arn:aws:sqs:us-east-1:111122223333:billing \
  --attributes '{"RawMessageDelivery": "true", "FilterPolicy": "{\"status\": [\"paid\"]}"}'
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email \
  --notification-endpoint ops@example.com

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"orderId": 42}' \
  --message-attributes '{"status": {"DataType": "String", "StringValue": "paid"}}'

See it in a real stack

No architecture uses Amazon SNS yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2010–2025

By 2010 SQS let AWS customers hand work from one component to another, but each message went to one consumer, and only when that consumer asked for it. Sending the same event to several systems, or alerting a person, meant building your own notification layer. AWS’s Adam Selipsky called that “undifferentiated heavy lifting”.

On April 7, 2010 AWS released Amazon SNS in beta. You publish once to a topic and SNS delivers a copy to every subscriber, using a “push” mechanism that, in AWS’s words, “eliminates the need to periodically check or ‘poll’ for new information and updates.” At launch it delivered over HTTP, HTTPS and email and into SQS queues, with messages of up to 8 KB. InfoQ noted that AWS had chosen its own API rather than AMQP or WS-Notification, and that SNS promised neither guaranteed delivery nor ordering.

The pairing with SQS became its main use. In 2012 AWS made it easy to subscribe a queue to a topic from the console, and SNS-to-SQS fan-out, with a durable queue behind each consumer, became a standard AWS pattern. SNS also grew towards people, with SMS in 2011 and mobile push in 2013.

Why it’s built this way

Push, not poll
SNS calls each subscriber as soon as a message arrives, so nothing has to run a polling loop, and adding a consumer doesn’t change the publisher.
Standard topics store nothing
SNS hands each message to the current subscribers and forgets it, which keeps it simple and fast. Durability is left to SQS: put a queue behind each subscriber and nothing is lost while a consumer is down.
A plain AWS web API, like SQS
Matching SQS’s HTTP API made SNS easy to call from any language and to wire into queues. The cost, as InfoQ pointed out at launch, was tying users to AWS instead of a messaging standard.
Filtering per subscription
Filter policies, added in 2017, let each subscriber say which messages it wants, so a publisher can send everything to one topic instead of keeping a topic per audience.

Timeline

  1. 2010

    Beta launch in April, delivering over HTTP, HTTPS, email and to SQS

  2. 2011

    SMS text message delivery

  3. 2013

    Mobile push notifications; messages grow to 256 KB

  4. 2017

    Subscription filter policies

  5. 2020

    FIFO topics with ordering and deduplication

  6. 2022

    Filtering on the message body, not just attributes

  7. 2025

    High-throughput mode lets FIFO topics match the throughput of standard topics

Sources8 · facts checked 5 October 2026

Improve this page on GitHub