Multi-Region Architectures with Amazon Aurora Global Database - Designing for DR and Global Reads
Achieves an RPO of less than 1 second through physical replication at the storage layer. Introduces the procedures for planned and unplanned failover and how to use Write Forwarding for global reads.
How Global Database Works
Aurora Global Database is a feature that replicates data from the primary Region to secondary Regions, and you can have up to 10 secondary Regions. Whereas ordinary cross-Region read replicas use binlog-based logical replication, Global Database uses physical replication at the storage layer. As a result, replication lag is typically kept under 1 second, and the impact on primary performance is kept small. It is available for both MySQL-compatible and PostgreSQL-compatible editions and requires an instance class of db.r6g.large or larger.
DR Design and Failover
Switchover, which performs a planned Region switch (formerly called managed planned failover), is used for maintenance or Region migration and promotes a secondary Region to primary without losing data. Because it stops writes on the primary and waits for replication to complete before switching, there is no data loss. Failover, which is used when the primary Region fails, typically completes within 1 minute. Data loss equivalent to the replication lag may occur, but the RPO is typically less than 1 second. If your application connects to the Aurora Global Database writer endpoint, after a switchover or failover this endpoint points to the primary at that time. Combining Route 53 health checks with failover routing lets you switch the connection target automatically through DNS.
Using Global Reads
Read replicas in secondary Regions can handle read queries, providing low-latency reads to globally distributed users. If you set the Tokyo Region as the primary and the Virginia Region as the secondary, users in the United States read from the read replica in Virginia, and users in Japan read from the primary in Tokyo. Because only the primary handles writes, writes from users far from the primary Region take time depending on the distance. When you enable Write Forwarding, the secondary side sends write requests to the primary, so you can reduce the Region-routing logic on the application side.
Global Database Pricing
The additional charge for Global Database arises from write I/O for replicated data. Replication I/O in secondary Regions costs about $0.20 per million requests (as of August 2026). Instance and storage charges in secondary Regions are the same as for ordinary Aurora, and the instance class of read replicas does not need to match the primary, so you can choose smaller instances according to the read load. If you use a secondary only for DR without using its read replicas, you can keep costs down by running it on the smallest instance on standby and scaling up at failover. Inter-Region data transfer charges are not billed for Global Database replication.
RPO / RTO and Switching in Practice
In disaster recovery, how much data loss you can tolerate (RPO) and how quickly you need to recover (RTO) are important metrics. Because Aurora Global Database replicates changes in the primary Region to other Regions over dedicated infrastructure, it can keep the data lost during a Region failure small. It supports both planned Region switching and emergency promotion, and can promote a secondary Region to a writable primary in a short time. If you prepare the switching procedure in advance and rehearse it regularly, you can confirm the time recovery takes beforehand.
Use Cases and Design Considerations
Aurora Global Database is a feature intended for applications with users in various parts of the world. By having users read from the secondary database in each Region, you can return data with low latency from a location close to them. On the other hand, because writes are concentrated in the primary Region, you take into account in your design that writes from remote locations incur latency. In addition, because replication between Regions has a slight delay, you allow for the possibility that data read in a secondary Region is momentarily stale. You route processing that needs the latest data to the primary Region and route other reads to the secondary database in each Region.
Summary
Aurora Global Database is a feature that replicates data to multiple Regions at the storage layer and can be used for recovering from Region failures and for reads in Regions close to users. Switchover is used to switch Regions without losing data, and failover is used to recover from a failure of the primary Region. It can be used for the data layer of applications that concentrate writes in one Region and distribute reads across Regions.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon Aurora official page
- Amazon RDS official page
- Amazon Route 53 official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.