Why Cross-Region Replication Is Hard
Replicating a database across AWS regions means sending data over the public internet (or AWS backbone) between geographically distant data centers. The fundamental constraint is physics: the speed of light limits how fast data can travel from us-east-1 (Virginia) to ap-southeast-1 (Singapore) — roughly 170ms of round-trip latency at minimum.
Standard cross-region replication in RDS MySQL uses logical replication (binary logs). The primary region executes a transaction, writes it to a binlog, ships the binlog to the secondary region, and the secondary region re-executes the SQL statements. This process is slow, CPU-intensive on the secondary, and can lag by minutes under heavy write load — meaning a regional disaster could result in minutes of lost data.
How Aurora Global Database Works
Aurora Global Database uses physical storage replication — it copies the raw redo log records directly at the storage layer, bypassing the compute engine in the secondary region entirely.
- Mechanism: The primary region's storage layer ships redo log records to the secondary region's storage layer over a dedicated, low-latency replication channel. The secondary region's compute instances read from this replicated storage just like they would from local storage.
- Replication Latency: Typically under 1 second between any two AWS regions, regardless of write volume.
- RPO (Recovery Point Objective): Less than 1 second. In a regional disaster, you lose at most 1 second of data.
- RTO (Recovery Time Objective): Less than 1 minute. Promoting a secondary region to become the new primary is a manual or automated operation that completes in under 60 seconds.
Topology
A Global Database consists of:
- 1 Primary Region: Handles all writes. Can have up to 15 read replicas within the region.
- Up to 5 Secondary Regions: Read-only. Each secondary region can have up to 16 read replicas of its own, serving local read traffic with low latency for globally distributed users.
Managed Planned Failover vs. Unplanned Failover
- Planned Failover (Switchover): Used for maintenance or region migration. Aurora synchronizes the secondary fully before promoting it, guaranteeing zero data loss (RPO = 0).
- Unplanned Failover (Detach and Promote): Used when the primary region is completely unavailable. The secondary is promoted immediately, accepting up to ~1 second of data loss.