RDS MySQL Read Replicas: How They Affect Your RI Strategy

Every RDS MySQL read replica is a regular database instance. It runs, it consumes compute and storage, and it bills at the same hourly rate as any other instance of the same class. The fact that it is a replica — receiving asynchronous writes from a primary — does not change its billing. That means every argument for reserving a primary database applies equally to every read replica you run.

Most teams understand this in principle. The practical confusion happens at three points: how many RIs do you actually need for a fleet with multiple replicas, whether the RI region matters for cross-region replicas, and how to size replicas differently from primaries when the read workload demands it. This guide answers all three.

Do RDS Reserved Instances Cover Read Replicas?

Yes. An RDS RI covers a read replica automatically when four attributes match: database engine, instance family, AWS region, and deployment type. A read replica is always Single-AZ. The RI must also be Single-AZ. A Multi-AZ RI does not cover a read replica regardless of any other attribute match.

From AWS official documentation (docs.aws.amazon.com/AmazonRDS, May 2026): ‘Read replicas are billed as standard DB instances at the same rates as the DB instance class used for the replica.’ The billing system applies RI discounts to any matching running instance automatically — primary, standby (via Multi-AZ RI), or read replica. No configuration required.

The automatic matching means you do not need to tag replicas, create separate reservations specifically for replicas, or do anything differently than you would for a primary. You purchase a Single-AZ db.r8g.xlarge MySQL RI in us-east-1 and it applies to any db.r8g.xlarge MySQL Single-AZ instance in us-east-1 — whether it is a primary, a read replica, or a standalone reporting database.

 

Also read: RDS Reserved Instances: Engine-by-Engine Pricing and Commitment Guide

How Many RIs Do You Need for a Primary Plus Read Replica Fleet?

This is the question most guides skip. The answer is straightforward: one RI per running instance, regardless of whether the instance is a primary or a replica.

Same-Region Replica Fleet

Primary: db.r8g.xlarge MySQL Single-AZ in us-east-1. 3 read replicas: db.r8g.xlarge MySQL Single-AZ in us-east-1. Total instances: 4. Total Single-AZ db.r8g.xlarge MySQL RIs needed in us-east-1: 4. The replicas are not free — they bill at the same rate as the primary and need the same RI coverage to get the same discount.

Annual cost without RI: 4 x $0.478/hr x 8,760 = $16,746.72. Annual cost with 4 x 1-yr No Upfront RIs at $0.320/hr: 4 x $0.320 x 8,760 = $11,212.80. Annual savings from covering the full fleet: $5,534/year. If only the primary was reserved and the 3 replicas ran at on-demand: 1 x $0.320 x 8,760 + 3 x $0.478 x 8,760 = $2,803 + $12,561 = $15,364/year. The team that covered only the primary saved $1,384/year. The team that covered all 4 instances saved $5,534/year — 4x more savings from the same RI strategy applied consistently to replicas.

Fleet Config	Instances	On-Demand Annual	Full Fleet RI Annual	Primary-Only RI	Savings Gap
Primary + 1 replica	2x r8g.xlarge	$8,373	$5,606 (2 RIs)	$6,990 (1 RI)	$1,384/yr left uncovered
Primary + 2 replicas	3x r8g.xlarge	$12,560	$8,409 (3 RIs)	$10,145 (1 RI)	$2,768/yr left uncovered
Primary + 3 replicas	4x r8g.xlarge	$16,747	$11,213 (4 RIs)	$13,329 (1 RI)	$4,152/yr left uncovered
Primary + 4 replicas	5x r8g.xlarge	$20,934	$14,016 (5 RIs)	$16,162 (1 RI)	$5,536/yr left uncovered

db.r8g.xlarge MySQL Single-AZ, US East (N. Virginia), 1-year No Upfront RI at $0.320/hr (verified Vantage.sh May 2026) vs on-demand $0.478/hr. Full fleet RI: all instances reserved. Primary-only RI: only the primary reserved, replicas at on-demand. Savings gap = avoidable on-demand spend from uncovered replicas. Verify at aws.amazon.com/rds/mysql/pricing — rates change.

