Hi Reader ๐๐ฝ
This is another issue that is all about messaging systems and patterns. It is the last one of this series. After that, we continue with more networking services ๐ช
This time we talk about the service Simple Notification Service or better known as SNS ๐จ
To get you excited, here is one upfront guessing question: What's the subscription limit per topic? ๐ค Scroll down to find the answer.
But now let's get into the overview of this issue:
Let's get into it! ๐
Amazon SNS is a fully managed publish & subscribe service.
The fundamentals are quite simple:
Subscribers can either be personal applications like smartphone notifications, emails, or SMS. A subscriber can also be another AWS Service.
SNS publishes messages to subscribers with a push-based model. Once a message comes in, SNS pushes out the message to its subscribers immediately.
SQS on the other hand is a poll-based mode. That means a message remains in a queue and consumers poll this message.
SNS supports a lot of different destinations to which it can deliver messages. SNS distinguishes those into two endpoint groups:
SNS works exceptionally well for the use-case of sending a message to many subscribers. This pattern is called Fan-out.
This is also the major difference to SQS, as SQS only has one consumer per message (excluding the cases where reprocessing is happening due to errors).
As with other AWS services, SNS is fully integrated with IAM. This means you can control access to your topics via topic policies.
You can also encrypt your data in SNS. You need to encrypt the message in two places, in transit and at rest.
SNS handles the whole encryption process on the server side. You can either use a key of AWS's own Key Service (KMS) or provide a custom one. This will encrypt all sensitive data in your message.
In SNS you can choose two different types of topics.
Message filtering allows you to send only a subset of messages to subscribers. You can assign filter policies that check the message for certain attributes. If a message meets these policies, SNS sends it to the subscriber. This allows a flexible routing mechanism.
The filter policy can be applied both to Message Attributes and the Message Body.
In the example, we're filtering based on the message payload isBlogPost. Some of our subscribers are ignoring messages that have this field set to true, while all of them are listening to messages that have the field set to false.
For each delivery protocol, SNS defines a delivery policy. With this protocol, you can define how retries are happening. Retries will only happen on server-side errors.
Compared to SQS, SNS is not aware of errors happening inside of your Lambda function.
SNS only cares about sending out your messages. That means once your message is out it is successfully processed by SNS.
If your Lambda function fails to work on the message the delivery protocol will not be aware of that. SNS calls your Lambda function asynchronously. We highlight this because this is very often misunderstood.
A common server-side error is a missing IAM policy. If your topic isnโt allowed to call a Lambda function a server-side error will occur.
Another error would be if the Lambda API is down but this doesnโt happen very often (fortunately).
With the delivery protocol, you can then define retries.
SNS is a serverless service. You donโt have any fees if you donโt use it. The charges are completely usage-based.
Free Tier: The free tier covers 1 million requests, 100k notifications, 100 SMS, and 1000 notifications via email every month.
SNS is an amazing service to build high-throughput, customer-facing applications. The ability to use application and personal endpoints are amazing in SNS.
That's it for today. We hope you've enjoyed this issue!
See you in two weeks!
Sandro & Tobi ๐
P.S.: there can be 12,500,00 subscribers per topic! ๐ฅ
This week, we want to give a huge shout-out to Allen Helton. Watching Allen's story unfoldโfrom becoming an AWS Community Builder and AWS Hero to joining the amazing Momento teamโhas been amazing.
Allen shares a lot of content through his newsletter, blog, and podcast. He is always happy to assist you if you need help with anything cloud-related. Thanks, Allen!
Still hungry for AWS content? Have a look at our blog! ๐ โ
We teach AWS for the real world - not for certifications. Join more than 10,500 developers learning how to build real-world applications on AWS.
AWS FOR THE REAL WORLD โฑ๏ธ Reading time: 9 minutes ๐ฏ Main Learning: Build a self-service portal that grants temporary AWS + Azure access and revokes it automatically โ using Kestra and one YAML file. ๐ Blog Post ๐ป GitHub Repository ๐ฌ Watch on YouTube Hey Reader ๐๐ฝ Happy new week! Tobi and I met up last week and spent some time planning the videos ahead. Weโre going more and more into YouTube โ and a few things Iโm hyped about: The biggest AWS mistakes weโve made (so you donโt have to) How...
AWS FOR THE REAL WORLD โฑ๏ธ Reading time: 4 minutes ๐ฏ Main Learning: Which AWS services are worth your time and which ones to skip ๐ฌ Watch on YouTube Hey Reader ๐๐ฝ a new week, new AWS video coming out. I (Sandro) used all of my knowledge from the past six plus years building AWS solutions, ranking the services I actually use and the services I hate. For some I've changed my mind A LOT over the years (e.g. DynamoDB). Let me know what you think and check it out.Here you go AWS News But first of...
AWS FOR THE REAL WORLD โฑ๏ธ Reading time: 12 minutes ๐ฏ Main Learning: The 11 most impactful AWS releases from the past 12 months that have nothing to do with AI. ๐ Blog Post Hey Reader ๐ Every re:Invent recap, every AWS blog, every newsletter from the past year has been dominated by one topic. You know which one. But while everyone was writing about agents and foundation models, the core infrastructure layer kept moving. Quiet releases. No keynote fanfare. Things that actually affect your...