Aurora Replicas

In Multi-AZ deployments, Aurora creates additional Aurora compute instances that interact with the underlying storage layer, which spans multiple Availability Zones. These other DB instances are read-only and are known as Aurora Replicas. They are also referred to as reader instances when discussing the ways that you can combine writer and reader DB instances within a cluster. One benefit of Aurora Replicas is that you can offload some of the work for read-intensive applications by using the reader instances to process SELECT queries.

When a problem affects the primary instance, it fails over to one of these secondary reader instances, which takes over as the primary instance. Aurora detects database problems and activates the failover mechanism automatically when necessary. For more information about Aurora failover, see High availability for Amazon Aurora.

Aurora Replicas add no additional costs in terms of consumed storage or disk write operations, because all the instances in the Aurora DB cluster share the underlying storage volume. The log stream generated by the writer and sent to the storage nodes is also sent to all reader instances. In the reader instance, the database consumes this log stream by considering each log record in turn. If the log record refers to a page in the reader instance's buffer cache, the reader instance uses the log applicator to apply the specified redo operation to the page in the cache. Otherwise, the reader instance discards the log record.

Note that Aurora Replicas consume log records asynchronously from the perspective of the writer instance, which acknowledges user commits independent of the reader instances. Aurora Replicas typically lag behind the writer instance by a short interval (100 milliseconds or less). For more information about the relationship between the cluster volume, the primary DB instance, and Aurora Replicas in an Aurora DB cluster, see the AWS documentation.