Achieve cost-effective multi-Region resiliency with Amazon Aurora Global Database headless clusters

Many organizations with critical workloads and global footprints need a strategy to tolerate Region-wide outages. This requires making a trade-off between availability, Recovery Time Objective (RTO), and cost. You should consider using a tiered approach to meet your compliance and budgetary needs.

When developing a cross-Region disaster recovery (DR) strategy, an important consideration is the cost of running resources in the DR region. A viable, cost-effective DR strategy is critical to maintaining business continuity and ensuring regulatory compliance.

In this post, we talk about the benefits of using Amazon Aurora Global Database headless clusters as a part of your DR solution and how to achieve cross-Region disaster recovery.

A headless secondary Amazon Aurora database cluster is one without a database instance. This type of configuration can lower expenses for an Aurora global database. In an Aurora database cluster, compute and storage are decoupled. Without the database instance, you’re not charged for compute. You can add instances to the Aurora cluster in the secondary region to make it available to your users and applications. For full pricing and regional availability see Amazon Aurora Pricing.

As of this writing, you have two options to tolerate Region-wide outages in Aurora:

• You can use cross-Region replication or Aurora Global Database to meet strict availability requirements.
• You can use cross-Region snapshot replication as an alternative solution. In this case, both RTO and RPO increase because the Amazon Aurora storage volumes used by instances in your Aurora cluster have to be hydrated from the snapshot in Amazon Simple Storage Service (Amazon S3). The time required to hydrate these volumes is workload dependent.

Solution overview

An Aurora global database cluster with a headless cluster configuration is a global cluster that spans at least two regions. The primary region supports an Aurora database cluster that consists of one writer Aurora database instance (compatible with either MySQL or PostgreSQL), one or more replicas in the same or different Availability Zone, and a cluster volume that represents the data for the primary database cluster. A secondary region contains the cluster volume that represents the data for the secondary database cluster. Aurora replicates data to the secondary regions using a dedicated infrastructure over the AWS backbone for a network with latency typically under a second. You can create up to five secondary regions with Aurora global databases. The following diagram illustrates this configuration.

For the list of Regions where Aurora global databases are available, refer to Aurora global databases.

You can create an Aurora global database with a headless configuration in one of the following ways:

• Convert an Aurora cluster to a global database with a headless configuration – You can create an Aurora global database with a headless configuration by adding a secondary cluster without an Aurora database instance.
• Modify an existing Aurora global cluster to create headless configuration – To convert a secondary region cluster into a headless configuration, you can delete the Aurora database instances from the secondary region Aurora cluster. This secondary cluster is now considered headless.

Aurora global database uses the dedicated infrastructure in the Aurora purpose-built storage layer to handle replication across regions. The storage volume used by the (now) headless secondary cluster is kept in sync with the primary region Aurora cluster. For details, visit Amazon Aurora global databases.

Prerequisites

Before you start the process with creating a headless configuration, set up the environment for your Aurora database. For more information, see Setting up your environment for Amazon Aurora. You also need to complete other preliminary steps for creating any Aurora cluster. To learn more, visit Creating an Amazon Aurora DB cluster.

Convert an Aurora cluster to an Aurora global database with headless configuration

You might have an existing Aurora provisioned DB cluster running an Aurora database engine that’s global-compatible. If so, you can add another region to it to create your Aurora global database with headless configuration. Complete the following steps:

1. On the Amazon RDS console, choose Databases in the navigation pane. This page lists the information about the primary region cluster.
   
   You can also use the AWS Command Line Interface (AWS CLI):

   aws rds describe-db-clusters \
   --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,Endpoint:Endpoint,ReaderEndpoint:ReaderEndpoint,DBClusterArn:DBClusterArn,EngineVersion:EngineVersion}' –region us-west-1

2. Convert the Aurora primary cluster into an Aurora global cluster. You must perform this step via the AWS CLI:

   aws rds create-global-cluster --region us-west-1 \
   --global-cluster-identifier global-cluster \
   --source-db-cluster-identifier arn:aws:rds:us-west-1:123456789012:cluster:mysql-uswest –-region us-west-1

