Amazon Aurora has recently introduced a Global Database writer endpoint to streamline routing for applications in disaster-recovery scenarios. This highly available global endpoint removes the need for application code changes to reestablish connectivity following a cross-region switchover or failover operation.
Designed for globally distributed applications, Aurora Global Database allows a single Aurora MySQL or PostgreSQL database to span multiple regions, replicating data to enable fast local reads with low latency in each region and providing disaster recovery in case of region-wide outages.
The new Global Database writer endpoint is automatically created for any global cluster and dynamically updates to point to the current writer instance, removing the need to modify configurations when the primary cluster’s location changes. According to the cloud provider, the feature simplifies application routing after initiating cross-region Global Database switchover or failover operations. The cluster's CNAME can be found in the management console or accessed using the RDS CLI or API.
Source: AWS documentation
Luc van Donkersgoed, principal engineer at PostNL and AWS Serverless Hero, comments:
This is great (...) This means you can fail or switch over your writer instance to another region without updating the write endpoint in your applications. Simplifies multi-region implementations a lot!
In its guidelines and best practices, AWS highlights the importance of establishing VPC connectivity between the client application and both primary and secondary regions. Without this setup, the application cannot access the IP addresses in the newly promoted primary region. Additionally, monitoring DNS caching after a global database failover or switchover is crucial: Aurora Global Database emits an RDS event that can be used to invalidate the application’s DNS cache. In a Reddit thread, user Psychological_Gas169 comments:
Finally! No need to go back to my app and update the endpoints every time I switch over to the DB!
Corey Quinn, chief cloud economist at The Duckbill Group, warns:
This is handy but could incur cross-region data transfer charges if it shifts while you're not expecting it.
With Global Database, customers are billed for replicated write I/O operations between the primary region and each secondary region, as well as for cross-region data transfer.
Since Global Database replicates data asynchronously, an automated cross-region failover may result in some write transaction data not being replicated. Although the service makes a best-effort attempt to block writes in the original primary region, the switch remains susceptible to split-brain issues.
The new feature is available in all regions and for all MySQL and PostgreSQL versions supported by Aurora Global Database, including popular regions such as Northern Virginia, Ohio, Dublin, and Tokyo.
