AWS SNS — Introduction

7 min readNov 10, 2024

Basics of SNS before we start to use

SNS is a serverless managed publish/subscribe service that can distribute a massive number of messages to different recipients. SNS provides an HTTP API over which messages can be published to an SNS topic. Among the subscriber types, SNS supports are AWS Lambda functions, SQS queues, HTTP(S) endpoints using webhooks, email, and SMS.

Every SNS topic has a set of subscriptions. Once a message is published to a topic, SNS handles distributing the message to all its subscribers. To publish a message to an SNS topic, a message producer must use the SNS HTTP API. Once the message is published, all subscribers receive a copy of the message over the channel through which they established their subscription.

SNS Topic type

SNS Subscribers

SNS uses application-to-application (A2A) messaging to separate publishers from subscribers. Messages are sent to SNS topics, where they can be filtered and delivered to subscribers like Lambda, Amazon SQS, or HTTP endpoints.

Amazon SNS application-to-person (A2P) messaging lets us to deliver notifications and alerts directly to our customers’ mobile devices through SMS (Short Message Service). Using this feature, we can send push notifications to mobile apps, text messages to mobile phone numbers, and plain-text emails to email addresses.

SNS Delivery Retries

All messages sent to SNS are processed and delivered immediately. If a message cannot be successfully delivered on the first attempt, SNS implements a 4-phase retry policy:

1) retries with no delay in between attempts

2) retries with some minimum delay between attempts

3) retries with some back-off model (linear or exponential)

4) retries with some maximum delay between attempts

SNS messages can contain up to 256 KB of text data.

The invocation of Lambda functions by SNS actually occurs in an “Asynchronous” manner. When SNS publishes a message to a Lambda function, the message is placed into what is known as the “Event Queue,” an internal component within the Lambda architecture. The 200 status code returned by the Publish API simply indicates that the message has been successfully placed in this queue, not that the Lambda function has completed execution.

Once the message is in the Event Queue, Lambda begins processing the invocation Asynchronously. If the Lambda function fails to execute successfully, the retry policy configured in SNS does not apply. Instead, Lambda employs its own retry mechanism, which attempts to execute the function up to three times with an exponential backoff.

When server-side errors occur, Amazon SNS retries the failed deliveries using either a linear or exponential backoff function. For server-side errors caused by AWS managed endpoints backed by Amazon SQS or AWS Lambda, Amazon SNS retries delivery up to 100,015 times, over 23 days.

While HTTP endpoints support customer-defined retry policies, Amazon SNS sets an internal delivery retry policy to 50 times over 6 hours, for SMTP, SMS, and mobile push endpoints.

Message Delivery Policies:

SNS provides flexible message delivery policies that allow us to control the retry behavior and delivery delay for messages.
We can configure policies to specify the maximum number of delivery attempts, the retry interval, and the delay before delivering the message to subscribers.
This allows us to optimize the delivery behavior and ensure that messages are delivered reliably and according to your desired timing requirements.

SNS DLQ

Amazon 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.

Message Attributes

SNS allows us to attach custom attributes to messages, providing additional metadata or context to the messages.
Message attributes can be used for filtering, routing, or processing messages based on specific criteria.
Attributes can be added when publishing messages to SNS topics and accessed by subscribers to perform customized actions based on the attributes.

Message Filtering

By default, Amazon SNS topic subscribers receive every message that’s published to the topic. To receive only a subset of the messages, a subscriber must assign a filter policy to the topic subscription.

A filter policy is a JSON object containing properties that define which messages the subscriber receives. Amazon SNS supports policies that can act on the message attributes or on the message body, according to the filter policy scope that you set for the subscription. Filter policies for the message body assume that the message payload is a well-formed JSON object.

The AWS SNS offers two types of message filter strategies:-

Attribute-based message filtering
Payload(or Message body)-based message filtering

Attribute-based message filtering is the most basic version of the message-filtering strategy that AWS SNS offers and is completely free. Here a message is filtered using the message attribute itself that we need to configure in the SNS Topic subscription.

Payload (or Message body)-based message filtering grants subscribers the ability to articulate their subscription filter policies based on the message contents.

Here’s the basic structure of an AWS SNS filter policy:

json {   "attribute_name": ["value1", "value2"],   "numeric_attribute": [{"numeric": [">", 10]}, {"numeric": ["<=", 100]}] }

