Amazon Aurora is a MySQL- and PostgreSQL-compatible relational database built for the cloud. It combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases. Amazon Aurora Global Database is designed for globally distributed applications, allowing a single Aurora database to span multiple AWS Regions. It asynchronously replicates your data with no impact on database performance, enables fast local reads with low latency in each Region, and provides disaster recovery for your applications in case of a single Region impairment.

On October 22, 2024, we announced the availability of the Aurora Global Database writer endpoint, a highly available and fully managed endpoint for your global database that Aurora automatically updates to point to the current writer instance in your global cluster after a cross-Region switchover or failover, alleviating the need for application changes and simplifying routing requests to the writer instance. The endpoint is available for both Aurora MySQL-Compatible and Aurora PostgreSQL-Compatible Global Database.

In this post, we dive deep into the new Global Database writer endpoint, covering its benefits and key considerations for using it with your applications.

Overview of Aurora Global Database

An Aurora global database consists of one primary Region where your data is written and up to five read-only secondary Regions for low-latency local reads. You issue write operations to the primary DB cluster in the primary Region. Aurora asynchronously replicates the data to the secondary Region DB clusters with latency typically under a second.

Global Database offers cross-Region switchover and failover capabilities that allow you to change the location (Region) of the primary cluster in your global cluster. A global database switchover is intended for planned events, such as performing disaster recovery drills, or Regional rotations. For example, you might want to provide lower-latency writes in different Regions based on business hours across different time zones. You can achieve this by changing the location of the primary cluster accordingly. A global database failover is intended for recovery from unplanned events, such as a rare single Region impairment. To learn more about global database switchover or failover, see Using switchover or failover in an Amazon Aurora Global Database.

Traditional connection routing following a switchover or failover

To route requests to the writer DB instance in a global database, you traditionally connected to the associated cluster endpoint that routes requests to the writer instance. Upon a switchover or failover, however, you had to reconfigure the application code or configuration to reestablish connectivity to the writer instance in the newly promoted primary cluster. To avoid making application changes and unintended errors, some customers built a custom DNS-based solution that would redirect the incoming requests to the correct writer DB instance using a CNAME. However, this custom-built solution has a few limitations, such as a lack of TLS/SSL support.

Introducing Global Database writer endpoints

The newly launched Global Database writer endpoint provides a seamless and secure solution for routing write requests to the appropriate writer instance. A Global Database writer endpoint is a highly available, fully managed endpoint that points to the current writer DB instance, enabling you to perform cross-Region global database switchover or failover without having to reconfigure your application’s code or configuration files to connect to the writer instance. This feature streamlines the application architecture, enhances operational efficiency, and provides secure communication with the DB instances.

Getting started with the Global Database writer endpoint

To get started, you must connect your applications to the new Global Database writer endpoint. You can find the endpoint details on the Amazon Relational Database Service (Amazon RDS) console under your global cluster details. Alternatively, you can use the describe-global-clusters API with the AWS Command Line Interface (AWS CLI) to obtain the endpoint information. Aurora automatically creates the endpoint when you add a new Region to your single-Region Aurora cluster. Additionally, Aurora provides the Global Database writer endpoint by default for existing Global Database clusters.

When you view an Aurora global database on the AWS Management Console, you can see the new Global Database writer endpoint under your Global Database cluster details page on the Connectivity & security tab.

The following screenshot shows a global database called gdb-demo with the primary DB cluster in the us-east-1 Region and the secondary DB cluster in the us-east-2 Region. You can see the new Global Database writer endpoint on the Connectivity & security tab.

How the Global Database writer endpoint works

A Global Database writer endpoint is an Amazon Route 53 endpoint. Aurora automatically updates the Global Database writer endpoint’s DNS entry along with other necessary metadata after you initiate a global database switchover or failover. To further explain how the endpoint helps, we discuss two common access patterns that you can use to connect your application to a global database.

Remote cross-Region access pattern

When implementing this pattern, your application stack remains in its current Region rather than failing over with the database. With the new global writer endpoint, your application continues to connect to the same endpoint following a global database switchover or failover operation across Regions. After your application registers the DNS change, new requests automatically route to the writer in the newly promoted primary cluster, alleviating the need for code changes to reconnect to the new writer instance.

A key consideration for minimizing disruption with this access pattern is establishing virtual private cloud (VPC) connectivity between your application and the various Regional DB clusters in your global database. When you initiate a cross-Region switchover or failover, you first choose a secondary Region. Upon the completion of the switchover or failover operation, the DB cluster in the chosen Region is promoted as the new primary DB cluster. Because your application stack remains in its original (old primary) Region and VPC, it requires appropriate networking access between the two VPCs to establish connectivity to the database.

