Multi Region Sub-second Replication
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.
Failover In Under A Minute
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.
Use Multiple Replica For Read Only Access
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.
Advantages of Aurora global databases
Aurora global databases can provide you with the following advantages:
- Secondary clusters provide scaling of reads far beyond the capacity of a single Aurora cluster.
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.
- The replication performed by an Aurora global database has little performance impact on the primary DB cluster. The resources of the DB instances are fully devoted to serve application read and write workloads.
- Changes are replicated between AWS Regions with minimal lag time, typically less than 1 second.
- The secondary clusters enable fast failover for disaster recovery. You can typically promote a secondary cluster and make it available for writes in under a minute.
- Applications in remote AWS Regions experience lower query latency when they read from a secondary cluster.
Only the primary cluster performs write operations. Clients that perform write operations connect to the DB cluster endpoint of the primary cluster.
Limitations of Aurora global databases
The following limitations currently apply to Aurora global databases:
- Latest Aurora versions
db.r4ordb.r5instance classes- only in US, Europe and AP regions
- A secondary cluster must be in a different AWS Region than the primary cluster.
- To upgrade your global database clusters, make sure to upgrade the secondary clusters before the primary cluster.
- If the primary AWS Region’s DB instance restarts or fails over, any Aurora Replicas in that Region also restart. The cluster is then unavailable until all replicas are back in sync with the writer of the primary DB cluster.
- No cloning
- No backtrack
- No Aurora serverless option
