RDS read replica cost: scaling reads and what it adds

Quick answer

An RDS read replica is a full, independent instance that asynchronously copies the primary and serves read queries, so each replica costs roughly the same as a primary of that size: its own instance hours plus its own storage. Cross-region replicas add data transfer charges for replication traffic. Read replicas are the right tool for scaling read-heavy workloads, but each one is a full instance cost, so add replicas to match real read load, right-size them, and consider whether caching or a different engine would scale reads more cheaply. Every replica is another instance on the bill.

When a database is bottlenecked on reads, the standard fix is a read replica: an asynchronous copy that takes read traffic off the primary. It works well, and it is important to remember that a replica is not a discount feature, it is a whole additional database instance, priced accordingly. Scaling reads means adding instances, and the bill follows.

What a read replica costs

Component	What you pay
Instance hours	Full instance cost per replica, by size
Storage	Its own copy of the data
Cross-region transfer	Replication traffic between regions

Each read replica runs as an independent instance with its own compute and storage, so a replica of a given size costs roughly what a primary of that size costs. Two replicas roughly triple your database compute (primary plus two). If the replica is in another region, replication traffic incurs cross-region data transfer charges on top. There is no per-replica discount, each is a full instance.

When read replicas are the right call

Read replicas earn their cost when the workload is genuinely read-heavy and the primary cannot keep up: reporting queries, read-scaled APIs, and analytics against the operational database. Offloading reads to replicas protects the primary and scales throughput. They are also useful for serving reads in a region closer to users. The key is that the read load must be real, adding replicas a workload does not need is just extra instances.

Scaling reads without overpaying

Add replicas to match measured read load, not speculatively, and right-size each replica the same way you right-size the primary, a replica does not need to be larger than the read load requires. Before adding replicas, consider whether a cache would absorb the reads more cheaply, since a cache hit avoids the database entirely. And weigh whether Aurora, whose replicas share storage, would scale reads more cost-effectively for your case.

Keeping replica cost in check

Remove replicas that were added for a spike and no longer needed, avoid cross-region replicas unless the latency or disaster-recovery benefit justifies the transfer cost, and reserve steady replicas for commitment discounts just like the primary. Read replicas are distinct from Multi-AZ standbys, which do not serve reads. Price your replica topology against the resource catalog so each added instance is a deliberate, justified cost.

FAQ

How much does an RDS read replica cost?

Roughly the same as a primary instance of that size, because each read replica is a full, independent instance with its own compute hours and its own copy of storage. There is no per-replica discount, so two replicas roughly triple your database compute (primary plus two). Cross-region replicas add data transfer charges for replication traffic on top.

When should I use RDS read replicas?

When the workload is genuinely read-heavy and the primary cannot keep up: reporting queries, read-scaled APIs, and analytics against the operational database. Offloading reads to replicas protects the primary and scales read throughput, and replicas can also serve reads closer to users in another region. The read load must be real, since each replica is a full instance cost.

Do cross-region read replicas cost more?

Yes. In addition to the full instance and storage cost of the replica, cross-region replicas incur data transfer charges for the replication traffic between regions, which can be significant for write-heavy databases. Only use cross-region replicas when the latency benefit of serving reads closer to users, or the disaster-recovery value, justifies that ongoing transfer cost.

How do I scale reads without overpaying for replicas?

Add replicas to match measured read load rather than speculatively, right-size each replica to the read load it serves, and consider whether a cache would absorb the reads more cheaply since a cache hit avoids the database entirely. Remove replicas added for a spike once it passes, and evaluate whether Aurora's shared-storage replicas would scale reads more cost-effectively for your case.

Is a read replica the same as a Multi-AZ standby?

No. A read replica is an asynchronous copy you direct read queries to, for scaling read throughput, and it actively serves traffic. A Multi-AZ standby is a synchronous copy for automatic failover that normally serves no traffic. They solve different problems, read scaling versus availability, and each is a separate cost. Many setups use both.

How does C3X help with read replica cost?

C3X prices your RDS topology, including read replicas, from Terraform before you deploy, so each additional replica instance shows its cost in the pull request. That lets you confirm the read load justifies each replica and right-size them at design time, rather than discovering that a read-scaling change tripled your database compute after it shipped.

What to do next

See the cost of each read replica before you add it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.