The savings gap grows linearly with each additional replica. Teams operating 5 replicas behind a reporting workload and reserving only the primary are leaving $5,536/year on the table every year of the term. This is one of the most consistent patterns in under-optimized RDS accounts: RI coverage for the primary, on-demand everywhere else.

 

Also read: RDS MySQL Multi-AZ Reserved Instance: Is the HA Premium Worth It?

The Cross-Region Read Replica RI Trap

This is the specific mistake that costs teams the most money on read replica fleets. It is also the mistake that is easiest to make if you have not read the RI documentation carefully.

How the Trap Works

You have a primary MySQL database in us-east-1. You create a cross-region read replica in eu-west-1 to serve European users with lower latency. You purchase a Single-AZ db.r8g.xlarge MySQL RI in us-east-1 — thinking it will cover both the primary and the replica.

It does not. The RI in us-east-1 covers your primary in us-east-1. Your eu-west-1 replica runs at on-demand rates because there is no matching RI in eu-west-1. AWS does not transfer RI coverage across regions. Each RI is regionally scoped. The region is a hard match requirement — not optional.

Cross-region read replicas require a separate RI in the replica’s region. A db.r8g.xlarge MySQL Single-AZ RI in us-east-1 does not cover a db.r8g.xlarge MySQL Single-AZ replica in eu-west-1. Purchase a separate RI in eu-west-1 to cover the eu-west-1 replica. Source: AWS RDS RI documentation, May 2026.

The Complete Cross-Region Fleet RI Strategy

Primary (us-east-1): 1 Single-AZ db.r8g.xlarge MySQL RI in us-east-1. Same-region replicas (us-east-1): 1 Single-AZ db.r8g.xlarge MySQL RI in us-east-1 per replica. Cross-region replica (eu-west-1): 1 Single-AZ db.r8g.xlarge MySQL RI in eu-west-1. Cross-region replica (ap-southeast-1): 1 Single-AZ db.r8g.xlarge MySQL RI in ap-southeast-1.

Each region requires its own RI purchase. RIs do not share across regions. For a fleet with 1 primary and 5 cross-region replicas in 5 different regions, you need 6 separate RI purchases in 6 separate regions. The effective hourly rate will differ per region because RDS pricing varies by region — verify each region’s rate at the AWS pricing page.

Cross-Region Data Transfer Cost Is Separate from the RI

Cross-region replication generates data transfer charges. AWS does not charge for intra-region replication data transfer between a primary and its read replicas in the same region. For cross-region replicas, standard cross-region data transfer rates apply. Verify current cross-region data transfer rates at aws.amazon.com/ec2/pricing/on-demand (data transfer section) — rates change. These data transfer charges are not reduced by the RI and are separate from the instance compute cost that the RI covers.

Should Read Replicas Be the Same Size as the Primary?

Not always. This is a sizing decision that directly affects your RI purchasing strategy, and getting it wrong in either direction has a cost.

When Replicas Need More RAM Than the Primary

A read replica serving long-running analytical queries needs a larger InnoDB buffer pool than a primary processing fast OLTP transactions. OLTP workloads typically access a small hot working set of rows repeatedly — the buffer pool gets populated quickly and cache hit rates stay high on smaller RAM. Analytical queries scan larger portions of the dataset, requiring more RAM to maintain adequate buffer pool coverage.

If your primary is correctly sized for OLTP at db.r8g.xlarge (32 GB RAM) and a replica serves analytical queries that scan 60 GB of data, the replica needs at least db.r8g.2xlarge (64 GB RAM) to maintain a buffer cache hit ratio above 95%. The RI for the replica must match the replica’s instance class — a db.r8g.xlarge RI does not cover a db.r8g.2xlarge replica (without size flexibility normalization, the xlarge only covers 50% of the 2xlarge).

Formula: purchase 2x db.r8g.xlarge Single-AZ RIs in us-east-1. These 2 reservations (8 normalization units each = 16 total) cover one db.r8g.2xlarge (16 normalization units) via MySQL size flexibility. This is the correct approach for covering a 2xlarge replica with xlarge-equivalent RI commitments.

When Replicas Can Use Smaller Instances Than the Primary

A replica used exclusively for low-concurrency reporting with modest data access patterns — say, a scheduled nightly report that queries 10 GB of data — may run adequately on a smaller instance than the primary. If the primary is db.r8g.2xlarge for a write-heavy production workload, the reporting replica might run fine on db.r8g.xlarge with appropriate query optimization and a scheduled run window.

