Using Amazon Aurora global databases - Amazon Aurora
Overview of Aurora global databasesAdvantages of Amazon Aurora global databasesRegion and version availabilityLimitations of Aurora global databases
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Using Amazon Aurora global databases

Amazon Aurora global databases span multiple Amazon Web Services Regions, enabling low latency global reads and providing fast recovery from the rare outage that might affect an entire Amazon Web Services Region. An Aurora global database has a primary DB cluster in one Region, and up to five secondary DB clusters in different Regions.

Topics

Overview of Amazon Aurora global databases

By using an Amazon Aurora global database, you can run your globally distributed applications using a single Aurora database that spans multiple Amazon Web Services Regions.

An Aurora global database consists of one primary Amazon Web Services Region where your data is written, and up to five read-only secondary Amazon Web Services Regions. You issue write operations directly to the primary DB cluster in the primary Amazon Web Services Region. Aurora replicates data to the secondary Amazon Web Services Regions using dedicated infrastructure, with latency typically under a second.

In the following diagram, you can find an example Aurora global database that spans two Amazon Web Services Regions.

An Aurora global database has a single primary and at least one secondary Aurora DB clusters.

You can scale up each secondary cluster independently, by adding one or more Aurora Replicas (read-only Aurora DB instances) to serve read-only workloads.

Only the primary cluster performs write operations. Clients that perform write operations connect to the DB cluster endpoint of the primary DB cluster. As shown in the diagram, Aurora global database uses the cluster storage volume and not the database engine for replication. To learn more, see Overview of Amazon Aurora storage.

Aurora global databases are designed for applications with a worldwide footprint. The read-only secondary DB clusters (Amazon Web Services Regions) allow you to support read operations closer to application users. By using the write forwarding feature, you can also configure an Aurora global database so that secondary clusters send data to the primary. For more information, see Using write forwarding in an Amazon Aurora global database.

An Aurora global database supports two different operations for changing the Region of your primary DB cluster, depending on the scenario: global database switchover and global database failover.

  • For planned operational procedures such as Regional rotation, use global database switchover (previously called "managed planned failover"). With this feature, you can relocate the primary cluster of a healthy Aurora global database to one of its secondary Regions with no data loss. To learn more, see Performing switchovers for Amazon Aurora global databases.

  • To recover your Aurora global database after an outage in the primary Region, use global database failover. With this feature, you fail over your primary DB cluster to another Region (cross-Region failover). To learn more, see Performing managed failovers for Aurora global databases.

Advantages of Amazon Aurora global databases

By using Aurora global databases, you can get the following advantages:

  • Global reads with local latency – If you have offices around the world, you can use an Aurora global database to keep your main sources of information updated in the primary Amazon Web Services Region. Offices in your other Regions can access the information in their own Region, with local latency.

  • Scalable secondary Aurora DB clusters – You can scale your secondary clusters by adding more read-only instances (Aurora Replicas) to a secondary Amazon Web Services Region. The secondary cluster is read-only, so it can support up to 16 read-only Aurora Replica instances rather than the usual limit of 15 for a single Aurora cluster.

  • Fast replication from primary to secondary Aurora DB clusters – 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.

  • Recovery from Region-wide outages – The secondary clusters allow you to make an Aurora global database available in a new primary Amazon Web Services Region more quickly (lower RTO) and with less data loss (lower RPO) than traditional replication solutions.

Region and version availability

Feature availability and support vary across specific versions of each Aurora database engine, and across Amazon Web Services Regions. For more information on version and Region availability with Aurora and global databases, see Aurora global databases.

Limitations of Amazon Aurora global databases

