RDS Read Replica: What It Is and When to Use It

Definition

An Amazon Relational Database Service (Amazon RDS) Read Replica is a read-only copy of a primary (source) database instance. Its primary purpose is to elastically scale out beyond the capacity of a single database for read-heavy workloads, increasing aggregate read throughput by distributing read queries across multiple instances.

How It Works

Amazon RDS Read Replicas use the native, asynchronous replication capabilities of the underlying database engine (e.g., MySQL, PostgreSQL, SQL Server). When you create a read replica, RDS first takes a snapshot of your source DB instance and creates a new read-only instance from it. Subsequently, any changes made to the data on the primary database are asynchronously copied to the read replica.

This replication is asynchronous, meaning the primary database does not wait for the replica to acknowledge the change, which ensures that write performance on the primary is not impacted. However, this can result in a small delay known as replication lag, where the data on the replica is slightly behind the primary. Each read replica has its own unique Domain Name System (DNS) endpoint, allowing applications to direct read queries specifically to the replica, thereby reducing the load on the primary instance.

For Amazon Aurora, the architecture is different. Aurora replicas share the same underlying storage volume as the source instance, which avoids the need to copy data and typically reduces replication lag to less than 10 milliseconds.

Key Features and Limits

Supported Engines: Read Replicas are available for Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server.
Number of Replicas: You can create up to 15 read replicas for a single source instance for MySQL, MariaDB, PostgreSQL, and SQL Server. For Oracle, the limit is 5 read replicas. Amazon Aurora supports up to 15 read replicas.
Cross-Region Replication: You can create a read replica in a different AWS Region from the source database. This is a common strategy for disaster recovery (DR) and for reducing latency for users in different geographic locations.
Replica Promotion: A read replica can be promoted to a standalone, writable database instance. This action is irreversible and is often used for disaster recovery or to shard a database. When a replica is promoted, it reboots and its DNS endpoint is retained.
Flexible Configuration: A read replica does not need to have the same instance class or storage type as its primary. This allows you to provision larger instances for replicas that handle intensive analytics queries or smaller instances for less demanding tasks.
Security: Communication between the source and replica instances is secured using public key encryption, even across regions. Replicas of encrypted source databases are also encrypted.
Delayed Replication: For PostgreSQL, you can configure a delayed read replica, which intentionally lags behind the primary by a specified time period. This can be a valuable tool for recovering from human errors, like accidentally dropping a table on the primary.

Common Use Cases

Scaling Read-Heavy Workloads: The most common use case is to offload read traffic from the primary database. Applications like content management systems, e-commerce sites with high product catalog browsing, and social media feeds can direct queries to one or more read replicas to improve performance and responsiveness.
Business Intelligence (BI) and Analytics: Running complex, long-running analytical or reporting queries against a production database can severely impact its performance. By directing these BI workloads to a read replica, you can analyze your data without affecting the primary application's performance.
Disaster Recovery (DR): A cross-region read replica can serve as a standby database. In the event of a regional outage or failure of the primary instance, you can promote the cross-region replica to become the new primary database, enabling business continuity.
Database Engine Upgrades: You can perform a major version upgrade with minimal downtime by first upgrading a read replica, testing it, promoting it to be the new primary, and then redirecting application traffic to it.

Pricing Model

An RDS Read Replica is billed as a standard DB instance, at the same on-demand hourly rate as a standalone instance of the same class and size. There are no additional replication fees for in-region replication.

Key cost factors include:

DB Instance Hours: You pay for the compute capacity (e.g., db.m5.large) of the replica instance for as long as it runs.
Storage: You are billed for the provisioned storage (e.g., General Purpose SSD - gp3) attached to the replica, just like any other DB instance. (Note: Amazon Aurora replicas share storage, so you only pay for the compute capacity, not a separate copy of the data).
Data Transfer: Data transfer for replication within the same AWS Region is free. For cross-region read replicas, you are charged for the data transferred out of the source region to the replica region.

For detailed estimates, use the AWS Pricing Calculator.

Pros and Cons

Pros:

Improved Read Scalability: Effectively distributes read traffic, allowing you to scale beyond the limits of a single instance.
Reduced Primary Load: Offloading read queries frees up the primary instance's resources (CPU, memory, I/O) to handle write traffic more efficiently.
Enhanced Availability/DR: Cross-region replicas provide a manual disaster recovery option.
Flexibility: Replicas can have different instance sizes and storage configurations tailored to specific workloads.

Cons:

Replication Lag: The asynchronous nature means data on the replica can be slightly out of date. Applications must be designed to tolerate this potential staleness.
Not an HA Solution: Unlike Multi-AZ, failover to a read replica is a manual process (promotion) and is not automatic.
Write Endpoint is Unchanged: All write operations must still be directed to the single primary instance.
Cost: You pay for the replica as a full database instance, effectively doubling the instance cost for each replica you add (excluding Aurora).

Comparison with Alternatives

RDS Read Replica vs. RDS Multi-AZ

The most common point of confusion is the difference between a Read Replica and a Multi-AZ deployment. They solve different problems.

You can combine these features. A common best-practice architecture is to have a Multi-AZ primary instance for high availability and then create one or more read replicas from that primary for read scaling.

Exam Relevance

Understanding RDS Read Replicas is critical for several AWS certifications, especially:

AWS Certified Solutions Architect – Associate (SAA-C03)
AWS Certified Database – Specialty (DBS-C01)

Examinees must be able to differentiate between Read Replicas and Multi-AZ deployments. Key topics include knowing when to use each service, understanding the concepts of asynchronous replication and replication lag, the process of promoting a replica, and designing architectures that use read replicas for scaling and disaster recovery.

Frequently Asked Questions

Q: Can I write to a Read Replica?

A: No, RDS Read Replicas are read-only by design. All write operations (INSERT, UPDATE, DELETE) must be sent to the primary source database instance. The replica will then receive these changes via asynchronous replication.

Q: What is the difference between an RDS Read Replica and a Multi-AZ standby instance?

A: A Read Replica is an asynchronous, readable copy of your database used to scale read traffic; failover to it is a manual process called promotion. A Multi-AZ standby is a synchronous, non-readable copy in a different Availability Zone used for high availability; failover to it is automatic and managed by AWS.

Q: How can I reduce or troubleshoot replication lag?

A: Replication lag can be caused by several factors. Common troubleshooting steps include: ensuring the read replica instance class and storage are powerful enough to keep up with the primary's write volume, checking for long-running queries or transactions on the primary that may block replication, and monitoring for network bottlenecks. For workloads highly sensitive to lag, consider using Amazon Aurora, which has a different storage architecture that minimizes lag.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.