With this course, you will be helping and enabling your development teams to architect applications that are highly scalable and resilient using best practices when working within a decoupled environment. This will lead to increased availability of operational service to their applications helping to minimize incidents that would affect the end user.
In this course, you will learn to design greater applications using managed services in a decoupled environment along with being able to differentiate and explain the differences between SQS, SES, and SNS.
Though designed as a beginner's course, a basic awareness of AWS Lambda and IAM policies would give a headstart in better understanding the core principles of this course. In this course, you will find three comprehensive lectures along with further resources that can be found in the description box underneath the respective lectures.
- Explain the difference between SQS, SNS, and SES
- Understand when you would use each SQS, SNS, and SES within a solution
- Identify and explain the key components of within SQS, SNS, and SES
- Developers working in a decoupled environment.
- Cloud Solution architects.
- Those who are looking to take the AWS Certified Developer - Associate certification.
- An awareness of IAM policies and how they are constructed.
- For more information on IAM policies, please see the following course.
- Basic knowledge of AWS Lambda.
Related Training Content
- Getting Started with AWS Simple Notification Service (Lab)
- Manage Message Queueing with AWS SQS (Lab)
- SQS Versus SNS (Course)
Hello, and welcome to this lecture covering the SNS service. It's likely that out of the three services covered within this course, this is the 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 over 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 a 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 can 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 protocol 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. 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. 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 to select the latest 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 will 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.