EMAIL / LESSON 07
Amazon SES Basics.
What Amazon SES is, how its sandbox works, and when it makes sense to pick it over a friendlier email service
Loading the lesson…
Loading activities…
Browse lessons
EMAIL / LESSON 07
What Amazon SES is, how its sandbox works, and when it makes sense to pick it over a friendlier email service
Loading the lesson…
Loading activities…
Last chapter you sent email through a service that was built to be friendly. This one's about Amazon SES, the email building block that Amazon Web Services (AWS) offers, and what changes when you work one level closer to the raw plumbing.
Amazon SES stands for Amazon Simple Email Service. AWS describes it as "an email platform that provides an easy, cost-effective way for you to send and receive email using your own email addresses and domains."
You can use it for the same kinds of email your app already needs, like order confirmations, password resets and newsletters. It can also receive email, which lets developers build things like autoresponders or support ticket systems out of incoming messages.
The big word here is building block. SES is one service inside AWS, and it's designed to plug into other AWS services. Bounce and complaint notifications can flow into Amazon SNS. Access is controlled through AWS Identity and Access Management, usually shortened to IAM. Sending events can get published to Amazon CloudWatch. That flexibility is the whole point of SES... and it's also why there's more to set up.
A developer-focused email service tries to hide the moving parts. You sign up, add a domain, copy an API key and send. SES hands you more of those parts directly.
Here's what you take on with SES that a friendlier service usually handles for you.
| Area | What SES expects from you |
|---|---|
| Account | An AWS account, which covers far more than email |
| Access | IAM credentials instead of a single API key |
| Location | Picking an AWS Region and setting things up inside it |
| Starting limits | Getting your account out of the sandbox before you can email real users |
| Feedback | Handling bounce and complaint notifications yourself |
None of it is hard once you've done it once. It's just MORE steps, and they're scattered across a bunch of AWS screens instead of one dashboard.
Every new SES account starts out in what AWS calls the sandbox. It exists, in AWS's words, "to help prevent fraud and abuse, and to help protect your reputation as a sender."
While your account is in the sandbox you can use every SES feature, but the official sandbox page lists these restrictions.
That first rule is the one that catches beginners off guard. In the sandbox you can't email your real users AT ALL, only addresses you've proven you own. It's a safe spot to test, and launching from it just isn't possible.
To email anybody, you ask AWS to move your account out of the sandbox and into production. You do that from the SES console by opening the account dashboard, heading to the Get set up page and choosing Request production access.
The form asks you a few things.
Choose Marketing or Transactional, whichever describes most of the mail you'll send. Transactional means one-to-one messages triggered by something the user did, like a password reset.
Enter your website URL so AWS can get a feel for what kind of content you plan to send.
You tick a box agreeing to only email people who explicitly asked for it, and confirming you've got a process for handling bounce and complaint notifications.
AWS says its support team "provides an initial response to your request within 24 hours." If they need more info it can take longer. AWS also points out that verifying your domain first is a best practice that helps your request get approved faster.
Even after you're out of the sandbox, every address you send from still has to be verified. Production access only removes the limit on who you can send TO.
AWS runs its services in lots of Regions, which are physical locations around the world with codes like us-east-1 or eu-west-1. SES is available in a long list of them, shown on the SES endpoints page.
For SES, the Region matters more than you'd expect.
The simple beginner rule? Pick one Region and do everything there.
AWS says that with SES "you pay based on the volume of emails sent and received." The SES pricing page lists the current rates and plans.
That page lists pay as you go pricing alongside several monthly plans, and it describes AWS Free Tier credits that new AWS customers can put toward SES. The plans changed recently, so we won't quote numbers here.
SES is a good fit in these situations.
A friendlier service is often the better first pick in these cases.
There's no wrong answer here. Plenty of apps start on a friendly service and move to SES later, once the volume or the AWS setup makes the extra work worth it.
In the next lesson you'll verify a domain, set up DKIM, SPF and DMARC, create safe credentials and send your very first email from Node.