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 which will highlight some of the key points mentioned throughout the previous lectures within this course. I started by talking about the Simple Queue Service, SQS. And within this lecture, I explained that SQS is a fully managed service offered by AWS. It's ideally suited for serverless systems, market services, and distributed architectures. It's capable of sending, storing, and receiving messages at scale and the service is based around producers, consumers, and an SQS queue. Producers are responsible for sending messages to your queue and consumers are responsible for processing messages in the queue. The SQS queue is distributed across multiple services for resiliency.
And when a message is retrieved, the visibility timeout is started. When the message is processed, the consumer then deletes the message from the queue. The default time for the visibility timeout is 30 seconds, but it can be set up to 12 hours. If the visibility timeout expires before receiving a delete message request, the message becomes available again. Standard queues, which is the default queue type, and it supports at least once delivery of messages and they offer a best effort on message ordering and they also offer an almost unlimited number of transactions per second. First in first out queues, the order of messages is maintained. There are no duplication of messages and the default TPS is 300 for all send/receive and delete operations.
TPS for batching can be up to 3,000. Encryption can be enabled using server-side encryption via KMS. And dead letter queues are used to hold messages that fail to be processed and they allow engineers to assess why the message failed and these also must be configured as the same queue type as the source it is used against. Following this lecture, I then focused on Simple Notification Service. Within this lecture, I covered the following points. SNS is used as a publish subscribe messaging service. Users or endpoints can subscribe to SNS topics. Messages or events are published to topics which are then pushed to all subscribers to that topic. They're very useful in an event-driven architecture within a decoupled environment. They are highly scalable and it can be configured within the AWS Management Console, the CLI or using the AWS SDKs. Different methods of notification can be used when subscribing such as HTTP, email, AWS Lambda, and SQS. Subscribers don't just have to be users and SNS offers methods of controlling specific access to your topics through topic policies. These policies follow the same format as IAM policies. SNS integrates well with SQS in a highly distributed and decoupled environment. SNS can act as a producer for an SQS queue and SNS also integrates with Lambda to invoke functions. The Lambda function has to be subscribed to the topic for this to work. When a message is sent to the topic, the message is pushed to the Lambda function to invoke it and the message is used as the input parameter for the Lambda function.
The last lecture within this course focused on the Simple Email Service, SES, and here I explained the following points. SES uses AWS infrastructure and email service to handle an automated email system to communicate with your customers. It's an ideal service for marketers and developers and applications can be developed to respond automatically to incoming emails such as request to unsubscribe to your newsletter. It's very reliable and cost-effective and it's easily integrated into your existing systems such as your SMTP interfaces. When sending email, the first time you configure SES to send email, your environment is placed in a sandbox for single email address testing. To move out of this sandbox environment, you must open a ticket within the AWS Support Center to increase the limits for SES sending. This allows you to then monitor sending activity along with bounced and complaint emails and verify entire domains.
When receiving email, SES automatically scans for spam and viruses and receipt of emails and rejects messages from untrusted sources. Recipient-based control and IP address-based control work together to direct emails. Recipient-based control, recipient lists are created called conditions. Receipt rules are used to control what action is taken when a condition is met. And when a condition match is found, the recipient rule will carry out the associated action for that email such as an S3 action, SNS action, or a Lambda action, et cetera. If no match is found, the email is deleted. IP address-based control defines what happens to an email based on its source IP address. The email is accepted or rejected based on different IP lists. And SES operates and updates its own list of known spamming sources to delete unwanted email. And by default, all email that originates from EC2 instances is blocked. That now brings me to the end of this lecture and to the end of this course. You should now have a greater understanding of the three different AWS services discussed, SQS, SNS, and SES, and be able to distinguish when you would need to use each service within your decoupled and distributed architecture. If you have any feedback on this course, positive or negative, please do contact us at firstname.lastname@example.org. Your feedback is greatly appreciated. Thank you for your time and good luck with your continued learning of cloud computing, thank you.
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.