In this case, reserve the reporting replica at the smaller size with a Single-AZ db.r8g.xlarge RI. Do not reserve it at 2xlarge simply because the primary is 2xlarge. Each instance is reserved at the instance class it actually runs on.

How to Assess Replica-Specific Sizing

Pull CloudWatch metrics specifically for each replica, not just the primary. BufferCacheHitRatio, CPUUtilization, DatabaseConnections, and ReplicaLag are the four key metrics. A replica with BufferCacheHitRatio below 95% is undersized. A replica with CPUUtilization consistently below 20% at P90 and FreeableMemory above 25% of total RAM is oversized. Right-size the replica based on its own workload pattern before purchasing any RI for it.

For the complete MySQL instance sizing methodology

Does Replication Lag Affect Whether You Should Reserve a Read Replica?

This is a question no RI guide for read replicas asks — and it matters more than most FinOps engineers realize.

A read replica exists to serve read traffic. If replication lag is so high that the replica is serving data that is hours or days behind the primary, the replica’s value to your application depends entirely on whether stale data is acceptable. For some workloads (historical reporting, batch analytics on yesterday’s data), high lag is tolerable. For others (user-facing reads where stale data causes UI inconsistencies), any significant lag makes the replica unusable for its intended purpose.

Replication Lag Signals That Affect RI ROI

Chronic lag above 60 seconds: the replica is falling behind on every business day and never fully catches up. The underlying cause is usually single-threaded replication not keeping pace with the primary’s write volume. Root cause: enable parallel replication via the replica-parallel-workers parameter (available in MySQL 5.7+ and MySQL 8.0+). If lag cannot be resolved, the replica’s application value is limited.

Lag caused by write-heavy analytics on the replica: if the replica is running analytics queries that touch tables with indexes, MySQL replication holds while those index updates propagate. This is a workload configuration issue, not an instance size issue. Separate the analytics from the RI by scheduling analytics queries during low-write periods on the primary or using read_only mode on the replica to prevent accidental writes.

The RI consideration: if a replica is chronically lagged and you have not resolved the root cause, you are reserving a database that may not be delivering its intended value. Investigate and resolve replication lag before purchasing a long-term RI on an under-performing replica. A 1-year commitment on an instance you will decommission or replace when you finally fix the lag architecture is avoidable waste.

ReplicaLag CloudWatch metric: monitors Seconds_Behind_Master in MySQL. A production read replica should maintain lag below 10 seconds during normal operation. Lag above 60 seconds during peak traffic indicates parallel replication is not configured or the replica instance is undersized for its write application rate. Source: AWS RDS documentation (docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Monitoring.html).

What Happens to the RI When You Promote a Read Replica?

Promoting a read replica to a standalone read/write instance is a common disaster recovery action. Understanding what happens to your RI when you do this prevents a billing surprise.

The Promotion Process

When you promote a read replica, it becomes a standalone DB instance that accepts both reads and writes. It is no longer a replica — it no longer receives updates from a source. It is now an independent database. From AWS’s perspective, it is still a db.r8g.xlarge MySQL Single-AZ instance in the same region. The RI that was covering it as a replica continues covering it as a promoted standalone instance. Nothing about the RI changes.

The promoted instance’s Single-AZ RI coverage persists unchanged through the promotion. You do not need to purchase a new RI or modify the existing one. The instance attributes (engine, family, region, deployment type) remain the same.

The DR Scenario and the RI Planning Implication

Common DR scenario: your primary fails. You promote the read replica to be the new primary. Now you have a standalone instance (the promoted replica) without a primary. If you launch a new primary to replace the failed one, you will have two instances running where before you had a primary plus a replica. Your RI configuration was: primary RI (on-demand if you were lazy) + Single-AZ RI for the replica. After promotion: the Single-AZ RI now covers the promoted instance (acting as new primary). The replacement primary you launch has no RI unless you purchase one.

The implication: plan your RI inventory with DR scenarios in mind. If your architecture involves promoting replicas to standalone during failures, ensure you have RIs covering the replacement instances you would launch after a promotion event. This is an argument for reserving both the primary and the replicas: in a DR scenario, the full fleet is covered at the RI rate regardless of which instance is promoted.

