What I've learned on Aurora and SES

Since starting working on my latest project, I’ve been introduced to working with Typescript, React, Nextjs, and most notibly, AWS. I’ve never worked on these AWS services before, I have to say, it proved to be an eye opening experience. In regards to the current progression of web development, and as a testament to how the industry have evolved. In this post, I shall strive to share what I’ve learned thus far.

1 AWS Aurora

1.1 What is Aurora?

Amazon Aurora is a relational database management system (RDBMS) built for the cloud with full MySQL and PostgreSQL compatibility. Aurora gives you the performance and availability of commercial-grade databases at one-tenth the cost.

Currently, Aurora only supports PostgreSql and MySQL. Aurora is built for the cloud and is a variant of the standard RDS platform. While working with Aurora, the difference between that and MySQL is almost non existent, at least in terms of CRUD workflow.

For me the main differences lies in the inner workings of the service, which are explained below.

1.2 Backend Optimization

While working with MySQL, I am often faced with some hurdles, mostly when dealing with big data. These experiences forced me to learn optimization tactics. Some I’ve deemed only right for my part to implement, however some I felt, or even wished, should’ve been done automatically.

1.2.1 AWS RDS

Amazon Relational Database Service (Amazon RDS) is a collection of managed services that makes it simple to set up, operate, and scale databases in the cloud. Choose from seven popular engines — Amazon Aurora with MySQL compatibility, Amazon Aurora with PostgreSQL compatibility, MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server — and deploy on-premises with Amazon RDS on AWS Outposts.

RDS makes it that a database platform to be deployed in a secure and optimized manner with only a few clicks. When deployed, RDS is able to automate maintenance of the platform with automated backup and patching capabilities as well. However this is not the main source of Aurora’s performance advantage of other databases.

While Aurora does extend upon RDS, allowing it to not only have automated maintenance, but an optimized storage subsystem as well. The optimized storage subsystem is designed with NVMe SSD drives, instead of EBS used by RDS, which gives a much more significant performance boost.

The benefits are as follows:

  1. Creates six copies of your data, distributed across multiple locations and continuously backed up to AWS S3.
  2. Data replication accross multiple regions for fast local performance as well as disaster scenarios.
  3. Automatic scaling as your application grows

1.3 Automated Maintenance and Patching

AWS RDS enables the monitoring of the data in real time. These data can be viewed in the console, as well as managing which specific data to monitor and customize the dashboard according to your requirements.

Monitoring can be done either through Enhanced Monitoring or CloudWatch

RDS delivers the metrics from Enhanced Monitoring into your Amazon CloudWatch Logs account. You can create metrics filters in CloudWatch from CloudWatch Logs and display the graphs on the CloudWatch dashboard. You can consume the Enhanced Monitoring JSON output from CloudWatch Logs in a monitoring system of your choice. For more information, see Enhanced Monitoring in the Amazon RDS FAQs.

1.3 Working with Aurora

As I’ve mentioned before, the differences between the average workflow of using traditional DB(MySQL) and Aurora for developing CRUD apis are almost non-existent.

However, while using Aurora, I’ve come to the conclusion that comparing it to MySQL is a bit unfair. While Aurora does have a much more optimized storage subsytem, the main draw of using it instead of MySQL alone is the automated monitoring and patching. Which is a service provided by AWS and should not be looked at as a con when deciding to use Aurora + MySQL or just MySQL.

Just to be clear, I’m not making light of the optimized sub system, it’s definitely a plus and even a must have on certain scenarios such as scaling one’s application to a targeted degree.

However, optimization is also possible with MySQL, using the AWS console to monitor connections and and view SQL performance has helped tremendously in terms of debugging the optimizing our apis.


2.1 What is SES?

AWS SES is a service in AWS that allows your app to send and recieve emails with your own designated emails or domains.

For example, you can send marketing emails such as special offers, transactional emails such as order confirmations, and other types of correspondence such as newsletters. When you use Amazon SES to receive mail, you can develop software solutions such as email autoresponders, email unsubscribe systems, and applications that generate customer support tickets from incoming emails.

While in development, AWS SES is in sandbox mode, meaning it can only send and recieve emails from verified identities.

2.2 Verified Identities

A verified identity is/are emails or domains you’ve registered in AWS SES via the AWS console in order to send emails.

2.3 Benefits

Traditionally, building large scale email solutions is complex and costs a lot of money. Dealing with challenges in maintaining the email server, network cconfigurations and IP address reputation. As is often the main draw of these AWS services, these problems are handled swimmingly by the platform, allowing crutial configurations to be set appropriately with but a click of a button.

2.4 Working with SES

Overall working with SES was failry simple. I merely had to download the typescript api, setup the aws cli, verify an identity(in my case was an email) and was able to start fairly quickly.