Managing automated email and text messaging with AWS SES and SNS

Building a website often comes down to choosing between “best–of-breed” services and cost-effective solutions that meet your business needs while being relatively easy to manage. Here we explore AWS services for automated text messaging and email, and compare them with other 3rd party options in the context of work done for GoLibrary. 

At Mugo Web, we encourage our customers to use Amazon Web Services (AWS) tools whenever possible. We have chosen AWS as our preferred cloud hosting and computing services platform, and we find that its wide assortment of integrated services (more than 200 at last count) are usually up to the task and offer pricing advantages that make them an attractive choice for our professionally managed sites.

I bolded professionally managed in that last sentence because it’s an important distinction. AWS services have earned their reputation as being very flexible, and consequently, requiring a bit more configuration and technical know-how than some other single-purpose services. But, we’re tech professionals – so it works for us and our customers.

In this post, I’ll walk through a library website project in which we used AWS Simple Email Service (SES) and Simple Notification Service (SNS) for push notifications, instead of the third-party platforms we once employed. We find the AWS tools to be more than capable of handling the site’s business requirements, and with our experience managing AWS, they were also easy to implement.

Purpose-built with AWS Services

Our customers at the Northern Lights Library System in Alberta, Canada, wanted to launch a site devoted explicitly to encouraging patrons, particularly members of First Nations communities, to sign up for a library card.

The GoLibrary registration flow is handled in the Ibexa CMS and provides helper screens to encourage First Nations community members to get a library card.

We launched GoLibrary, a clean, simple site whose core technical function is library card registration. The site employs three integrated platforms:

• Ibexa, our preferred CMS, for content publication and form management.
• Polaris, the Integrated Library System (ILS) that issues library card numbers (along with countless other tasks).
• AWS hosting and other services, including SES and SNS for sending notifications to registrants that include their new library card number.

Visitors can begin the registration flow at one of two points:

• A listing of libraries in the TRAC Libraries, if the patron already knows their local branch, or
• A helper page that suggests a few nearby libraries, based on which First Nation community the user belongs to.

The site has user-friendly forms to collect information, including email and mobile phone number (phone is optional, but many First Nations patrons use mobile devices as their primary way to access the Internet).

This registration flow is the core value of the GoLibrary project. While many of the TRAC Libraries have card registration options on their websites, the process has been streamlined and made more discoverable through this site. For the GoLibray project, we created a flow by which Polaris issues a temporary card number that allows patrons to immediately access online services, such as ebooks and eLearning courses. To check out physical materials, patrons upgrade to a full card registration when they visit their local branch.

When the user submits the GoLibrary form, Ibexa sends Polaris the relevant information and a request to create a membership/library card number. (We often work with Polaris on our library projects, and its API is optimized for these kinds of requests). Polaris sends us back the ID, but we don’t hold this information within the Ibexa database. To complete the GoLibrary registration flow, we simply send the ID number to the user.

That’s where AWS SES and SNS take over.

AWS SDK scripting

We employ two scripts built on top of the AWS SDK PHP library to send confirmation messages to new library patrons. The AWS SDK is well-documented and highly accessible to any developer who works with PHP applications.

Emails

To create emails, including visually appealing HTML versions, we use the Twig PHP/Symfony templating framework to retrieve needed data, compile the mail, and then send the message via the AWS service. This is all pretty straightforward and typical of how you’d work with SwiftMailer or other open PHP email tools.

Here’s the code we are using to integrate Amazon SES:

$message = (new Swift_Message(
                    'Thank you for registering for a temporary library card at ' . $libraryContent->getName()
                ))
                    ->setFrom('no-reply@golibrary.ca')
                    ->setTo($data['email'])
                    ->setBody(
                        $this->twig->render(
                        '@ibexadesign/emails/user_notification.html.twig',
                            [
                                'library_content' => $libraryContent,
                                'barcode' => $barcode,
                                'data' => $data
                            ]
                        ),
                        'text/html'
                    );
                $this->mailer->send($message);

Text messages

If the patron has provided a mobile phone number during signup, we also send a text message confirming their new membership. This script does not call a template (it’s just a text message) and includes less information, by design.

Here is the code we use to integrate Amazon SNS:

$SnSclient = new SnsClient(
                    [
                        'profile' => 'sns-sms',
                        'region' => 'ca-central-1',
                        'version' => '2010-03-31',
                        'credentials' => CredentialProvider::defaultProvider()
                    ]
                );
 
                $message = 'Thank you for registering for a temporary library card at ';
                $message .= $libraryContent->getName() . '. Your library card number is ' . $barcode . '.';
 
                $messagesLogger = new Logger('messages');
                try {
                    $result = $SnSclient->publish(
                        [
                            'Message' => $message,
                            'PhoneNumber' => $phoneNumber,
                        ]
                    );
                } catch (AwsException $e) {
                    // log error message if it fails
                }

