Throughout today’s digital world, databases play a key role in the growth of your business. Just as the operating system is known to be the core of a computer system, databases are referred to as the heart of websites, applications, and organizations. Therefore, having the right Database Management System is a must, so that you can guarantee high availability of your database, with fewer crashes and less downtime. In today’s “automate all” environment, cloud vendors are also striving to automate this complex, yet still-manual, work. And that’s where Amazon Aurora can help.
Since its release, Amazon Aurora has changed the world of databases by eliminating bottlenecks from conventional databases plus adding new features like a serverless database, where you don’t need to buy or request a physical server to host your database. As with Lambda, it is the duty of AWS to scale your database specifications smoothly on demand–per the required resource and configuration.
Veteran DABs will be blown away from such a DB environment. Considering that Aurora aims to replace the existing traditional databases, including MySQL and PostgreSQL, you should take a careful look inside this new serverless database world.
Aurora is one of the fastest-growing relational database engines of AWS and is a part of the Amazon Relational Database Service, i.e., RDS. People often mistake RDS for a database. So, to clarify: RDS is a service, not a database, and is responsible for managing database engines supported by AWS.
Aurora blends the speed and consistency of a high-end business database with the flexibility and cost-efficiency of an open-source database. The Aurora engine is compatible with two database systems: MySQL and PostgreSQL. Amazon claims that their Aurora PostgreSQL databases are 3x faster than standard PostgreSQL databases, whereas Aurora MySQL databases are 5x faster than standard MySQL databases. So, if anyone is using MySQL and PostgreSQL, they can easily shift/migrate to Aurora Engine without making any changes to their code.
For applications using Microsoft SQL Server, AWS recently announced Babelfish – a translation layer that enables Aurora PostgreSQL to understand Microsoft SQL protocol (T-SQL). By using this tool, migrating applications of this kind to use Aurora includes only minimal code changes. This project will also be available soon as open-source code.
Aurora also provides automatic scaling for the database storage, which can both increase or decrease over time. Therefore, your bill will be calculated by the actual amount of storage used. The amount of IO requests that Aurora can execute is also scalable, enabling great burst performance (for both read & write).
In mid-2018, AWS announced the availability of Aurora Serverless to the world. The term “serverless” means that you will be charged for what you have used. You don’t need to worry about provisioning the instances. All you need to do is create the cluster as per your current requirement, and all the maintenance, patching, backups, replication, and scaling are handled automatically in the backend by Amazon.
In December-2020, AWS announced Aurora Serverless v2, which introduced significant improvements to the scaling mechanism. These improvements can lead to much better performance and to cost reduction. You can read more about that on AWS website.
Note: Currently Aurora Serverless supports only MySQL Version 5.6/5.7 and PostgreSQL Version 10.12.
The diagram below will show you how Aurora Serverless works behind the scenes:
3 Use Cases of Amazon Aurora
Amazon Aurora can be used in the following cases:
- e-Commerce websites, where no one knows when your website is going to be flooded with high traffic, for which Aurora’s auto-scaling feature is perfect.
- Gaming development; since Aurora is 5x faster than traditional databases, it can be very useful here.
- New startups with limited staff (and funding) prefer Aurora because all database-related items are managed and supported by AWS.
Key Features of Amazon Aurora Database
Aurora comes with many features, but before we get to that, let’s understand why AWS created Aurora when there were already so many database engines on the market. Amazon wanted to create a database engine that was faster, simpler, and capable of reducing users’ overall cost for provisioning and managing a database instance.
So what are the features included by AWS that make Aurora a winning option?
Autoscaling of Storage
With the increase in data set records, Aurora will continuously check for available storage; if it is running out of storage, then Aurora automatically scales the storage with a chunk of 10GB, which can go up to 64TB.
Aurora is highly available, achieved by having six copies of your data in three availability zones.
With Aurora, you can have cross-region replicas. You can add 15 Aurora replicas on every cross-region cluster. (Note: This feature is only available for Aurora MySQL, not for Aurora PostgreSQL.)
Aurora creates, in parallel, a buffer cache for the database. So, in case you encounter a database restart, the buffer cache will remain, which helps you to quickly start again from where you left off.
Crash Recovery in a Blink
Aurora is capable of automatically handling crashes with the help of Aurora replicas. If a master database crashes in the same or different AZs, then Aurora simply updates the CNAME of this database to a healthy replica and makes it a master database. However, if the crash results in a cross-region, then you have to manually promote the available healthy region to take the read-write operations.
An Aurora database is always created in VPC (Virtual Private Cloud), which is an isolated network provided by AWS to your organization; you have total control, and no one outside of your organization can touch your databases.
This is a newly added feature to Aurora and is only supported by MySQL. As the name suggests, now you can have multiple master databases in multiple AZs.
Pros and Cons of Aurora Database
In this universe, nothing is flawless, and Aurora is no exception. Here, you will see some of the benefits of using Aurora along with some of its drawbacks.
- Aurora provides great auto-scaling for storage, IOPS, and for compute size when using Aurora Serverless.
- You don’t need to have a big budget to get started with Aurora, as you pay for what you use.
- Aurora can be easily integrated with other AWS services like DMS (Database Migration Service), Amazon Simple Storage Service (Amazon S3), AWS Lambda, etc.
- Aurora offers periodic and automatic updates that always refresh the server systems with the latest features and improvements.
- With Aurora, you can bring up a database within a fraction of a second, which is very helpful if you need a test database for some quick debugging.
- Aurora doesn’t provide support to the latest MySQL and PostgreSQL versions.
- There is still no support for additional database engines; currently, Aurora is limited to MySQL and PostgreSQL
- Although Aurora has the ability to autoscale and descale as needed, you have to be cautious about database growth and how much it will cost.
- You can add new nodes in the database cluster, but these newly added nodes can’t perform write operations.
- In order to work with Aurora, you must have prior working knowledge in AWS. If you don’t know what a VPC is, you’ll face difficulties working with Aurora.
You’ve now heard many times that with Aurora you only pay for what you’ve used. This is true, but the actual price of Aurora is divided into many factors, which you need to be aware of.
For example, let’s consider that a user creates an Aurora Serverless instance in North Virginia, USA, with 4 CPUs, 8GB RAM, 200GB of storage, and no additional backup policy. He used this instance 24 hours/day and received 200,000 I/O requests in the entire month. Then, the end-to-end cost that he will have to pay for the entire month will be around $196. You can check the AWS monthly calculator to learn more.
So, irrespective of the price list, what are the factors you need to consider.
Database Instance Pricing
Here you will be charged for creating the database instances, which is further divided into two parts: On-Demand Instance Pricing and Reserved Instance Pricing. For on-demand instances, pricing is done on an hourly basis, whereas for reserved instances, pricing is calculated for a 1-year or 3-year term. Reserved instances are eligible for additional discounts on hourly pricing as well. For instance pricing, check this official link from AWS.
Database Storage and I/O Pricing
The amount of storage acquired by your database will be billed at $0.11 per GB/month. You also have to pay for the I/O requests that your database has received and will be charged $0.22 per million requests.
Backup Storage Pricing
There is no additional pricing for backup storage of your database cluster if you don’t keep a copy of your backup for more than a day. But if you keep something beyond this period, then Amazon will charge you. Also, if you have deleted your database cluster and forget to delete the backups, then you will be charged for storage at a rate of $0.023 per GB/month.
If you want to immediately recover from a database crash at a specific point in time, then Aurora can help. But for that, Aurora will charge you $0.013 hourly per million Change records, simply called retain logs.
Pricing for Data Transfers
The price for a data transfer between EC2 and Aurora is free as long as they are in the same Availability Zone (AZ). But if the data transfer is done in different AZs, then you have to pay the price. Please note pricing for IN/OUT varies per region. For more info, you can check this AWS official link.
Getting Started with Aurora Database
This section will show you how to create an Aurora database, what configurations you can change/modify, and how you can connect to your Aurora DB once it is created. Finally, we will provide a working example that shows how a Lambda Function can be written to stop/start the Aurora database.
Creating an Amazon Aurora Database
Follow the steps below to create an instance of an Aurora database. We are using MySQL for this demonstration.
Step 1: Log in to your AWS Management Console; in Services, choose RDS.
Step 2: Select the AWS Region where you want to create your Database cluster.
Step 3: In Databases, click on “Create database,” as shown in Screenshot A.
Step 4: Then choose Easy Create as a database creation method and Amazon Aurora for your engine type. Refer to Screenshot B.
Step 5: In Edition, we have chosen Amazon Aurora with MySQL 5.6 compatibility. Select the DB Instance Size as per your requirement. Give a name to your cluster, create a Master username and Master password, and finally click on “Create database.” Check Screenshot C.
Step 6: You will finally see a window showing the creation of your database, as can be seen in Screenshot D.
Connecting to Amazon Aurora Database
There are many ways to connect to your database in Aurora, but we will only focus on connecting through the command line.
Step 1: First make sure your database is publicly accessible, like the one shown in Screenshot E.
If not, then select your database and modify the Public accessibility setting from “No” to “Yes.” Also, please write down the Endpoint and Port as well.
Step 2: Second, make sure to edit the Inbound Rules in your Security Group to allow Port 22 and Port 3306 either for all IPs or for the selected ones. Check Screenshot F.
Step 3: Don’t forget to attach your Internet Gateway to your VPC. If you are using a default VPC, it is already attached. Finally, open your Terminal and write the following command line to access the database:
mysql -h epsagon-aurora-instance-1.cbpfizkbgias.ap-south-1.rds.amazonaws.com -P 3306 -u epsagon -p
Type the password that you made upon creating the Aurora Database, and you will be able to get into your MySQL DB. Check Screenshot G.
A Lambda Function to Start/Stop Amazon Aurora Database
In order to make this article precise, here we will assume that readers already have prior basic knowledge of AWS. We will use the CloudWatch event to trigger a Lambda Function, which in turn starts/stops our Aurora MySQL database. But before that, we have to perform the following steps:
Step 1: Create an IAM policy that contains some permissions, as shown in Screenshot H.
Step 2: Create an IAM Role that includes the policy created above. Refer to Screenshot I.
Step 3: Create a Lambda Function by visiting the AWS Management Console using Python 3.7. See Screenshots J and K.
Step 4: Add this Python script in Function Code, which is actually responsible for starting/stopping the Aurora database. Finally, click on “Save.” Check Screenshot L.
In our Python script, we are using tag “Epsagon-Aurora-Tag” to identify the database to start/stop. We have assigned this tag name to our DB Cluster, as shown in Screenshot M.
Step 5: After this, create two rules in CloudWatch. One for starting the database instance and another for stopping it. See Screenshot N.
Step 6: In order to test the Lambda Function, adjust the Rules created above to trigger every minute, and check your CloudWatch logs to see the action performed by the Lambda function. In Screenshots O and P, you will see the Aurora database has been successfully started and stopped.
Monitoring Amazon Aurora with AWS CloudWatch
CloudWatch enables you to easily monitor the health of your database instances with the help of informative graphs. In order to use CloudWatch, you just need to click on “Monitoring,” while creating the Aurora Database. Check Screenshot Q.
Once your database is up and running, you can now directly monitor your database either from the CloudWatch dashboard or from the Database Monitoring tab, as shown in Screenshots R and S below.
Amazon Aurora is currently ruling the IT market. This is due to many reasons, which we have tried to cover in this piece. Amazon is also continuously working on making improvements and creating new features to make it even more popular worldwide.