In the above example:

"attribute_name": The filter policy checks if the attribute_name attribute has either value1 or value2.
"numeric_attribute": This filter policy specifies that the numeric_attribute should be numeric and have a value greater than 10 and less than or equal to 100.

Unlike, the attribute-based filter policy, the payload-based filter policy is not free and costs about $0.09 per GB of scanned payload data.

SNS Billing

SNS is a serverless managed publish/subscribe service, which means it comes with pay-as-you-go billing. You pay about 50 cents per 1 million messages. If your messages are bigger than 64 KB, you have to pay for each additional 64 KB chunk as if it was a whole message. So a “publish” action with a 256KB payload will be charged as four requests.

AWS also offers the first 1 million requests each month for free; this includes 100000 deliveries via HTTP subscription.

Be mindful of the maximum message size limit imposed by SNS (256 KB for most transport protocols).

SNS Access Policies

SNS also provides access policies that allow you to control access at the topic level. Access policies are similar to IAM policies but are specific to SNS topics. Access policies are written in JSON format and define who has access to perform certain actions on the topic.

{
  "Statement": [{
    "Sid": "grant-1234-publish",
    "Effect": "Allow",
    "Principal": {
      "AWS": "111122223333"
    },
    "Action": ["sns:Publish"],
    "Resource": "arn:aws:sns:eu-west-1:444455556666:MyTopic"
     "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:cloudwatch:*:111122223333:alarm:*"
        }
      }
  }]
}

Fanout and Message Distribution

SNS provides fanout capabilities, allowing us to distribute messages to multiple subscribers simultaneously.
When a message is published to an SNS topic, it can be automatically sent to all subscribed endpoints, such as email addresses, SMS numbers, or HTTP/HTTPS endpoints.
This simplifies the process of broadcasting messages to multiple recipients and ensures efficient message distribution across different channels.

We can create an ‘SNS Topic’ + multiple ‘SQS Queues’ and subscribe these multiple queues to the same topic to replicate a message over multiple queues. This scenario will replicate a message to all queues, and this allows for parallel asynchronous processing.

SNS Monitoring

AWS exposes many metrics to monitor the SNS:

NumberOfMessagesPublished
NumberOfNotificationsDelivered
NumberOfNotificationsFailed
NumberOfNotificationsFilteredOut
NumberOfNotificationsRedrivenToDlq
NumberOfNotificationsFailedToRedriveToDlq
SMSSuccessRate

SNS Best practices

Ensure topics aren’t publicly accessible

Unless we explicitly require anyone on the internet to be able to read from or write to our Amazon SNS topic, we should ensure that our topic isn’t publicly accessible (accessible by everyone in the world or by any authenticated AWS user).

Avoid creating policies with Principal set to “”.
Avoid using a wildcard (*). Instead, name a specific user or users.

Consider using VPC endpoints to access Amazon SNS

If we have topics that we must be able to interact with, but these topics must not be exposed to the internet, we need to use VPC endpoints to limit topic access to only the hosts within a particular VPC. We can use topic policies to control access to topics from specific VPC endpoints or only from specific VPCs.

Amazon SNS VPC endpoints provide two ways to control access to our messages:

We can control the requests, users, or groups that are allowed through a specific VPC endpoint.
We can control which VPCs or VPC endpoints have access to your topic using a topic policy.

AWS SNS Appropriate Subscribers

SNS Topics Should Not Allow Global Subscribe
SNS Topics Should Be Encrypted
AWS SNS Subscription Should Not Use HTTP As Delivery Protocol

SNS Cross Account Access

Ensure Amazon SNS topics don’t allow unknown cross-account access.

SNS Topic Accessible For Publishing

Ensure SNS topics don’t allow ‘Everyone’ to publish.
SNS Topics Should Not Allow Global Publishing

SNS Topic Encrypted

Enable Server-Side Encryption for AWS SNS Topics.
SNS Topic Encrypted With KMS Customer Master Keys

AWS SNS Threat scenarios

unauthorized access to your SNS topic or subscription
use of SNS for spamming or phishing
use of SNS for denial of service (DoS) attacks

Others

Tag you SNS topic
use write sns topic names
Monitor SNS topic metrics
Monitor SNS api calls using cloudtrail for any suspicious delete or create api calls.