AWS – Managing Amazon Aurora databases

How to install web server (IIS) on Windows Server 2019

Amazon Aurora is a managed relational database that is compatible with either MySQL or PostgreSQL. You might be wondering why we have Amazon Aurora when Amazon RDS already supports MySQL and PostgreSQL. The keyword with Aurora is compatible—whereas RDS manages the full open source implementation of those databases, Aurora was built from the ground up using AWS storage technologies to offer databases that look and feel like MySQL and PostgreSQL to external tools and clients but offer improved performance and availability.

If you already have an application built on one of these open source databases running on-premises or in the cloud, you can safely migrate it to Aurora with no changes and enjoy a significant performance boost, along with automatic replication across three AZs.

How to do it…

In this recipe, you will configure a new Aurora database instance, securely store the administrative password in Secrets Manager, add a read replica, and perform a backup and restore of the database. Note that the resources you create in this recipe will incur charges on your AWS bill:

  1. Log in to your AWS account and go to the RDS dashboard (Aurora is considered a component of RDS).
  2. Click the Create database button. Choose Amazon Aurora from the Engine options on the following page. Select Amazon Aurora with MySQL compatibility as the Edition:

Engine options
  1. Leave the rest of the settings at the defaults:
    • Regional database location
    • One writer and multiple readers
    • Production template
    • db.r5.large database instance size
    • Multi-AZ deployment
    • Default VPC
  1. Click Create database.
  2. You will see a button to view credential details on the next screen as the database is being created. Click that button and copy the password, along with the connection details. Wait until the database is available.


  1. In this step, you will use the AWS Secrets Manager to store the admin password. Secrets Manager allows you to store secrets and automatically integrates with other AWS services to handle password rotation for you. Open a new browser tab and go to the Secrets Manager dashboard. Click Store new secret.
  2. Select Credentials for the RDS database and paste in the username and password.
  3. Select the database you just created from the options.
  4. Click Next and give the secret a name.
  5. Enable automatic credential rotation, give the rotation lambda function a name, and click Next.
  6. On the final Secrets Manager review screen, take note of the code samples that are relevant for your application and click  Store.
  7. Go back to the Aurora dashboard and view your databases. Note that the top-level node represents the entire cluster. Underneath, you can see the primary writer instance and the read replica. Note that your region and AZs might be different:

Aurora databases
  1. Click on the cluster and note the various tabs that are available for configuration. Take some time to explore each tab:

Aurora cluster configuration
  1. From the Actions menu at the top of the screen, select Add reader.
  2. On the next screen, accept all defaults, enter a unique DB instance identifier, and click Add reader.
  3. From the left-hand menu, select Snapshots, then click Take snapshot.
  1. Choose the DB instance, give the snapshot a name, and click Take snapshot:

Take DB Snapshot
  1. You could create a new cluster based on the snapshot, or you can do a point-in-time recovery.
  2. From the Actions menu, select Restore snapshot.
  3. Note that the following screen is basically the same as the screen to create a new database since you are not overwriting the original.
  4. Accept the defaults, give the restored copy a unique DB instance name, and click Launch DB instance.
  5. When you have completed all steps in this recipe, be sure to delete all instances to avoid further charges! 

How it works…

The storage layer for Amazon Aurora is custom-built to provide a high degree of durability and availability. A total of six copies of your data are spread across three AZs, and snapshot backups are sent to S3 to give you the ability to do a point-in-time restore if your data becomes corrupted. Read replicas in Aurora share the underlying storage with the primary instance, so the replica lag typically associated with reading replicas is much shorter, and there is little to no performance impact on the primary.

Failover for Aurora works a bit differently than with a normal RDS database. Since the storage and compute layers are separate, and storage is spread out over three different AZs, failures that can occur with relational databases due to storage issues are much less likely. If an underlying compute instance needs to be restarted due to a crash, nothing needs to be done to correct or repair the data, and the buffer cache is separate from database processes, so your application will be back up and running at full speed quickly. Another benefit is if you have a cross-region replica set up, you can also fail the database over to the other region.

There’s more…

Aurora serverless is an option that allows you to automatically scale the size of your database up and down depending on usage. If your app is not in use constantly, the instance will be shut down to save money, and then it will be quickly spun back up in response to activity. While not a good choice for applications that see 24/7 usage, it is definitely an option to consider for departmental line-of-business databases that only see use during business hours.

Another interesting feature of Aurora is the ability to create custom endpoints that point to a subset of read replicas. This gives you the ability to create replicas with configurations tuned toward specific workloads and direct those queries at just those replicas.

Comments are closed.