AWS SES and SNS, your first notification service

Getting started with AWS is not an easy challenge, even for experience programmer, especially if we consider all available services, which is still growing and growing. I don’t want to frighten you or flood you with massive portion of information you will not remember until the end of this article, so I decided to focus on two popular notification services. Mainly I want to focus on showing you a difference between this two services.

Ok, before we begin, let’s describe basic assumptions of SES and SNS. Short form SES means Simple Email Service and you should now be able to guess why we use it. Of course to send email messages, but in contrast to typical e-mail service like gmail it provides a massive number of other functionality, like for example increased limit of messages per day (gmail has a limit of 500 messages per day, with SES service we can get the limit even up to 50000). Insight in statistics of send-messages and built-in notifications of unsuccessful message deliveries goes hand to hand with better control over our service. SNS or Simple Notification Service is there to provide more or less the same functionality like SES. In most cases, we use API provided by AWS management console to set the format of our messages.

General differences

There are a few differences between SES and SNS, although they provide similar functionality for some use-cases. 

To send emails through SNS, the email address must be subscribed to SNS topic. Subscribing an email address to a topic requires confirmation from the owner of the email address. SNS has a notion of topic, which means that you cannot send email in SNS to a specific user – only to a specific topic. All users subscribed to a topic will receive the message. SNS is oriented towards broadcast sending, while SES can support point-to-point sending and has no support for broadcast today. SES can also send messages to any email address with no prior confirmation. It’s meant for sending high volume email efficiently and securely. Once you have verified that you are the owner of an email address, you can send emails through SES to any other e-mail address without the recipient’s consent. SES takes care of the engineering required to ensure delivery of their emails. On the other hand, that forces high levels of security, so that it does not become a spammer’s dream.

SES provides full support for a rich email experience, such as HTML, links, and images. SNS allows you to publish notifications across multiple protocols, such as HTTP, SQS and email protocols. SNS also has a lower price per email than SES.

SNS is meant as a channel publisher/subscriber service. In order to receive e-mails from SNS, the end-user must first subscribe (via means enabled by the developer) and approve that subscription through e-mail before amazon delivers e-mails from the subscribed channel to that end-user. End-users can subscribe via e-mail, SMS, web-hooks and other means up to the user independent of the publisher.

On a practical level, we use SES to send our users emails about their content and we use SNS to send our developers notifications (via SMS and email) when servers go down or have issues. If you want to send specific emails to specific users it seems SES is the way to go.

Sending an Email via Amazon SES Console 

Amazon SES console is by far the easiest way to send an email with Amazon SES.

It is usually used for sending test email because it requires information to be entered manually by you. After getting acquainted with Amazon SES, you will probably start sending your emails using either the Amazon SES SMTP interface or API. Still, the console is useful for activity monitoring purposes. 

Amazon SES lets you send transactional email, marketing messages, or any other type of high-quality content to your customers. You can do that by following four steps:

     Step 1: Create SMTP Credentials

     Step 2: Verify An Email Address

     Step 3: Request Removal Of Amazon SES Restrictions

     Step 4: Configure Your Application To Use Amazon SES.

To protect customers from abuse, Amazon SES does not immediately grant unlimited Amazon SES usage to new users. Initially there are a number of restrictions, such as only being able to send email to and from verified email addresses and being limited to a maximum of 200 messages per day.

The final step is all about configuring your application to use Amazon SES. The procedure to do this varies from application to application but typically, you will need to configure the application with the correct SMTP server information and credentials. This is possible through direct application configuration files edition or simply by entering the required information using the application user interface. 

Sending an Email via Amazon SNS Console

Again we will use Amazon console to configure our service features. In contrast to SES service, it’s not necessary to confirm your email, instead you must create SNS Topic. You can think of it as a storage for your messages. This is where your messages will be pulled from. The advantage over SES is straight forward – you don’t have to limit the number of email messages. You can configure your service to send sms messages using single phone number.

You can start working with AWS SNS by logging into AWS console. From there you can create a topic, provide a name and display name for the topic and create a subscription. You can also add another subscriber.

SES pros and cons 

+publishing notification across multiple protocols

+supports custom email header fields

-higher price than SNS

-only email messages are supported

SNS pros and cons

+multiple subscribers

+lower price than SES

-limited to 8192 characters of UTF-8 strings

-multimedia content is not supported

-need for confirmation of recipient’s email address

-sending messages only to specific topic allowed

So, when should I use SNS and when SES?

The answer is simple. SNS service will be a great support in applications that are strictly focused on delivering messages (especially not email messages). Possibility to support massive number of messages and huge number of potential subscribers will be best option in such apps. Also low price could be one of the reasons why we should use it.

On the other hand, when using SES we should focus on apps where subscriptions wouldn’t be possible. This solutions is oriented towards safety because we can directly send email message to any mailbox, there is no requirement to confirm anything or to be in specific topic. Even higher price shouldn’t deter you from using it, especially if security has big importance.      

If you have come this far…

This short guide was meant to introduce you to basics of SES and SNS, their structure and usage rules and also show you some differences and cases when these two excel. There are so many types of application where this two services rule the roost so you should understand that it was not possible to include them into this short article. However I hope that reading it brought you some basic knowledge and next time you will want to create your app that uses either SES or SNS, you will know which service you should choose.