VPC peering is one such solution to establish cross-VPC connectivity. The following figure illustrates that the application and database exist in both primary and secondary Regions. To enable the application in VPC-A to connect to the writer instance in VPC-B after a switchover, we’ve implemented VPC peering between our primary and secondary Region DB clusters’ VPCs. See Amazon VPC-to-Amazon VPC connectivity options to learn about options for configuring networking between VPCs in different Regions. With this remote access pattern, the read and write operations might experience latency because the application servers will be communicating cross-Region with the new primary cluster.

Local access pattern

When implementing this pattern, your application stack moves with the database to the same Region as the primary cluster. For example, in the case of a rare Regional outage, your application server in the current Region would also become unresponsive and need to move to another Region.

For this pattern, you must make sure that your application stack is deployed in all of the secondary Regions with the appropriate network access set up between your application servers and the associated secondary Region database cluster. With the new Global Writer endpoint, your application configurations across the different Regional stacks will use the same endpoint, minimizing the likelihood of configuration errors.

When configured appropriately, your application can resume read and write requests after the writer instance in the new primary Region becomes available following a global database switchover or failover operation. The following figure illustrates this architecture.

New Amazon RDS events and best practices

Aurora now generates additional Amazon RDS events in response to state changes in the global database. We discuss these RDS events and best practices when using the Global Database writer endpoint in this section.

  • Configure connectivity before starting switchover or failover – To minimize disruption following a switchover or failover, you might want to set up VPC connectivity between your application servers and the various Regional clusters in your global database.
  • Avoid overlapping IP addresses between primary and secondary Region DB clusters – A Global Database cluster spans across multiple Regions, and each Regional cluster is housed within a separate VPC. During the planning phase, we recommend creating these Regional VPCs so that their IP address ranges (VPC CIDR blocks) don’t overlap. Having distinct, non-overlapping IP address ranges across the Regional VPCs can help prevent application connections from inadvertently resolving to an incorrect IP address in a different Region when the primary Region changes.
  • Maintain consistency between primary and secondary cluster configurations – After a secondary cluster is promoted, it doesn’t automatically inherit the configuration of the old primary cluster. To mitigate configuration mismatch, we recommend you create and configure an Aurora DB cluster parameter group in advance.
  • Update the DNS name of the Global Database writer endpoint – With the Global Database writer endpoint, it is possible that although Aurora might have updated the endpoint, it might take some time for the DNS entries to reflect on your client and for your application to register them. You can monitor RDS-EVENT-0397, which Aurora will publish when it has finished updating the DNS name that the Global Database writer endpoint resolves to. You can use this event to devise strategies to make sure that your application doesn’t cache the DNS entries beyond the time after the event is generated.
  • Additional considerations for global database failover – During a global database failover, Aurora proactively takes measures to provide a smooth transition to the new primary cluster. One of the key mechanisms employed is the halting of write traffic to the primary cluster through the highly available storage layer of Aurora. When this process is successful, Aurora emits the RDS-EVENT-0390 notification, keeping you informed that writes have been stopped. In rare cases when multiple Availability Zones experience failures, the process of halting writes might time out. Aurora informs you of this time-out by emitting the RDS-EVENT-0391. If the old primary cluster is reachable on the network, these events are recorded there. Otherwise, the events are recorded on the new primary cluster. Although the potential for a split-brain issue exists during this brief time-out period, Aurora event notifications empower you to monitor the process and address potential inconsistencies that might arise in certain situations.

For more information, see Considerations with using Global writer endpoints.

Conclusion

In this post, we explored the new Aurora Global Database writer endpoint and its benefits. You can use this feature to simplify routing for your requests to the writer instance without needing to update the endpoint in your application after initiating a cross-Region switchover or failover for your global database. To learn more about Aurora Global Database, see Using Amazon Aurora Global Database.

About the Authors

Aditya Samant is a relational database industry veteran with over 2 decades of experience working with commercial and open-source databases. He currently works at Amazon Web Services as a Principal Database Specialist Solutions Architect. In his role, he spends time working with customers designing scalable, secure and robust cloud native architectures. Aditya works closely with the service teams and collaborates on designing and delivery of the new features for Amazon managed databases.

Rohan Bhatia is a Principal Product Manager on the Amazon Aurora team based in Seattle, Washington.

Shagun Arora is a Sr. Database Specialist Solutions Architect at Amazon Web Services. She works with customers to design scalable, highly available and secure solutions in the AWS Cloud.

Source: View source