Introduction to the Simple Email Service
Start course
Difficulty
Beginner
Duration
37m
Students
10372
Ratings
4.7/5
starstarstarstarstar-half
Description

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.

Learning Objectives

  • 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

Intended Audience

  • Developers working in a decoupled environment.
  • Cloud Solution architects.
  • Those who are looking to take the AWS Certified Developer - Associate certification.

Prerequisites

  • 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




Transcript

Hello, and welcome to this lecture covering the Simple Email Service, SES. The SES service makes it possible to use AWS infrastructure and email servers 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 they may have just set up on your website, or an email confirmation sent to a customer detailing their online order placed via your site. 

When receiving email, you can architect your application 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 are able to maintain a good communication channel to your customers and third parties. This service is easily able to integrate into your 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're 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.

So, in this very short demonstration, I just wanna show you how to verify a single email address using the SES service. So, if we're near the Management Console, if we just go to the SES service, so Simple Email Service. And if we go across to the left where it says Email Addresses, we can see here that we don't have any verified email addresses at the moment.

So, what I need to do is click on the blue button that says, Verify a New Email Address, put in my email address, and then click on Verify This Email Address. We'll then get a message stating that a verification email has been sent to my email address, and it could take up to an hour for this to arrive. So, I'll just pause this video and come back when it's arrived.

Okay, so I've now got my email from SES, and it's asking me to click on the link to verify that I did actually request this email address. So, all I need to do is click on the link within the email, and here we have a congratulations message saying that we have successfully verified an email address, and we can now start sending email from this address.

I'm now back in the SES dashboard, and we can see that our verification status is now verified. Now, what we can do is send a test email by clicking on Send a Test Email here, select the email format, and I'm going to send an email to myself. This is a test, this is a test. So, send the test email. Now, if I go across to my email, I can see that I have received that email. And that's how you set up and verify a single user for SES.

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 bounced emails or complaint 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 will 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, stuart.scott@cloudacademy.com, with the action of Amazon S3, and SES received an email addressed to stuart.scott@cloudacademy.com, 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 your email based on its source IP address. This method allows you to select if email should be accepted or rejected based on its originating IP address. Through 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 list.

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, we'll be a summary lecture covering some of the key points from the previous lectures.

About the Author
Students
218685
Labs
1
Courses
213
Learning Paths
174

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.