Amazon SNS

What it is

Amazon Simple Notification Service (Amazon SNS) is a fully managed Publish/subscribeA messaging pattern in which senders publish messages to a topic without knowing who receives them, and every subscriber to the topic gets a copy. Amazon SNS works this way.Glossary entry service. A publisher sends a message to a topic, and SNS pushes a copy to every subscriber of that topic. The publisher does not know or care who the subscribers are, so you can add a new consumer without changing the publisher.

SNS covers two kinds of messaging:

Application-to-application (A2A): delivery to Amazon SQS queues, AWS Lambda functions, HTTP (Hypertext Transfer Protocol)The protocol that web browsers and APIs use to send requests, such as GET and POST, and receive responses. On its own it is not encrypted; HTTPS adds TLS.Glossary entry or HTTPS (HTTP Secure)HTTP sent over a TLS-encrypted connection, so that requests and responses cannot be read or changed on the way, and the server proves its identity with a certificate.Glossary entry endpoints, Amazon Data Firehose streams, and some SaaS partners.
Application-to-person (A2P): email, text messages (SMS), and mobile push notifications.

The key difference from SQS: SQS holds messages until a consumer pulls them, while SNS pushes each message to all subscribers as soon as it is published and does not keep it for later readers.

Core concepts

Topic: the channel publishers send to. A standard topic can have up to 12.5 million subscriptions.
Subscription: an endpoint and its protocol. Email and HTTPS subscriptions must be confirmed before they receive messages.
Message size: up to 256 KiB by default, and up to 1 MiB if you raise the topic's MaximumMessageSize. Larger payloads go through the Extended Client Library, which stores them in Amazon S3.
Raw message delivery: for SQS, HTTPS, and Firehose subscribers, SNS sends the message body as is, instead of wrapping it in a JSON (JavaScript Object Notation)A text format for structured data made of name-and-value pairs and lists, such as {"bucket": "logs"}. IAM policies, most AWS API responses, and many CloudFormation templates are written in JSON.Glossary entry envelope with SNS metadata.

Fanout

The classic SNS pattern is Fan-outSending one message or event to many receivers at once so that each can process it in parallel, such as an Amazon SNS topic delivering to several SQS queues.Glossary entry: publish once to a topic that has several SQS queues subscribed, and each queue gets its own copy. Each consuming application then works through its queue at its own pace, retries independently, and survives outages, because the queue holds the messages. For example, an order service publishes "order placed", and separate queues feed fulfillment, billing, and analytics.

Fanout is also how one Amazon S3 event reaches several consumers: S3 rejects notification configurations that overlap on the same event type and key prefix or suffix, so it cannot send the same event directly to several queues. Send the event to one SNS topic and subscribe the queues to it.

For the queues to receive messages, each queue's access policy must allow the topic to send to it (sqs:SendMessage with the topic's ARN (Amazon Resource Name)The unique identifier of an AWS resource, in the form arn:partition:service:region:account-id:resource. IAM policies use ARNs to name the resources they allow or deny.Glossary entry as aws:SourceArn).

Message filtering

By default, every subscriber receives every message. A filter policy on a subscription delivers only the messages it matches, based on the message attributes or on the message body (the filter policy scope). Filtering moves the routing logic out of the consumers: for example, the "refunds" queue subscribes with a filter policy that matches only "type": ["refund"].

FIFO topics

A FIFO (First in, first out)Processing items in the order they arrived. Amazon SQS FIFO queues keep messages in order within a message group and remove duplicates.Glossary entry topic (name ending in .fifo) keeps messages in order within each message group and removes duplicates. FIFO topics deliver only to SQS queues, FIFO or standard. They cannot deliver to email, SMS, mobile push, HTTP endpoints, or directly to Lambda; to reach a Lambda function, subscribe a queue and let the queue invoke the function. They are also the only topic type with message archiving and replay: the topic keeps messages for 1 to 365 days, and a subscriber can replay them.

Security, resilience, performance, and cost

Security

