RDS Read Replicas for Scaling

Most applications read data far more often than they write it. Think of a blog: thousands of people read a post for every one person who publishes one. When your single database starts struggling under that read traffic, an RDS read replica lets you create extra copies of your database that handle reads only, taking pressure off the main database. This page explains how read replicas work, when to use them, and the traps that catch people new to cloud databases.

RDS stands for Relational Database Service, Amazon’s managed service for running databases like PostgreSQL, MySQL, and others.

What a read replica is

A read replica is a separate, read-only copy of your main database (called the primary or source). AWS keeps it in sync by continuously copying changes from the primary to the replica. Your application sends all writes (INSERT, UPDATE, DELETE) to the primary, and you can send read queries (SELECT) to the replica instead. This spreads the work across more machines.

The copying is asynchronous. That means a write lands on the primary first, and only a moment later does it reach the replica. That tiny delay is called replica lag (usually milliseconds, but it can grow under heavy load). This single fact drives almost every rule below, so keep it in mind.

You can create up to 15 read replicas for a single primary (for most engines), and replicas can even have their own replicas (cascading), though that adds more lag.

When to use read replicas (and when not to)

Situation	Read replica?	Why
Read-heavy app (reporting, dashboards, search)	Yes	Offloads reads from the primary
Need a copy in another Region for users abroad	Yes (cross-Region)	Lower latency for distant users
You need automatic failover if the primary dies	No, use Multi-AZ	Replicas don’t fail over automatically
Read-after-write flow (user saves, then immediately reads back)	No	Replica lag may show stale data
You need a backup/restore point	No, use snapshots	Replicas aren’t backups

Gotcha: Read replicas scale reads, they do not improve availability. Multi-AZ (Multi Availability Zone) is for availability. Don’t confuse them. We compare them below.

Replicas vs Multi-AZ vs Aurora cluster

These three sound similar but solve different problems.

Feature	Read replica	Multi-AZ instance	Aurora cluster
Main purpose	Scale reads	High availability	Both
Can you read from the standby/replica?	Yes	No (standby is hidden)	Yes (reader endpoint)
Failover	Manual promotion	Automatic	Automatic
Replication	Asynchronous	Synchronous	Shared storage (very low lag)
Separate endpoint to query	Yes	No	Yes

The separate endpoint

This is the part beginners miss. A read replica has its own DNS endpoint (hostname), completely separate from the primary’s endpoint. Your application code must be written to send reads to the replica’s endpoint and writes to the primary’s endpoint. RDS does not automatically split your traffic for you.

For example:

Primary:  mydb.abc123.us-east-1.rds.amazonaws.com
Replica:  mydb-read.def456.us-east-1.rds.amazonaws.com

Most database libraries support configuring two connections. You point your write connection at the primary and your read connection at the replica.

Tip: Aurora is different here. Aurora gives you one single reader endpoint that automatically load-balances across all replicas, so you don’t manage individual hostnames. If you have many replicas, this is much easier.

Creating a read replica

Console steps

1. Open the RDS console and go to Databases.
2. Select your source database instance (the primary).
3. Click Actions, then Create read replica.
4. Give the replica a DB instance identifier, for example mydb-read.
5. Choose the instance class (it can differ from the primary; a replica handling light reads can be smaller and cheaper).
6. To make a cross-Region replica, change the Destination Region to another Region.
7. Review the settings and click Create read replica.

It takes several minutes for the replica to become available, since AWS copies the full dataset first.

CLI equivalent

aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-read \
  --source-db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --region us-east-1

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "mydb-read",
        "DBInstanceClass": "db.t3.medium",
        "Engine": "postgres",
        "DBInstanceStatus": "creating",
        "ReadReplicaSourceDBInstanceIdentifier": "mydb",
        "StorageType": "gp3"
    }
}

Cross-Region replica via CLI

For a replica in another Region, pass the full ARN (Amazon Resource Name, a unique ID for the resource) of the source and set the target Region:

aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-eu-read \
  --source-db-instance-identifier arn:aws:rds:us-east-1:111122223333:db:mydb \
  --db-instance-class db.t3.medium \
  --region eu-west-1

Cross-Region replicas are great for two things: serving read traffic to users physically closer to that Region (lower latency), and disaster recovery (DR) so you keep a live copy far from your primary Region.

Cost note: Each replica is billed as a full extra database instance, plus its own storage. A cross-Region replica also incurs data transfer charges for copying changes between Regions (often a few cents per GB). Two db.t3.medium replicas can easily add 60-90 USD per month. Size replicas to the read load, not by copying the primary’s size out of habit.

Promoting a replica

A read replica can be promoted into a standalone, writable primary database. This breaks replication and the former replica becomes independent. People do this for disaster recovery, or to split a database for a new use case.

Console steps

1. In the RDS console, open Databases and select the replica.
2. Click Actions, then Promote.
3. Configure backup settings, then click Promote read replica.

CLI equivalent

aws rds promote-read-replica \
  --db-instance-identifier mydb-read

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "mydb-read",
        "DBInstanceStatus": "modifying",
        "ReadReplicaSourceDBInstanceIdentifier": null
    }
}

Warning: Promotion is manual for standard RDS read replicas. If your primary fails, a plain read replica will NOT take over automatically. For automatic failover you need Multi-AZ, an Aurora cluster, or a Multi-AZ DB cluster. Don’t rely on a read replica as your high-availability plan.

Watching replica lag

Because replication is asynchronous, monitor the lag so you know how stale your reads might be. RDS publishes a CloudWatch metric called ReplicaLag (in seconds).

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=mydb-read \
  --start-time 2026-06-15T00:00:00Z \
  --end-time 2026-06-15T01:00:00Z \
  --period 300 \
  --statistics Average

Output:

{
    "Label": "ReplicaLag",
    "Datapoints": [
        { "Timestamp": "2026-06-15T00:30:00Z", "Average": 0.8, "Unit": "Seconds" }
    ]
}

Set a CloudWatch alarm if lag climbs above a threshold (say 30 seconds), since high lag means your replica is falling behind and reads are increasingly stale.

Best practices

• Send reads to the replica endpoint and writes to the primary endpoint; never assume RDS splits traffic for you.
• Keep read-after-write flows (e.g. a user saves a profile then views it) pointed at the primary to avoid showing stale data from replica lag.
• Use cross-Region replicas for user locality and disaster recovery, but budget for cross-Region data transfer costs.
• Don’t treat read replicas as a high-availability solution; pair them with Multi-AZ or Aurora for automatic failover.
• Right-size replicas to the read workload instead of matching the primary’s instance class.
• Monitor ReplicaLag in CloudWatch and alarm on it so stale reads never surprise you.
• Prefer Aurora’s single reader endpoint when you run several replicas, to avoid managing many hostnames.

Related Topics

• What is RDS?
• RDS Multi-AZ deployments
• Amazon Aurora
• Create an RDS instance
• ElastiCache