An Aurora global database consists of one primary AWS Region where your data is maintained, and up to five read-only, secondary AWS Regions. Aurora replicates data to the secondary AWS Regions with typical latency of under a second. You issue write operations directly to the primary DB instance in the primary AWS Region.
An Aurora global database uses dedicated infrastructure to replicate your data, leaving database resources available entirely to serve application workloads. Applications with a worldwide footprint can use reader instances in the secondary AWS Regions for low-latency reads. In some unlikely cases, your database might become degraded or isolated in an AWS Region. If this happens, with a global database you can promote one of the secondary AWS Regions to take full read/write workloads in under a minute.
The Aurora cluster in the primary AWS Region where your data is mastered performs both read and write operations. The clusters in the secondary Regions enable low-latency reads. You can scale up the secondary clusters independently by adding one of more DB instances (Aurora Replicas) to serve read-only workloads. For disaster recovery, you can remove a secondary cluster from the Aurora global database and promote it to allow full read and write operations.
Aurora global databases can provide you with the following advantages:
A secondary cluster doesn’t have a writer primary DB instance. This functionality means that it can have up to 16 read-only Aurora Replica instances, instead of the limit of 15 for a single Aurora cluster.
Only the primary cluster performs write operations. Clients that perform write operations connect to the DB cluster endpoint of the primary cluster.
The following limitations currently apply to Aurora global databases:
db.r5 instance classes