IAM policies control who can publish and subscribe. A topic access policy (resource-based) grants other accounts or AWS services permission, for example letting Amazon S3 event notifications or CloudWatch alarms publish to the topic.
Encryption at restEncrypting data where it is stored, such as on disks, in databases, or in backups, so that it cannot be read without the key. On AWS it usually uses keys in AWS KMS.Glossary entry: SSE (Server-side encryption)Encryption that a service applies when it stores your data and removes when you read it back. Amazon S3 encrypts every new object with SSE-S3 by default; SSE-KMS uses keys in AWS KMS instead.Glossary entry with an AWS KMS key encrypts message bodies, not metadata such as the subject and attributes. Encrypted topics require HTTPS requests. Publishers need kms:GenerateDataKey* and kms:Decrypt on the key.
When an AWS service such as CloudWatch or Amazon S3 publishes to an encrypted topic, use a Customer managed keyA KMS key that you create, own, and manage: you control its key policy, rotation, and deletion. AWS managed keys, in contrast, are created and managed for you by an AWS service.Glossary entry and grant that service's PrincipalA person or workload that can make requests to AWS, such as an IAM user, a role session, the root user, a federated user, or an AWS service. Resource-based policies name the principals they allow.Glossary entry access in the key policy.
Private access: an interface VPC endpointA private connection from a VPC to an AWS service or another endpoint service without crossing the internet. Gateway endpoints, for Amazon S3 and DynamoDB, are route table targets; interface endpoints are network interfaces that use AWS PrivateLink.Glossary entry (AWS PrivateLink) lets resources in a VPC publish without crossing the internet or needing a NAT gatewayA managed VPC component that lets instances in private subnets start connections to the internet or other networks, while blocking connections started from outside. It is billed per hour and per gigabyte processed.Glossary entry. SNS has no gateway endpoint; gateway endpoints exist only for Amazon S3 and DynamoDB.

Resilience

SNS stores multiple copies of each published message across multiple AZ (Availability Zone)An isolated location within an AWS Region, made up of one or more data centers with their own power, cooling, and networking. The AZs in a Region are linked by fast, low-latency connections, so spreading resources across them protects against the failure of one site.Glossary entry before acknowledging it.
Delivery retries depend on the endpoint. For SQS and Lambda, SNS retries up to 100,015 times over 23 days. For email, SMS, and mobile push, it retries 50 times over 6 hours. You can customize the retry policy only for HTTP and HTTPS endpoints, for example with longer delays between retries, and its total retry time cannot exceed 3,600 seconds (1 hour, a hard limit). For endpoint outages longer than that, attach a DLQ (Dead-letter queue)A queue that receives messages that could not be processed after a set number of attempts, so they stop blocking other messages and can be inspected later. Amazon SQS, Amazon SNS, AWS Lambda, and Amazon EventBridge can send failed messages to one.Glossary entry, or put an SQS queue in front of the consumer.
If retries run out, or the endpoint returns a client error (for example, a deleted Lambda function), SNS discards the message unless the subscription has a dead-letter queue: an SQS queue in the same account and AWS RegionA separate geographic area where AWS runs its services, such as us-east-1 in Northern Virginia, made up of several Availability Zones. Most resources live in one Region; you choose Regions for latency, data residency, and the services you need.Glossary entry.
For guaranteed processing, the usual pattern is SNS to SQS fanout: the queue keeps the message until the consumer succeeds.

Performance

Publish throughput is a per-account, per-Region quota that you can raise; PublishBatch sends up to 10 messages per call.
FIFO topics allow up to 300 messages per second per message group, and 3,000 per second per topic by default.
Standard topics give At-least-once deliveryEvery message is delivered, but occasionally more than once. Amazon SQS standard queues work this way, so consumers should be idempotent.Glossary entry and best-effort order, so consumers should be IdempotencyAn operation is idempotent when repeating it has the same effect as doing it once, such as setting a value rather than adding to it. It makes retries safe; many AWS APIs accept a client token for this.Glossary entry.

Cost