Our script also creates a new Logger object, and we call the publish method of the SnsClient within a try-catch block to handle potential exceptions (specifically, message transmission failure). This helps in troubleshooting the text integration when needed.

That’s it. Again, if you are familiar with the SDK for Twilio or other leading messaging platforms, the AWS SDK will be very familiar to you.

The pros and one kinda-con of AWS

As I said at the start of this post, our team at Mugo Web encourages our customers to standardize as much as possible on AWS hosting. Obviously, AWS doesn’t offer every functional component your site needs – even for the relatively simple GoLibrary site we are discussing here, we are integrating “best-of-breed” CMS and ILS platforms to get the job done.

But for security, resource management, auditing, messaging, and other general site functionality, we find that using AWS tools makes the most sense, for a variety of reasons.

Ecosystem/compatibility

AWS services are pre-integrated if you will – we don’t have to worry that an update to the CDN is going to conflict with an API call to an external system. And since it’s all PHP, you can transfer existing assets (like Twig email templates) into a homogeneous AWS environment without a lot of heavy lifting.

Cost: fees and management

Typically, AWS services are less expensive than recognized “best of breed” solutions, due to their pay-as-you-go pricing model.

For our GoLibrary example:

AWS SES charges 10 cents per 1,000 sent emails. SendGrid (a feature-rich mail service that we’ve used in the past) charges $19.95 a month for up to 50,000 emails monthly in its tiered pricing plans. That’s 50 cents per 1,000, assuming you use all the throughput you pay for.

AWS SNS and Twilio metered pricing is about the same ($0.00645 vs. $0.0075, respectively).

For most businesses, $15-$20 a month in savings for messaging services is not going to move the needle. (There can also be additional savings on data transfers and the like, but, again, it’s not game-changing money for most companies.) The real savings come from using AWS hosting and the simplicity of managing your services via a central platform, and from a shared knowledge base (more on that a bit later). The scale of your cost savings depends on the complexity of your applications and your experience in running websites.

Features: getting the job done vs. best-of-breed

For the GoLibrary site project, we just needed services to pull a few data fields and send notifications to users. AWS had that covered. SES and SNS are both geared toward sending transactional messages, and that’s really all we needed for this application.

That’s not to say they are going to win a straight feature-to-feature comparison with platforms like SendGrid and Twillo. SendGrid has a reasonably friendly UI and advanced marketing features, such as drip email campaigns, that position it as something of a competitor to Mailchimp. Twillo has extensive analytical capabilities, a broad international footprint, and support for all kinds of media, including video. But in many cases, you simply are not going to need all those features. There’s no reason to pay for it or to complicate the administration of the site.

Case in point: On the GoLibrary project, we discovered that SNS sends messages only within a fixed service area, so we can only send confirmation texts to patrons with Canadian area codes. That’s not ideal, but everyone gets an email, so we determined that the texting limitation was not a deal-breaker.

In our experience, we’ve found that many AWS tools (its CloudFront content delivery network, for example) stack up favorably with any solution you might consider. But these do tend to relate to site performance and optimization. For other business functions – CRM, CMS, eCommerce, and the like – you will likely want to integrate a few dedicated platforms. But, if you know what you are doing, simply employing the AWS ecosystem will cover a lot of your business cases.

Flexibility vs. turn-key administration

I’ve alluded to my final point a couple of times now, so here we go. AWS services and tools tend to not have the ease of use offered by “best of breed” solutions, and admins often need to dig a few layers deep to find configurations that the casual business user might expect to be on a dashboard.

This has been our experience. My teammate Carlos Mauri recently noted the somewhat cumbersome steps needed to turn on multi-factor authentication in AWS’s own identity management system. The features are there, but you have to know what you are doing to exploit them to their full potential.

For our team at Mugo Web, this is a manageable reality. We are professional technologists, and we leverage our expertise across numerous site projects. In fact, we keep an extensive wiki of best practices and configurations for the AWS services we use.

For SES, that SOP is about 15 pages long, and includes instructions on:

• Verifying the domain and setting up the sending account (this has to be created under the SES interface, not the global AWS IAM console).
• Turning off “sandbox mode” so that we can send emails to unverified addresses, such as a new library card holder.
• Tracking common email metrics, like source IP and timestamp, via the CloudWatch auditing service. (We built our own template for this task).

The CloudWatch analytics setup is actually a bit of heavy lifting, and might be reason enough for a small business without a dedicated site management team to go with SendGrid or another turnkey platform. But, again, as professional developers and site managers, we are comfortable with this kind of work, and can scale our efforts across numerous projects.

So, AWS was the clear choice for us and our client.

SES and SNS are solid tools with numerous upsides

In this post, I showed you how AWS email and text messaging services can handle a lot of the tasks for which you may be using dedicated “best of breed” solutions. The advantages of an integrated ecosystem and management toolset, plus cost and performance benefits, make AWS SES and SNS a solid option for professionally managed sites.