Auto scaling a MySQL database to meet fluctuating application demands
with Amazon Aurora
Amazon Aurora is a MySQL and PostgreSQL-compatible relational database that combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases. In this tutorial, you will learn how to create an Amazon Aurora database and configure it to scale automatically, by adding or removing read replicas, to meet fluctuating demands of your application.
This tutorial is not within the free tier and will cost you less than $1 provided you follow the steps in the tutorial and terminate your resources at the close of the tutorial.
| About this Tutorial | |
|---|---|
| Time | 10-20 minutes |
| Cost | Less than $1 |
| Use Case | Databases |
| Products | Amazon Aurora, Amazon RDS |
| Audience | Database administrators, Developers |
| Level | Intermediate |
| Last Updated | July 2, 2019 |
Step 1: Create an Aurora DB cluster
1.1 - Open a browser and navigate to Amazon RDS console. If you already have an AWS account, login to the console. Otherwise, create a new AWS account to get started.
Already have an account? Log in to your account
Connectivity
1.13 - Select the VPC where you want to create the database.
Note that once created, a database can't be migrated to a different VPC.
1.16 - On Publicly accessible, select “No”.
This means you will have to connect to the database from an EC2 instance within the same VPC.
1.17 - On VPC security group, select “Create new”. If you happen to have a security group that allows incoming TCP connections on port 3306, you can choose it instead. This security group will control ingress to your Aurora cluster.
Additional configuration
Leave the default values for “Additional configuration”.
The best practice is to enable the Deletion protection. If you want to delete the database at the end of the tutorial, you can leave the option unchecked.
1.20 - On “Deletion protection”, uncheck “Enable deletion protection”.
Review and create
After a quick review of all the fields in the form, you can proceed.
1.21 - Click on “Create database”.
While the instances are being created, you will see a banner explaining how to obtain your credentials. This is a good opportunity to save the credentials somewhere, as this is the only time you will be able to view this password.
1.22 — Click on “View credential details”.
Step 2: Add a scaling policy
Aurora Auto Scaling can create and remove replicas based on the scaling policies you define. When the workload or the number of connections to your database suddenly increases, Aurora Auto Scaling can add Aurora Replicas. Once the workload or the number of connections decrease, Aurora Auto Scaling removes the extra Aurora Replicas so that you don't spend on extra capacity.
2.4 - Choose a metric to use for the auto scaling.
There are two Target metrics you can use: “Average CPU utilization of Aurora Replicas” and “Average connections of Aurora Replicas”. Aurora Auto Scaling creates and manages CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and target value. The scaling policy adds or removes Aurora Replicas as required to keep the metric close to the specified target value.
Which metric to use depends on the architecture and workload of your application. If you have to run CPU intensive database queries, measuring the CPU utilization can be a good idea. If your queries are simple but you need to scale reads and writes, then measuring the number of connections could be the way to go.
Keep in mind that a Scaling Policy can be based only on one metric, but you can create more than one Scaling Policies. For this tutorial, you can select “Average connections of Aurora Replicas”.
2.5 - For Target value, enter “20”.
It means Aurora Auto Scaling will add Aurora Replicas if the number of connections reaches the target value of 20, and will remove extra Replicas if it gets below that target value. In all cases, Aurora Auto Scaling only removes Aurora Replicas that it created—never those created by you.
2.7 - For maximum capacity, enter "2".
The numbers for minimum and maximum capacity can be modified later. Which values to use in a production environment will depend on your estimates for workload, number of connections, and budget. The Aurora Replicas created by Aurora Auto Scaling are the same DB instance class as the one used for the primary instance.
Step 5: Delete your cluster
To finish this tutorial, you will learn how to delete your Aurora DB cluster when it's not needed anymore. In order to delete your Aurora DB cluster, go to the RDS Dashboard and follow these instructions:
5.1 - Select “Databases” on the left pane.
This will show you a list of all your Aurora DB clusters.
You will be asked if you want to create a final backup. That's usually a good idea, but it's not necessary for this tutorial.
5.7 - Uncheck the box for “Create final snapshot” and check the box for “I acknowledge...”.
Congratulations
You have created an Aurora DB cluster with Auto Scaling. You have learned how to automatically adjust the capacity of the Aurora DB cluster by adding or removing read replicas based on the needs of your application.