What Is NOT Covered by RIs on Read Replicas?

The same exclusions that apply to primary RDS instances apply to read replicas. Understanding these prevents over-estimating the cost savings from reserving replicas.

T3 and T4g Burstable Instance CPU Credit Charges

If you run read replicas on db.t3 or db.t4g instances (Unlimited CPU credit mode by default), and those replicas sustain CPU above the baseline level, the excess CPU credit charges are not covered by the RI. The RI covers the hourly compute rate. The excess CPU credits are billed separately at $0.075/vCPU-hr (T4g) or $0.05/vCPU-hr (T3).

A reporting replica on db.t4g.large running heavy scans during a nightly batch will accumulate CPU credit charges on top of the RI cost. For replicas with sustained high CPU workloads, use a non-burstable instance family (r8g, m7g) rather than t-family instances, regardless of the upfront cost difference.

Storage Costs

Every read replica has its own EBS storage volume. Storage is billed independently from the compute RI. A replica running gp3 storage at $0.115/GB-month incurs that storage cost even if the compute is fully covered by an RI. For replicas with large storage requirements (multi-TB analytical datasets), storage can represent a significant portion of the total replica cost that the RI does not address.

Cross-Region Data Transfer

Data transfer between the primary and a cross-region replica is charged at standard cross-region rates. This charge is not covered by any RI. For a primary processing 100 GB of writes per day, the cross-region replication traffic is approximately 100 GB/day x 30 days = 3 TB/month of data transfer. At standard cross-region rates (verify at aws.amazon.com/ec2/pricing/on-demand), this can add significant cost on top of the replica’s compute RI.

Extended Support

MySQL 5.7 and PostgreSQL 11 in Extended Support ($0.200/vCPU-hr since March 2026) incur this surcharge on every running instance including read replicas. A read replica on MySQL 5.7 with 4 vCPUs incurs $584/month in Extended Support charges that the RI does not reduce. A fleet of 5 MySQL 5.7 read replicas (4 vCPUs each) in Extended Support pays $2,920/month in Extended Support charges regardless of RI coverage. Upgrade the engine version first.

 

Also read: How to Save on RDS Reserved Instances: A Quick Guide

The Complete RI Purchase Checklist for MySQL Read Replica Fleets

Before purchasing any RI for a MySQL fleet that includes read replicas, work through this sequence:

1. Identify all running MySQL instances: use the CLI to get a complete instance list including replicas. aws rds describe-db-instances –query ‘DBInstances[*].[DBInstanceIdentifier,DBInstanceClass,MultiAZ,ReadReplicaSourceDBInstanceIdentifier,AvailabilityZone,DBInstanceStatus]’ –output table
2. Check engine version: identify any MySQL 5.7 or PostgreSQL 11 instances. Upgrade before reserving. Extended Support charges on replicas dwarf RI savings on the same instances.
3. Classify each instance: primary (read/write), read replica (read-only), or standalone. Note the region for each. Group by instance class and region.
4. Assess replica sizing: pull 30 days of CloudWatch metrics for each replica. BufferCacheHitRatio, CPUUtilization, and FreeableMemory determine whether the replica is correctly sized. Do not reserve an incorrectly-sized replica.
5. Check ReplicaLag: replicas with chronic high lag that have not been addressed are poor RI candidates. Resolve the replication architecture before committing to a multi-year term on an underperforming instance.
6. Purchase Single-AZ RIs: one per instance, in the same region as each instance. Cross-region replicas require separate RIs in their respective regions.
7. Verify coverage post-purchase: in Cost Explorer, check the RI utilization report within 48 hours of purchase. All target instances should show 100% utilization. Any instance at 0% utilization indicates a mismatch in engine, family, region, or deployment type.

How Usage.ai Handles Read Replica RI Optimization

Most RI management tools focus on primary database instances. Usage.ai Flex Reserved Instances analyzes the full MySQL fleet — primaries and replicas separately — with the same 24-hour utilization refresh cycle. The platform identifies read replica instances by region, classifies them as Single-AZ, and includes them in the RI recommendation and purchase workflow.

