Amazon Relational Database Service
User Guide (API Version 2014-10-31)

Replication with Amazon Aurora

Aurora Replicas are independent endpoints in an Aurora DB cluster, best used for scaling read operations and increasing availability. Up to 15 Aurora Replicas can be distributed across the Availability Zones that a DB cluster spans within a region. Although the DB cluster volume is made up of multiple copies of the data for the DB cluster, the data in the cluster volume is represented as a single, logical volume to the primary instance and to Aurora Replicas in the DB cluster.

As a result, all Aurora Replicas return the same data for query results with minimal replica lag, usually much less than 100 milliseconds after the primary instance has written an update. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag.

Aurora Replicas work well for read scaling because they are fully dedicated to read operations on your cluster volume. Write operations are managed by the primary instance. Because the cluster volume is shared among all instances in your DB cluster, no additional work is required to replicate a copy of the data for each Aurora Replica. In contrast, MySQL Read Replicas must replay, on a single thread, all write operations from the master DB instance to their local data store, which can affect MySQL Read Replicas ability to support large volumes of read traffic.

To increase availability, you can use Aurora Replicas as failover targets. That is, if the primary instance fails, an Aurora Replica is promoted to the primary instance with only a brief interruption during which read and write requests made to the primary instance fail with an exception. If your Aurora DB cluster doesn't include any Aurora Replicas, then the primary instance is recreated during a failure event. However, promoting an Aurora Replica is much faster than recreating the primary instance. For high-availability scenarios, we recommend that you create one or more Aurora Replicas, of the same DB instance class as the primary instance, in different Availability Zones for your Aurora DB cluster. For more information on Aurora Replicas as failover targets, see Fault Tolerance for an Aurora DB Cluster.


Aurora Replicas always use the REPEATABLE READ default transaction isolation level for operations on InnoDB tables. You can use the SET TRANSACTION ISOLATION LEVEL command to change the transaction level only for the primary instance of an Amazon Aurora DB cluster. This restriction avoids user-level locks on Aurora Replicas and allows Aurora Replicas to scale to support thousands of active user connections while still keeping replica lag to a minimum.

For details on how to create an Aurora Replica, see Creating an Aurora Replica Using the Console.

You can set up replication between two Amazon Aurora DB clusters in different AWS regions. For details, see Replicating Amazon Aurora DB Clusters Across AWS Regions.

You can set up replication between two Amazon Aurora DB clusters using MySQL binary log (binlog) replication. For details, see Replication Between Aurora and MySQL or Between Aurora and Another Aurora DB Cluster.

You can set up replication between an RDS MySQL DB instance as the master and an Aurora DB cluster by creating an Aurora Read Replica of a MySQL DB instance. Typically, this approach is used for migration to Aurora rather than for ongoing replication. For details, see Migrating Data from a MySQL DB Instance to an Amazon Aurora DB Cluster by Using a Read Replica.


Rebooting the primary instance of an Amazon Aurora DB cluster also automatically reboots the Aurora Replicas for that DB cluster, in order to re-establish an entry point that guarantees read/write consistency across the DB cluster.

Monitoring Aurora Replication

Read scaling and high availability depend on minimal lag time. You can monitor how far an Aurora Replica is lagging behind the primary instance of your Aurora DB cluster by monitoring the Amazon CloudWatch ReplicaLag metric. Because Aurora Replicas read from the same cluster volume as the primary instance, the ReplicaLag metric has a different meaning for an Aurora DB cluster. The ReplicaLag metric for an Aurora Replica indicates the lag for the page cache of the Aurora Replica compared to that of the primary instance.

If you need the most current value for Aurora Replica lag, you can query the mysql.ro_replica_status table in your Aurora DB cluster and check the value in the Replica_lag_in_msec column. This column value is provided to Amazon CloudWatch as the value for the ReplicaLag metric. The values in the mysql.ro_replica_status are also provided in the INFORMATION_SCHEMA.REPLICA_HOST_STATUS table in your Aurora DB cluster.

For more information on monitoring RDS instances and CloudWatch metrics, see Monitoring Amazon RDS.