Standard topics: you pay per publish request and per delivery, with each 64 KB chunk counting as one. Deliveries to SQS and Lambda carry no delivery charge, though data transfer is charged. Email, HTTPS, mobile push, and SMS each have their own rates, and SMS is priced by destination country.
FIFO topics: priced per published message, per subscription delivery, and per GB of payload.
Filtering on message attributes is free; filtering on the message body is charged for the payload scanned. Archiving and replay, and KMS calls, cost extra.

Monitoring

Amazon CloudWatch receives topic metrics every minute at no charge, including NumberOfMessagesPublished, NumberOfNotificationsDelivered, NumberOfNotificationsFailed, NumberOfNotificationsFilteredOut, and NumberOfNotificationsRedrivenToDlq. Alarm on failed notifications.
Delivery status logging writes the success or failure of each delivery to CloudWatch Logs.
AWS CloudTrail records SNS API (Application programming interface)A defined way for one program to ask another for data or actions, such as a set of HTTPS requests and responses. Every AWS service is controlled through its API, which the console, the CLI, and the SDKs call for you.Glossary entry calls.

	Amazon SNS	Amazon SQS	Amazon EventBridge (bus with rules)
Model	Push to every subscriber	Consumers pull	Rules route events to targets
Keeps messages	No (FIFO topics can archive)	Yes, up to 14 days	No (archives are optional)
Routing	Filter policies per subscription	None	Event patterns on any field
Receivers	Queues, Lambda, HTTPS, Firehose, email, SMS, mobile push	Your consumers	Many AWS services, API destinations, other event buses
Typical use	Fanout, alerts, notifications to people	Buffering and DecouplingDesigning components so that they do not depend directly on each other being available, for example by passing work through a queue. A slow or failed component then does not stop the others, and each can scale on its own.Glossary entry	Reacting to AWS, SaaS, and application events

Reverse mindmap: when the question points here

Is it Amazon SNS?

Yes, when the question says
- One event must reach several services at once leads to SNS fanout to SQS queues
- Notify operators by email or SMS leads to SNS topic
- Push notifications to mobile apps leads to SNS mobile push
- Alarm or S3 event must alert a team leads to SNS topic as the target
- One S3 event must reach several queues leads to S3 notification to SNS, fanout to SQS
Tune the delivery
- Each subscriber gets only some message types leads to Subscription filter policy
- Ordered, deduplicated fanout to queues leads to FIFO topic with SQS FIFO queues
- Keep messages that could not be delivered leads to Dead-letter queue on the subscription
- Webhook needs slower retries during an outage leads to Custom HTTPS retry policy (1 hour at most) plus a DLQ
- Queue consumers should get the plain body leads to Raw message delivery
Secure it
- Encrypt messages with your own key leads to SSE with a customer managed KMS key
- S3 or CloudWatch publishes to an encrypted topic leads to Key policy for that service principal
- Another account publishes leads to Topic access policy
- Private subnets publish without NAT leads to Interface VPC endpoint
No, when the question says
- Consumers pull at their own pace leads to Amazon SQS
- Route on event content from AWS services or SaaS leads to Amazon EventBridge
- Replay a stream with several readers leads to Kinesis Data Streams

Key takeaways

SNS pushes each message to every subscriber of a topic; it does not hold messages for later.
Fanout (SNS to several SQS queues) gives each consumer its own durable copy.
Filter policies deliver only matching messages to each subscription.
FIFO topics give order and deduplication, deliver only to SQS queues, and support archive and replay.
Dead-letter queues attach to subscriptions; encryption uses KMS, and AWS service publishers need a customer managed key.

Amazon SNS

What it is

Core concepts

Fanout

Message filtering

FIFO topics

Security, resilience, performance, and cost

Security

Resilience

Performance

Cost

Monitoring

Reverse mindmap: when the question points here

Key takeaways

Sources

Check your understanding

Add LetMeMaster to your Home Screen

What it is

Core concepts

Fanout

Message filtering

FIFO topics

Security, resilience, performance, and cost

Security

Resilience

Performance

Cost

Monitoring

SNS or another service?

Reverse mindmap: when the question points here

Key takeaways

Sources

Check your understanding