3 Things: Developing with Amazon SNS


Amazon Simple Notification Service, AKA SNS, is a versatile pub/sub AWS service that supports several different endpoints including, SMS, email and HTTP/HTTPS. Amazon SNS also supports AWS services as endpoints, like Amazon SQS, AWS Lambda and AWS Kenesis Data Firehouse. Amazon Simple Notification Service, which is often leveraged to do the heavy lifting in a fan-out pattern, provides a simplified path for creating pub/sub based applications without having to set up tons of infrastructure. Even with this simplified path, there are a few things that every developer should know before they start their Amazon SNS journey.

Photo by Delaney Van on Unsplash

Protect Against Failures

As stated before, Amazon SNS supports a multitude of endpoints, but what happens if an endpoint becomes unavailable? Amazon SNS can retry sending data to the endpoint, but if the endpoint does not become available, the message will fail. Fortunately, we can easily set up a dead-letter queue in Amazon SQS. This dead letter queue will be a holding area for all messages that fail and will give us a chance to reprocess the message.

Here is an example of a command for setting an Amazon SQS queue as an Amazon SNS topic dead-letter queue.

$ aws sns set-subscription-attributes \
––subscription-arn (my-sns-subscription-arn) \
––attribute-name RedrivePolicy \
––attribute-value “{\”deadLetterTargetArn\”: \”(my-sqs-dead-letter-queue-arn)”}”

First-In-First-Out Delivery

Sometimes business requirements dictate that our solutions need to support ordered messaging. That is, if I send messages one, two and three, the order of the message delivery should be message one, then message two and finally message three.

Below is an example of creating an Amazon SNS FIFO topic using the AWS CLI. Note the name of the FIFO topic must end in, “.fifo”. For example, “my-sns-topic.fifo”.

$ aws sns create-topic \
––name “(my-fifo-topic-name)” \
––attributes ‘{“FifoTopic”: “true”, “ContentBasedDeduplication”: “true”}’

Get Only the Messages You Want

Let’s say you have a multi-tenant system and in this system you send messages out to multiple consumers and these consumers are tenant based. Meaning, each consumer only consumes messages for one tenant. We can accomplish this on the producer side by sending a message to an SNS Topic with a message attribute called, “tenant-id.” On the consumer side, we can specify a subscription filter to filter on the tenant-id that you care about.

The following is an example of publishing a message to SNS with a “tenant-id” message attribute using the .NET AWS SDK.

var snsClient = new AmazonSimpleNotificationServiceClient();
string tenantIdentifierAttributeKey = "tenant-id";
MessageAttributeValue tenantIdentifierAttributeValue = new MessageAttributeValue();
tenantIdentifierAttributeValue.StringValue = "(tenant-id-value)"
tenantIdentifierAttributeValue.DataType = "String";
PublishRequest publishRequest = new PublishRequest();
publishRequest.MessageAttributes.Add(tenantIdentifierAttributeKey, tenantIdentifierAttributeValue);
publishRequest.Message = "Test Message";
publishRequest.TopicArn = "(my-topic-arn)";
await snsClient.PublishAsync(publishRequest);
view raw Publish.cs hosted with ❤ by GitHub

Want to know more about the tech in this article?  Checkout these resources:

AWS CLI, Configuring the AWS CLI, AWS .NET SDK, .NET

%d bloggers like this: