Simple Notification Service (SNS)

It’s a region resilient, highly available and scalable managed service that provides message delivery from producers (publishers) to consumers (subscribers). Messages are sent by publishers in topics, and subsriptions are used by subscribers to receive messages from them, either all messages can be received or a subset resulting from applying a filter policy. All the subscribers receive all messages if they’re not applying filters; this allows to implement a Fanout pattern if several SQS Queues are present as subscribers (The SNS topic MUST have a policy allowing SQS to read.

SNS has a true One-to-many architecture.

It supports a Delivery Status with some backends (HTTP(S), Lambda, SQS.

It also supports Delivery Retries for reliable delivery.

Since it’s hosted in the AWS Public Zone it’s available from outside AWS but services in a VPC need to either have internet access or be able to reach a VPC Endpoint for SNS.

It provides Server Side Encryption (SSE) or SSE-KMS.

Messages

The maximum size of a message is 256 KB, for larget payloads you need to use the Amazon SNS Extended Client Library which uses S3 to store payloads up to 2 GB.

Attributes

Each message can have attributes, each with the following properties:

  • Name

  • Type: String | String.Array | Number

  • Value

When Raw Message Delivery is enabled, messages with more than 10 attributes are discarded as client-side errors.

They’re useful to help subscribers decide what to do with the payload without haveing to read it.

Publishers (Event sources)

There are A LOT!

Subscribers (Event destinations)

  • Application-to-application (A2A): subscribers are non-human entities.

    • Amazon Data Firehose delivery streams

    • Lambda Functions

    • SQS queues

    • HTTP(S) endpoints

    • AWS Event Fork Pipelines

  • Application-to-person (A2P): notifications are sent to human-managed devices

    • SMS

    • Push notifications

    • E-mail

Message Filtering

This happens through a JSON policy that defines keys and values. Only messages that match get to the subscriber.

Topics

Available topic types are Standard and FIFO.

Apart from IAM policies, Topic policies are resource-based policies that regulate access to the topic (be sure to include publishers and subscribers) and can also grant cross-account access.

FIFO Topics

These provide the FIFO ordering to messages. They can only have SQS as a subscriber. Their name MUST contain the .fifo suffix.

They allow for message filtering.

This can be achieved using SQS Queues as a subscriber (same SQS Throughput) to access more specific features:

  • FIFO and SQS FIFO Queues guarantee strict message ordering and enable message deduplication: message are sent to SQSin the exact order they’re published and only once.

  • FIFO and SQS Standard Queues provide a best effort ordering and at-least-once delivery.

To provide ordering SNS uses a sequence number (128-bits) which increases for each Message Group. The number is passed to SQS as part of the message body. Metadata and sequence number are not compatible with raw message delivery.

They provide message deduplication.

Message Grouping

When you publish messages to an Amazon SNS FIFO topic, you set the message group ID. The group ID is a mandatory token that specifies that a message belongs to a specific message group.

Each individual message group can deliver a maximum of 300 messages per second. Therefore, to achieve high throughput for a single topic, use a large number of distinct message group IDs.

Message Deduplication

It provides exactly-once QoS (which becomes at-most-once if some filtering is in place)

When you publish a message to an Amazon SNS FIFO topic, the message must include a deduplication ID; any message published with the same deduplication ID, within the five-minute deduplication interval, is accepted but not delivered. The Amazon SNS FIFO topic continues to track the message deduplication ID, even after the message is delivered to subscribed endpoints.

Archiving and Replaying

  • SNS Standard topics support archiving in Amazon Data Firehose.

  • SNS FIFO topics support an in-place, no-code, message archive that lets topic owners store (or archive) messages published to a topic for up to 365 days. For topics with an active ArchivePolicy, subscribers can then create a ReplayPolicy to retrieve (or replay) the archived messages back to a subscribed endpoint.

Dead-Letter Queues

A dead-letter queue is attached to an Amazon SNS subscription (rather than a topic) because message deliveries happen at the subscription level. This lets you identify the original target endpoint for each message more easily.

A dead-letter queue associated with an Amazon SNS subscription is an ordinary Amazon SQS queue.

Use Cases

  • Fanout pattern: Multiple SQS Queues subscribe to a topic.

  • a message published to an SNS topic is replicated and pushed to multiple endpoints (Firehose delivery streams, Amazon SQS queues, HTTP(S) endpoints, and Lambda functions) allowing for parallel asynchronous processing. You can use this pattern to replicate production data to test environments.

  • Alerting

  • User notifications (E-mail, push, SMS)

  • S3 Events need to be catched by multiple SQS Queues.

  • SNS Topic ⇒ Kinesis Data Firehose ⇒ S3 or any KDF supported destination.

  • You have a frontend that uploads video files in a bucket and then publishes the object URL to a SNS topic. 3 SQS queues are set as subscribers to that topic in a Fanout architecture, specifically each SQS queue will be dedicated to a specific transcoding resolution (say 480p, 720p, 1080p). Message are safely stored in SQS until a pool of workers, one per resolution, picks the message, download the video from S3 and transcodes it to its set resolution. It then uploads the video to a bucket dedicated to transcoded videos, maybe one bucket for each transcoding resolution.