3. Return to the Amazon RDS console to confirm the global database configuration.
4. Identify the secondary region where you want to create the headless cluster and add the secondary region using the AWS CLI:

   aws rds create-db-cluster \
   --region us-east-1 \
   --source-region us-west-1 \
   --db-cluster-identifier mysql-useast \
   --global-cluster-identifier global-cluster \
   --engine aurora-mysql \
   --engine-version 5.7.mysql_aurora.2.07.2 \
   --kms-key-id 0643cdb5-381a-42fb-9877-41000bc332f3 

   If the Aurora cluster storage volume in the primary region is encrypted, the cluster volume in the secondary region is encrypted. In this case, you must pass the AWS Key Management Service (AWS KMS) key ID to the secondary region. This KMS key can be either AWS managed or customer managed. It can take several minutes for the status of a newly added secondary region Aurora DB cluster to change from Creating to Available.

5. Review the configuration on the Amazon RDS console.
   

The secondary region cluster is now part of the Aurora global database, and has no associated instances. With this approach, you have converted your Aurora database into an Aurora global database with a headless configuration.

Modify an existing Aurora global cluster to create a headless configuration

In other cases, you might have an existing Aurora global database. If so, you can modify the secondary cluster to convert to a headless configuration. Complete the following steps:

1. On the Amazon RDS console, choose Databases in the navigation pane. This page shows the information about your existing global cluster.
   
   You can also find this information via the AWS CLI:

   aws rds describe-db-clusters \
   --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,Endpoint:Endpoint,ReaderEndpoint:ReaderEndpoint,DBClusterArn:DBClusterArn,EngineVersion:EngineVersion}'

2. Expand the Aurora global database secondary cluster.
3. Select the reader instance in the secondary cluster and choose Delete.Optionally, you can use the AWS CLI to delete the instance:

   aws rds delete-db-instance \
   --db-instance-identifier mysql-useast-instance-1 

4. Return to the Amazon RDS console to confirm your configuration.

The secondary region cluster is now part of the Aurora global database, but no longer has instances attached to it. With this approach, you have modified an existing Aurora global database into an Aurora global database with a headless configuration.

Perform failover with a headless Aurora global database

Before proceeding with failover, you must add a DB instance to an existing headless cluster in the secondary region using the AWS CLI:

aws rds create-db-instance \
--db-instance-identifier mysql-uswest-instance-1 \
--db-cluster-identifier mysql-useast \
--db-instance-class db.r5.large \
--engine aurora-mysql \
--engine-version 5.7.mysql_aurora.2.07.2 \
--region us-east-1

Failover with an Aurora global database with headless configuration is no different than failover with Aurora global databases after an instance is added to the headless cluster. For more information, see Recovering an Amazon Aurora global database from an unplanned outage.

Conclusion

In this post, we walked through creating an Aurora global database with a headless configuration in a secondary region, and how to fail over to it.

Aurora global database headless clusters are a cost-effective strategy to build multi-Region resiliency. This allows you to achieve the subsecond latency available with Aurora Global Database without the additional costs associated with unused instances in the secondary region. You can make the secondary region available to users and applications after instances are added to the cluster in that region. Additionally, you can use this approach as a DR strategy if you have an RTO greater than the time it takes to add (and make available) instances in the secondary region.

If you have any questions, comments, or suggestions, please leave a comment. You can also visit the AWS re:Post.

For additional information on the architecture and performance of Aurora, refer to the User Guide.

About the Authors

Kanwar Bajwa is a Sr. Technical Account Manager at AWS based out of Toronto. He works with our customers to provide guidance, technical assistance and helping them improving the value of their solutions when using AWS.

Srinivas Ganapathi is a Sr. Technical Account Manager at AWS, and is based out of Toronto, Canada. He helps customers achieve operational excellence by transparently integrating their business processes with the AWS cloud. Srinivas loves to reduce complexity and eliminate downtime for his customers.