Amazon Aurora Global Database introduces support for up to 10 secondary Regions

Amazon Aurora is a MySQL and PostgreSQL compatible relational database built for the cloud. It combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open-source databases. Amazon Aurora Global Database is designed for globally distributed applications, allowing a single Aurora database to span multiple AWS Regions. It asynchronously replicates your data with no impact on database performance, enables fast local reads with low latency in each Region, and provides disaster recovery for your applications in case of a single Region impairment.

On May 21st 2025, we announced support for up to 10 secondary Regions. This new capability is available in Amazon Aurora MySQL-Compatible Edition and Amazon Aurora PostgreSQL-Compatible Edition versions that supports the Aurora Global Database configuration. In this post, we dive deep into the new functionality and explore use cases it unlocks.

Overview of Aurora Global Database

An Aurora Global Database consists of one primary Region and up to 10 read-only secondary Regions for low-latency local reads. You issue write operations to the primary DB cluster in the primary Region. Aurora asynchronously replicates the data to the secondary Region DB clusters with latency typically under a second. Aurora Global Database offers cross-Region switchover and failover capabilities so you can change the location (Region) of the primary cluster in your global cluster.

A Global Database switchover is intended for planned events, such as performing disaster recovery drills or Regional rotations. A Global Database failover is intended for recovery from unplanned events, such as those that might cause Regional workload degradation. To learn more about Global Database switchover or failover, see Using switchover or failover in an Amazon Aurora Global Database.

What’s new: Support for up to 10 secondary Regions

Previously, Aurora Global Database supported up to five secondary Regions. With the new functionality, you can expect the same fast, low-overhead replication and Aurora Global Database features such as Global Database failover, Global Database switchover, and write forwarding in up to 10 secondary Regions. This extended secondary Region support enables new use cases and greater scalability for your applications.

Increased scalability for globally distributed applications

Customers have an increasingly global presence, and so do their applications. In an Aurora Global Database, each secondary Region can support up to 16 read-only DB instances. If you have offices around the world, you can use Aurora Global Database to keep your main sources of information updated in the primary AWS Region. Offices in your other Regions can access the information in their own Region, with local latency. Having access to 10 secondary Regions, Aurora Global Database can be expanded to unlock a larger global footprint. This makes fast local reads possible in those additional Regions.

Additional Regions for a “Follow the Sun” use case

A common requirement for globally available applications is to keep both read and write latencies as low as possible. Aurora Global Database allows low-latency reads in secondary Regions; however, writes can only be performed in the primary Region. A “Follow the Sun” model can be beneficial in such situations, where Global Database switchover is performed to promote a Region to primary and make both reads and writes local. With the new support for 10 secondary Regions, the “Follow the Sun” model can be expanded to take advantage of additional 10 Regions.

Add a secondary Region

If you’re already using Aurora Global Database, extending your deployment to support up to 10 secondary Regions is simple. You can manage your Global Database deployment on the Amazon RDS console, the AWS Command Line Interface (AWS CLI), or the Amazon RDS API.

Complete the following steps to add a secondary Region:

1. On the Amazon RDS console, select the Aurora Global Database cluster you want to expand.
2. On the Actions menu, choose Add Region.
   
3. Choose the new Region you want to add as a secondary Region and follow the prompts to complete the configuration.
   

Aurora will automatically begin replicating data to the new secondary Region, and you can start directing read traffic to that Region.The following code example creates a new Aurora DB cluster in a secondary Region and attaches it to an Aurora Global Database as a read-only secondary Aurora DB cluster. The second command adds an Aurora DB instance to the new Aurora DB cluster.

aws rds --region <span><secondary_region></span> 
create-db-cluster 
--db-cluster-identifier <span><secondary_cluster_id></span> 
--global-cluster-identifier <span><Lglobal_database_id></span> 
--engine <span><aurora-mysql | aurora-postgresql></span> 
--engine-version <span><version></span>


aws rds --region secondary_region  
create-db-instance  
--db-instance-class <span><instance_class></span>  
--db-cluster-identifier <span><secondary_cluster_id></span>  
--db-instance-identifier <span><db_instance_id></span>  
--engine <span><aurora-mysql | aurora-postgresql></span>

Conclusion

With support for up to 10 secondary Regions, Aurora Global Database now offers even greater flexibility, scalability, and resilience for globally distributed applications. Whether you’re building a multi-Region disaster recovery strategy, reducing latency for users worldwide, or scaling your application to meet growing global demand, Aurora Global Database provides the foundation for highly available, low-latency workloads.

To learn more about Aurora Global Database, look at the detailed documentation. Explore Aurora Global Database and learn more about these features by heading over to the RDS Console and try creating a Global Database cluster.

About the authors

Aditya Samant is a relational database industry veteran with over 2 decades of experience working with commercial and open-source databases. He currently works at Amazon Web Services as a Principal Database Specialist Solutions Architect. In his role, he spends time working with customers designing scalable, secure and robust cloud native architectures. Aditya works closely with the service teams and collaborates on designing and delivery of the new features for Amazon managed databases.

Rohan Bhatia is a Principal Product Manager on the Amazon Aurora team based in Seattle, Washington.

Shivam Gujral is a Software Development Manager at Amazon on the Amazon Aurora team. In his role, Shivam oversees the development and strategic direction of the vertical focused on global databases, ensuring that Aurora’s distributed database systems operate seamlessly across multiple regions worldwide. His responsibilities extend to architecting and managing high availability and disaster recovery solutions, which are critical for maintaining data integrity, minimizing downtime, and providing robust fault tolerance for Amazon’s cloud database services.

Source: Read More