INTRODUCTION👋

Amazon Simple Notification Service (SNS) is a managed, highly-scalable messaging service by AWS which revolves around topics.

Think about topics, imagine a collection of messages. A client (e.g. a user or an endpoint, like at a HTTP server) can subscribe to such a topic and every time a message is published to this topic, all clients are notified.

PUBLISH / SUBSCRIBE⚡

SNS follows the "publish-subscribe" messaging paradigm, meaning that messages are actively pushed to clients, eliminating the need to poll.

ACCESS CONTROL🔑

You can control access to topics via AWS Identity & Access Management (IAM) by creating Topic Policies.

For example:

• restrict access to specific users or accounts
• restrict subscribers to use a specific protocol like HTTP

MESSAGE ORDERING⚖️

There are a lot of use cases when it's critical to deliver messages in the order they were published.

To cover this, SNS offers FIFO (First In, First Out) topics that can be used together with SQS FIFO queues to provide strict message order and delivery.

If messages belong to the same group, it's also guaranteed that they are processed in a strict order relative to their group.

DEDUPLICATION🔁

Like a reliable message ordering, often you need to make sure messages are only delivered once to each consumer.

This can be achieved with the same setup as with reliable message ordering (SNS FIFO topic & SQS FIFO queues) and messages that contain a unique deduplication ID.

Another approach: make sure that the same message is delivered once to each of your consumers by enabling content-based deduplication.

EVENT SOURCES & DESTINATIONS⚡

Many AWS services are supported as event sources for SNS, including popular ones like Lambda, Step Functions, EC3, DynamoDB, RDS, CodeBuild, CloudFormation & CloudTrail.

Destinations are grouped into:

• application-to-application (A2A) messaging
• application-to-person (A2P) notifications

A2A destinations include Kinesis Data Firehose, Lambda, SQS, Event Fork Pipelines and HTTPs.

For A2P, you can use SMS, email, platform endpoints (e.g. to deliver events to mobile phones via push notifications), and PagerDuty.

⚠️ Careful with FIFO topics: Most AWS services only support receiving events from SNS standard topics.

DATA ENCRYPTION🔒

You can protect message data while:

• in-transit (sent from & to SNS) and
• at rest (while stored at AWS centers)

For securing your messages in transit, you should use SSL and/or client-side encryption.

By enabling Server-Side Encryption (SSE), SNS will store sensitive data in the body of a message in encrypted topics.

What's not encrypted:

• Topic metadata - topic names & attributes
• Message metadata - subject, message ID, timestamp, and attributes
• Metrics for topics

ARCHIVING📥

For archiving messages (e.g. for compliance requirements or to run analytics), you can fan out messages to Kinesis Data Firehose.

This enables you to forward notifications to storage and analytic destinations which are supported by Data Firehose like S3 or Redshift.

MESSAGE FILTERING🔍

By default, all of your topic's subscribers will receive all messages that are published.

By assigning filter policies to subscriptions, this can be reduced to a subset of messages only relevant for the specific client.

A filter policy defines matching rules that evaluate the Message Attributes to determine if a message is rejected or accepted.

MESSAGE ATTRIBUTES📝

With SNS, you can provide structured metadata which is sent together with the message body.

This can be used to provide receivers information about how to process messages, without processing the message body first. Message attributes can also be used together with filter policies to determine if messages should be delivered to a specific subscriber in the first place.

BATCH OPERATIONS🛠️

With single API requests, you are able to manage billions of objects.

A batch job will execute a specified operation on every object that's included in the job description. Running jobs can be monitored programmatically or via the AWS console.

DEAD-LETTER QUEUES💀

If messages can't be delivered to clients - for example due to deleted endpoint or misconfigured IAM policies - you don't want them to just disappear into the Nirvana.

You want to either keep them for analysis purposes or to reprocess them at a later state.

By configuring a SQS queue as your Dead-Letter Queue (DLQ), you can automatically redrive messages after the delivery policy is exhausted.

DELIVERY RETRIES🔄

For each delivery protocol, SNS defines a delivery policy. Those policies define how retries are handled if errors occur.

Delivery policies contain different phases and except for HTTP endpoints, they are not customizable.

A custom HTTP/s delivery policy enables you to define how each phase should be handled by SNS.

MONITORING📊

CloudWatch offers you a set of predefined metrics for SNS like published & delivered messages, the average payload size or messages that had been redirected to a dead letter queue.

With 3rd-Party service likes 🔍 Dashbird.io, you can also easily track metrics and get alerted if thresholds are breached. Additionally, you get well-architected hints for best practices.

PRICING💰

As with other on-demand services, there's no minimum fee. You're paying for actual usage:

• $0.50 per 1m SNS requests
• $0.06 per 100k notification deliveries via HTTP
• $2.00 per 100k deliveries over email

🎁 Free Tier: covers 1m requests, 100k notifications, 100 SMS & 1000 notifications via email each month.