For teams with cross-region read replicas, Usage.ai identifies the replica region and generates separate RI recommendations for each region — not just the primary’s region. The platform surfaces the cross-region RI gap explicitly: if a replica in eu-west-1 is running at on-demand rates while an RI exists in us-east-1 that was intended to cover it, the discrepancy is flagged with the exact monthly cost of the mismatch.

For replica sizing issues, Usage.ai flags instances where BufferCacheHitRatio is below 95% as under-memory-provisioned before recommending any RI purchase. Recommending an RI on an undersized replica would lock in the suboptimal sizing for the full term. The right-sizing flag prompts the team to resolve the instance size before committing.

If any RI covering a read replica becomes underutilized because the replica is promoted, deleted, or resized, Usage.ai provides cashback in real money on the unused portion. Fee: percentage of realized savings only.

See how Usage.ai analyzes your full RDS MySQL fleet including read replicas

 

 

Frequently Asked Questions

1. Do RDS reserved instances cover read replicas?

Yes. An RI covers a read replica automatically when engine (MySQL), instance family, region, and deployment type (Single-AZ) all match. Read replicas are always Single-AZ — a Multi-AZ RI will never cover a read replica. The RI discount applies without any configuration. You do not tag replicas or assign RIs to specific instances. Source: docs.aws.amazon.com/AmazonRDS, May 2026.

 

2. How many RIs do I need for a primary plus 3 read replicas?

Four Single-AZ RIs in the same region and instance family as the instances. One for the primary, one for each replica. Each instance bills independently. For db.r8g.xlarge MySQL Single-AZ (verified $0.320/hr 1-yr No Upfront RI): 4 RIs = $11,213/year versus $16,747/year on-demand for all 4 instances. Reserving only the primary saves $1,384/year. Reserving all 4 saves $5,534/year.

 

3. Does a cross-region read replica need its own RI in a different region?

Yes. An RI is regionally scoped and covers only instances in its purchased region. A db.r8g.xlarge Single-AZ RI in us-east-1 does not cover a db.r8g.xlarge Single-AZ read replica in eu-west-1. Purchase a separate db.r8g.xlarge Single-AZ RI in eu-west-1 to cover the cross-region replica. Cross-region pricing may differ from us-east-1 — verify at aws.amazon.com/rds/mysql/pricing.

 

4. Are read replicas always Single-AZ?

Yes. Read replicas are always Single-AZ. They do not have a synchronous standby like a Multi-AZ primary. A read replica can have its own Multi-AZ configuration for HA (enabling Multi-AZ on the replica creates a standby for the replica itself), but this is rare and each node would then be billed at Multi-AZ rates. In standard configurations, treat every read replica as a Single-AZ instance for RI purchasing purposes.

 

5. What happens to the RI when I promote a read replica?

The RI continues covering the promoted instance unchanged. Promotion converts the replica to a standalone read/write instance, but the instance attributes (engine, family, region, Single-AZ deployment type) remain the same. The RI discount continues applying through the rest of the term. No modification to the RI is required after promotion.

 

6. Does replica lag affect whether I should reserve a read replica?

Yes, indirectly. A replica with chronic high replication lag (hours, not seconds) may not be delivering its intended read offloading value. Before purchasing a 1-year RI on a lagging replica, investigate and resolve the root cause (enable parallel replication via replica-parallel-workers, check for analytics queries on indexed tables). Reserve only instances that are functioning correctly and have a confirmed business purpose.

 

7. What does data replication between primary and replica cost?

Within the same AWS region: free. AWS does not charge for data transfer between a primary RDS instance and its read replicas in the same region. Source: docs.aws.amazon.com/AmazonRDS. For cross-region replicas: standard cross-region data transfer rates apply and are not covered by any RI. Verify current cross-region data transfer rates at aws.amazon.com/ec2/pricing/on-demand — rates change.

 

8. How do I check if my RI is covering my read replicas?

In AWS Cost Explorer, navigate to Reservations > Utilization Report. Filter by Amazon RDS. Any instance at less than 100% RI utilization should be investigated. Alternatively, check the RI coverage report: filter by RDS service and look for any running instances with low or zero RI coverage. Instances showing 0% RI coverage that you expected to be covered indicate a region, family, engine, or deployment type mismatch.