The course is part of these learning pathsSee 1 more
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 beginners 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 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
- Identity 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 Simple Email Service, SES. The SES service makes it possible to use AWS infrastructure and email service to handle an automated email system to communicate with your customers. This makes it a good choice for marketers and developers. For example, you could use SES to send a confirmation email to customers, notifying them of their new account details that's setup on your website or an email confirmation sent to a customer detailing their online order placed by your site. When receiving email, you can architect your applications to respond automatically to incoming emails such as request to unsubscribe to your newsletter or develop applications to receive incoming email from customers and automatically create tickets that can be assigned to your team to resolve their issues. As expected, it's a very reliable and cost-effective service that ensures you're able to maintain a good communication channel to your customers and third parties. This service is easily able to integrate into existing systems such as your SMTP interfaces or existing applications using the AWS SDKs. So, let's answer the two most obvious questions you may have, how do I send email and how do I receive email? If you are new to SES, then you will initially be placed within a sandbox environment which allows you to set up a single email address to test and understand the service in greater detail. To show you how to do this, I will demonstrate how to set up a single email. When you are ready to move onto a larger and wider scale distribution of emails, you can request to be moved out of the sandbox environment by opening a ticket within the AWS Support Center to increase the limits for SES sending.
More information on this process can be found using the following link. Once out of the sandbox environment, you can also start to monitor your sending activity including the number of bounce emails or complain emails. Also, you are able to verify entire domains rather than individual email accounts. As a part of the managed service offering of SES, when you receive emails via SES, AWS will automatically scan for spam and viruses and reject any messages from untrusted sources. When receiving email, there are two ways to configure SES to instruct it as to what to do with the email. These being recipient-based control and IP address-based control. Both of these methods can work together to direct SES as to where to send the email and if it should be accepted. With recipient-based control, you set up configurations to direct the email based on the recipient. These recipient lists are classed as conditions. Receipt rules are used to control what action is taken when a condition is met, so when the recipient of the email matches the recipient in the condition list. When a match is found, the recipient rule would carry out the associated action for that particular rule. If no match is found, then the email is deleted. The actions that are available to these rules are as follows, the S3 action. The email will be delivered to a nominated S3 bucket and if required, SNS can also be used to add a notification on when this delivery occurs. SNS action, the email will be published to an SNS topic where all subscribers of the topic will receive a copy of the entire email message. Lambda action, this incoming email will result in calling a lambda function. Again, SNS can be used to notify you when this event occurs.
Bounce action, this simply rejects incoming email and returns a bounce response to the sender of the email. SNS can again be used to manage notification of this event. Stop action, this will stop the evaluation of the receipt rule set. Add header action, this will simply add a header to the email. And finally the WorkMail action, this action will use Amazon WorkMail to process the email. So, as an example, if you had a condition listed, email@example.com with the action of Amazon S3, and SES received an email addressed to firstname.lastname@example.org, the receipt rule set would be analyzed until the condition was met, which is my email address. At this point, SES would analyze the required action, which would be to store the email on Amazon S3 and send a notification that this action has happened via SNS, if configured to do so. IP address-based control defines what happens to an email based on its source IP address. This method allows you to select if an email should be accepted or rejected based on its originating IP address. For the use of different lists, which relates to allow or block emails, it can help you prevent SES from delivering emails from unwanted sources, but allowing mails from known and trusted sources. Behind the scenes of SES, the service maintains, operates, and updates its own list of known spamming sources to help reduce the amount of unwanted emails delivered. One point to mention here is that by default, all email that originates from EC2 instances is blocked. As a result, you must add them to your allow list if this is a requirement. With both of these processes in place, the incoming flow of email to SES is as follows. IP address-based control is applied first to identify if the email should be allowed or blocked based on the configured lists. If the email is allowed, SES reviews your receipt rule set to identify a match within the conditions. If no conditions are met, the email is dropped at this point. If a match is found, SES will carry out the action based on the matching rule. That now brings me to the end of this lecture covering the introduction of SES. Coming up next will be a summary lecture covering some of the key points from the previous lectures.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date Stuart has created over 40 courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
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.