AWS Serverless Services
The course is part of this learning path
In this section of the Cloud Practitioner learning path, we introduce the concepts of decoupled and event-driven architectures and introduce various serverless services in AWS that are relevant to the CLF-C01 exam.
- Identify examples of decoupled and event-driven architectures
- Understand how AWS services such as SQS and SNS can integrate with decoupled and event-driven architectures
- Describe the various serverless services in AWS and their associated use cases
This course is designed for anyone who is new to cloud computing, so no prior experience with AWS is necessary. While it may be helpful to have a basic understanding of AWS and its services, as well as some exposure to AWS Cloud design, implementation, and operations, this is not required as all of the concepts we will introduce in this course will be explained and reinforced from the ground up.
Hello, and welcome to this lecture, covering the SNS service. It's likely that out of the free services covered within this course, this is a service you may have come across the most, simply due to its integration with a number of other AWS services. The Simple Notification Service is used as a publish and subscribe messaging service. But what does this mean? SNS is centered around topics, and you can think of a topic as a group for collecting messages. Users or endpoints can then subscribe to this topic, and messages or events are then published to that particular topic. When a message is published, all subscribers to that topic receive a notification of that message. This helps to implement event-driven architectures within a decoupled environment.
Again, much like SQS, SNS is a managed service and highly scalable, allowing you to distribute messages automatically to all subscribers across your environment, including mobile devices. It can be configured with the AWS management console, the CLI, or the AWS SDK. As mentioned, SNS uses a concept of publishers and subscribers, which can also be classed as consumers and producers, and works in the same principle as SQS, from this perspective. The producers or publishers send messages to a topic, which is used as the central communication control point. Consumers or subscribers of the topic are then notified of this message by one of the following methods, HTTP, HTTPS, email, email JSON, Amazon SQS, application, AWS Lambda, or SMS.
Subscribers don't just have to be users. For example, it could be a web server, and they may be notified of the message via the HTTP protocol. Or if it was a user, you could use the email notification method and enter their email address. SNS offers methods of controlling specific access to your topics through a topic policy. For example, you might want to restrict which protocols subscribers can use, such as SMS, or HTTPS, or only allow access to this topic for a specific user. The policy themselves follow the same format as IAM policies. For more information on IAM policies, please see our existing IAM course which is available within our library of content. I will now perform a demonstration, showing you how topic policies are configured and the different options within them, which allows you to apply access security to your topics.
So in this demonstration, I'm just gonna show you where to find your SNS policies and how to edit them, et cetera. So if we go to our SNS service, and if we create a new topic, go down to create topic here. And if we give it a topic name of Cloud Academy, and then go to create topic. From here, we can now edit the topic policy. So if we go to other topic actions, we can see here, the second option down is edit topic policy. Now there's two views here, a basic view and an advanced view. The basic view shows the policy is very much a point and click overview, so it's very simple to understand.
So this top section here allow these users to publish messages to this topic. We can say only myself, everyone or only these users, and we can enter users in this box here. I'm just gonna leave it as only me for this demonstration. And at the bottom here, you can see, allow these users to subscribe to the topic. So again, you can restrict it to only yourself, everyone or only specific AWS users. And down here, you can also specify different delivery protocols as well that I spoke about earlier. So again, for this demonstration, I'm just gonna leave it as only me. If we go to the advanced view, we can see the policy as a JSON view.
Now I explain that if you are familiar with IAM policies, this is laid out in exactly the same fashion. So we have the version at the top. We have a statement. We have a statement ID. And then also we have the usual parameters of effect principle, an action and resource. So if you look at this, for example, we can see that this will allow any principle with the following actions. For example, we can publish the SNS. We can delete the topic, et cetera. Now if we scroll down, we can see resource. And this resource line shows that it's the Cloud Academy topic that I just created. Now you can edit this policy directly in here and simply click on update policy if you're confident to do so. But like I say, it follows the same principles as IAM policies. And it's through these policies that you can control access to your SNS topics. And that's it.
Both SNS and SQS integrate with each other, which makes sense as both of these services are designed to run in a highly distributed and decoupled environment. By working together, a solution can be designed to send messages to subscribers through a push method, or SQS handles incoming messages and waits for consumers to pull data. Therefore, being able to use SNS as a producer for an SQS queue makes perfect sense from a development perspective. To do this, you'll need to have your SQS queue subscribed to the SNS topic. And this can be achieved by performing the following steps within this demonstration.
So in this demonstration, I'm gonna show you how you can use SNS as a producer for an SQS queue. So from within the management console, if we go to our SQS service again, and we can find the queue that we had earlier. So if I just select that, and then go to queue actions, then you can see down here, you have subscribe queue to an SNS topic. If I select that, now I can select the topic region and the topic that I want. Now the topic that I created earlier was in the EU Ireland region, so by selecting this drop down list, I should be able to find the Cloud Academy topic. And there it is. And that gives our topic ARN. If we say subscribe, we get a confirmation message to say that this queue has successfully subscribed to the following SNS topic, which is the Cloud Academy topic. And it also set up the relevant permissions as well to allow that to happen. So if we click on okay, now we can test this out. If we go through to SNS, and if we go to our topics and Cloud Academy, and the first thing that we can see is the SQS queue is actually subscribed to this topic. So that was the action we just carried out.
Now I wanna test this by publishing a message to this topic to make sure that SQS receives a copy of it. So if I click on publish to topic, and I'll just create a message here just called, Cloud Academy Test. This is a test, and click on publish message. Now that has published a message to that topic, so any subscribers should receive a copy, which means our queue should also receive a copy. So if we go back to SQS, we can see here that messages available is one. So if we go across and select our queue, and go to view/delete messages, click on start polling for messages, we can see here straight away that we have our message that we received from the topic. And if we go to more details, we can see here the subject of Cloud Academy Test, and also the message, "This is a test." So this proves that we have successfully used SNS as a producer for this SQS queue. Much like SQS, SNS also integrates well with AWS Lambda, a key serverless computer service. To learn more about serverless technologies, you can view our existing learning path, entitled, "Serverless Computing on AWS for Developers," which can be found here.
This integration allows SNS notifications to invoke existing Lambda functions. Like SQS, the Lambda function has to be subscribed to the topic. Then when a message is sent to the topic, the message is pushed out to the Lambda function to invoke it. The function itself uses the payload of the message as an input parameter, where it can then alter the message if required, or forward the message onto another AWS service, or indeed to another SNS topic.
To configure AWS Lambda to work with the topic, you can perform the following steps. From within the SNS dashboard of the AWS management console, select topics. Select the topic that you want to subscribe to with the Lambda function. Select actions and subscribe to topic. Using the protocol menu, select the AWS Lambda option. Then you must select the Lambda function to be used from the endpoint dropdown box.
Finally, you can select the version or alias of the function, and select the latest version of the function. Choose the latest option. Select create subscription. To gain more insight into this process and to see an example of how this can be used to create a sample message history store using SNS Lambda and Amazon DynamoDB, you can view this blog post made by AWS found here. We also have a lab which would teach you how to process SNS notifications with a Lambda function. As a simple example, the lab uses Python to log custom metrics to CloudWatch based on the message payload. That now brings me to the end of this lecture, which covered an introduction to the Simple Notification Service.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.