Read Replicas for Read Scaling

Read Replicas are copies of your RDS primary instance that receive updates through asynchronous replication. Unlike the Multi-AZ standby, Read Replicas are accessible for SELECT queries, allowing you to distribute read traffic and reduce the load on the primary database.

Read Replicas are supported for MySQL, PostgreSQL, MariaDB, Oracle (with Active Data Guard), and all Aurora editions. You can have up to 15 Read Replicas for Aurora MySQL and Aurora PostgreSQL, and up to 5 for standard RDS MySQL/PostgreSQL.

To create a Read Replica, your source instance must have automated backups enabled (retention period greater than 0). AWS takes a snapshot of the primary, restores it in a new DB instance, and establishes asynchronous replication from the primary.

Each Read Replica gets its own DNS endpoint. Your application must be updated to direct reads to the replica endpoints. Connection poolers or application frameworks with read/write splitting can route SELECT queries to replicas automatically.

Because replication is asynchronous, Read Replicas may lag behind the primary by a few milliseconds to seconds depending on write volume. This is called replication lag. You can monitor it via the ReplicaLag CloudWatch metric.

Applications must be designed to tolerate eventual consistency when reading from replicas. For example, after inserting a record, immediately reading from a replica might not return the new row yet. Read-after-write consistency requires routing that specific read back to the primary.

RDS supports creating Read Replicas in a different AWS Region, enabling global read scalability and disaster recovery. Cross-region replication uses the public internet or AWS Global Accelerator, and replication lag is higher than within a Region due to network latency.

Cross-region replicas are useful when: you want to serve reads closer to users in another geography, you need a warm DR copy in another Region ready to be promoted, or you want to offload analytical queries away from production.

Promoting a Read Replica breaks the replication link and makes it an independent, writeable primary DB instance. This is used in disaster recovery scenarios when the original primary is unavailable, or when you want to upgrade the replica to a different engine version and use it as the new primary.

Promotion is irreversible—once promoted, the instance can no longer be a replica. Before promoting, ensure the replica is as caught up as possible (minimal lag) to minimise data loss. After promotion, update your application's connection string to the new primary endpoint.

On the SAA-C03 exam, distinguishing Read Replicas from Multi-AZ is critical:

• If the scenario asks for improved read performance or read scaling → Read Replicas
• If the scenario asks for automatic failover or high availability → Multi-AZ
• If the scenario asks for both → Multi-AZ on the primary plus Read Replicas

Also remember: Multi-AZ standbys do NOT serve reads; Read Replicas do NOT provide automatic failover (you must promote manually for non-Aurora replicas).

Aurora handles Read Replicas differently from standard RDS. Aurora uses a shared distributed storage layer, so replicas access the same underlying data pages as the primary. This means Aurora replicas have minimal replication lag (typically under 100 ms) and can each serve read traffic.

Aurora provides a Reader Endpoint that load-balances connections across all available replica instances. Your application connects to the Reader Endpoint and Aurora distributes reads automatically. If a replica fails, it is removed from the reader pool without affecting the endpoint.

In Aurora, if the primary (writer) instance fails, Aurora automatically promotes one of the Read Replicas to primary in approximately 30 seconds—much faster than standard RDS Multi-AZ failover. The promoted replica starts accepting writes through the Cluster Writer Endpoint immediately.

Aurora supports failover priority tiers (0–15) so you can control which replica is promoted first. Assign higher-priority (tier 0) to replicas on larger instance classes or in preferred AZs.

A typical read-scaling architecture routes traffic through an Application Load Balancer or application logic:

• All write operations (INSERT, UPDATE, DELETE) → Primary DB endpoint
• All read operations (SELECT) → Read Replica endpoints or Aurora Reader Endpoint
• Session cache and result cache → ElastiCache (further reduces replica reads)

For analytics queries that are extremely heavy, consider promoting a replica or using Aurora's parallel query feature to push computation to the storage layer, avoiding impact on the production cluster.

Key CloudWatch metrics for Read Replicas include:

• ReplicaLag — seconds behind the primary; alert if this grows unexpectedly
• ReadIOPS — ensures the replica's storage keeps up with query load
• DatabaseConnections — ensures the replica is not connection-saturated
• CPUUtilization — high CPU on replica indicates query optimisation needed

RDS Performance Insights is available on Read Replicas and shows the top SQL statements consuming the most DB time, helping you identify and optimise expensive read queries.

Common use cases for RDS Read Replicas on the SAA-C03 exam:

• Reporting and analytics: run heavy SELECT queries on a replica to avoid slowing production writes
• Geographic distribution: cross-region replicas serve users in other continents with lower latency
• Disaster recovery: cross-region replica can be promoted if the primary Region fails
• Development/testing: promote a replica to create a test environment with a current copy of production data

Read Replicas are not a replacement for backups—always maintain automated backups and manual snapshots independently.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Read Replicas use asynchronous replication to distribute read traffic, replication lag means replicas may be slightly behind the primary, and Aurora replicas have minimal lag and support automatic promotion. Cross-region replicas provide both global read scalability and a DR option. Next up we explore RDS security with encryption and parameter groups.