The following limitations currently apply to Aurora global databases:

  • Aurora global databases are available in certain Amazon Web Services Regions and for specific Aurora MySQL and Aurora PostgreSQL versions only. For more information, see Aurora global databases.

  • Aurora global databases have specific configuration requirements for supported Aurora DB instance classes, maximum number of Amazon Web Services Regions, and so on. For more information, see Configuration requirements of an Amazon Aurora global database.

  • For Aurora MySQL with MySQL 5.7 compatibility, Aurora global database switchovers require version 2.09.1 or a higher minor version.

  • You can perform managed cross-Region switchovers or failovers on an Aurora global database only if the primary and secondary DB clusters have the same major, minor, and patch level engine versions. However, the patch levels can be different if the minor engine versions are one of the following.

    Database engine Minor engine versions

    Aurora PostgreSQL

    • Version 14.5 or higher minor version

    • Version 13.8 or higher minor version

    • Version 12.12 or higher minor version

    • Version 11.17 or higher minor version

    For more information, see Patch level compatibility for managed cross-Region switchovers and failovers.

  • Aurora global databases currently don't support the following Aurora features:

    • Aurora Serverless v1

    • Backtracking in Aurora

  • For limitations with using the RDS Proxy feature with global databases, see Limitations for RDS Proxy with global databases.

  • Automatic minor version upgrade doesn't apply to Aurora MySQL and Aurora PostgreSQL clusters that are part of an Aurora global database. Note that you can specify this setting for a DB instance that is part of a global database cluster, but the setting has no effect.

  • Aurora global databases currently don't support Aurora Auto Scaling for secondary DB clusters.

  • To use database activity streams on Aurora global databases running Aurora MySQL 5.7, the engine version must be version 2.08 or higher. For information about database activity streams, see Monitoring Amazon Aurora with Database Activity Streams.

  • The following limitations currently apply to upgrading Aurora global databases:

    • You can't apply a custom parameter group to the global database cluster while you're performing a major version upgrade of that Aurora global database. You create your custom parameter groups in each Region of the global cluster and you apply them manually to the Regional clusters after the upgrade.

    • With an Aurora global database based on Aurora MySQL, you can't perform an in-place upgrade from Aurora MySQL version 2 to version 3 if the lower_case_table_names parameter is turned on. For more information on the methods that you can use, see Major version upgrades.

    • With an Aurora global database based on Aurora PostgreSQL, you can't perform a major version upgrade of the Aurora DB engine if the recovery point objective (RPO) feature is turned on. For information about the RPO feature, see Managing RPOs for Aurora PostgreSQL–based global databases.

    • With an Aurora global database based on Aurora MySQL, you can't perform a minor version upgrade from version 3.01 or 3.02 to 3.03 or higher by using the standard process. For details about the process to use, see Upgrading Aurora MySQL by modifying the engine version.

    For information about upgrading an Aurora global database, see Upgrading an Amazon Aurora global database.

  • You can't stop or start the Aurora DB clusters in your Aurora global database individually. To learn more, see Stopping and starting an Amazon Aurora DB cluster.

  • Aurora Replicas attached to the secondary Aurora DB cluster can restart under certain circumstances. If the primary Amazon Web Services Region's writer DB instance restarts or fails over, Aurora Replicas in secondary Regions also restart. The secondary cluster is then unavailable until all replicas are back in sync with the primary DB cluster's writer instance. The behavior of the primary cluster when rebooting or failing over is the same as for a singular, nonglobal DB cluster. For more information, see Replication with Amazon Aurora.

    Be sure that you understand the impacts to your Aurora global database before making changes to your primary DB cluster. To learn more, see Recovering an Amazon Aurora global database from an unplanned outage.

  • Aurora global databases currently don't support the inaccessible-encryption-credentials-recoverable status when Amazon Aurora loses access to the Amazon KMS key for the DB cluster. In these cases, the encrypted DB cluster goes directly into the terminal inaccessible-encryption-credentials state. For more information about these states, see Viewing DB cluster status.

  • Aurora PostgreSQL–based DB clusters running in an Aurora global database have the following limitations:

    • Cluster cache management isn't supported for Aurora PostgreSQL DB clusters that are part of Aurora global databases.

    • If the primary DB cluster of your Aurora global database is based on a replica of an Amazon RDS PostgreSQL instance, you can't create a secondary cluster. Don't attempt to create a secondary from that cluster using the Amazon Web Services Management Console, the Amazon CLI, or the CreateDBCluster API operation. Attempts to do so time out, and the secondary cluster isn't created.

We recommend that you create secondary DB clusters for your Aurora global databases by using the same version of the Aurora DB engine as the primary. For more information, see Creating an Amazon Aurora global database.