Cross-Region Read Replicas on RDS: Cost and Lag Tradeoffs

Problem statement: You want a read replica in another AWS region — for regional read locality, disaster recovery, or both — and you need to know two numbers before you provision it: how much lag the WAN imposes as a hard floor, and how much the inter-region WAL transfer will cost you every month.

Symptom Identification

Cross-region replicas earn their cost only for specific problems. You have one of them if:

  • Users in a distant region see read latencies dominated by the round trip to your primary region — a European read hitting a US primary pays ~80–100 ms per query just in transit.
  • Your disaster-recovery plan requires a warm database in a second region with a recovery point close to zero.
  • Compliance requires a queryable copy of data physically resident in a particular jurisdiction.

And you are about to make an expensive mistake if:

  • You are reaching for a cross-region replica to cut lag, when a same-region replica would serve the same reads far faster and free.
  • Your database is write-heavy and you have not modeled the recurring inter-region transfer bill.

Root Cause Analysis

Two independent costs make cross-region replicas fundamentally different from same-region ones, and both are structural — neither tunes away.

The lag floor is the WAN. A cross-region RDS replica cannot replay a WAL record until that record has physically crossed the network between regions. The minimum achievable ReplicaLag is therefore approximately the one-way inter-region latency plus apply time. For adjacent regions that is tens of milliseconds; for intercontinental pairs it is commonly 150–300 ms in steady state and climbs under write bursts as the WAL sender competes with the WAN for bandwidth. No parameter, instance class, or apply-parallelism setting moves this floor — it is set by geography. This is the concrete, single-hop instance of the WAN RTT floor described in designing multi-region read replica topologies.

The cost is the WAL egress. AWS bills inter-region data transfer per GB for the WAL stream shipped from the source region to the replica’s region. Critically, that cost scales with your write volume, not your read volume — a database that writes 500 GB of WAL a month pays for 500 GB of egress whether the replica serves one query or a million. A write-heavy database can spend more on cross-region transfer than on the replica instance itself.

The physical-streaming, independent-storage nature of RDS replicas — the same property that distinguishes them from Aurora shared-storage readers in the read-scaling comparison — is exactly what makes cross-region replication possible, because each replica owns its own storage in its own region.

Architecture: The WAN Floor and the Transfer Meter

Cross-region RDS replica WAN lag floor and transfer cost Region A holds the source instance and its writers. A WAL stream crosses the WAN, metered per GB, to Region B where a cross-region replica replays it. Region B readers query the local replica cheaply while replica lag is floored by the WAN round trip. Region A (source) Source DB WAL sender local writers Region B (replica) X-region replica local readers WAL stream over WAN metered per GB egress lag floor ≈ one-way RTT + apply cost scales with write volume, not reads Region B reads stay local — the WAN cost is paid once, on the stream

Cost and Lag Reference Table

Representative figures for planning. Treat network latencies as typical steady-state values and transfer as billed per GB of WAL egressed from the source region.

Region pair (example) Typical one-way latency Realistic lag floor Relative transfer cost
Same region, cross-AZ ~1–2 ms Tens of ms None (in-region)
Adjacent regions (e.g. us-east ↔ us-west) ~30–40 ms ~60–90 ms Per-GB inter-region
Transatlantic (us-east ↔ eu-west) ~40–50 ms ~90–150 ms Per-GB inter-region
Transpacific / intercontinental ~80–150 ms ~150–300 ms Per-GB inter-region

The monthly transfer cost is straightforward to model:

text
monthly_transfer_cost ≈ monthly_WAL_GB × inter_region_rate_per_GB

For a database generating 500 GB of WAL per month at a per-GB inter-region rate, the recurring transfer bill alone runs into the tens of dollars per month before the replica instance cost — and it scales linearly with write throughput. Enable wal_compression on the source (via parameter group) to shrink the streamed volume and directly reduce this bill.

Step-by-Step Resolution

Step 1: Measure the WAN floor before committing

bash
# Rough one-way latency proxy between regions (from an instance in each)
ping -c 20 <destination-region-endpoint> | tail -1

Inline verification: Halve the reported RTT for a one-way estimate; your steady-state ReplicaLag will not go below that plus apply time. If that floor breaks a read-freshness SLA, a cross-region replica cannot meet it — revisit the requirement.

Step 2: Provision the cross-region replica

bash
# Create the replica in the destination region, referencing the source ARN
aws rds create-db-instance-read-replica \
  --region eu-west-1 \
  --db-instance-identifier appdb-eu-replica \
  --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:appdb-primary \
  --db-instance-class db.r6g.xlarge

Inline verification: aws rds describe-db-instances --region eu-west-1 shows the replica reaching available with ReadReplicaSourceDBInstanceIdentifier pointing at the cross-region source ARN.

Step 3: Enable WAL compression to cut transfer cost

bash
aws rds modify-db-parameter-group \
  --db-parameter-group-name appdb-source-params \
  --parameters "ParameterName=wal_compression,ParameterValue=on,ApplyMethod=immediate"

Inline verification: After the change, the source’s TransmitThroughput/WAL egress metric should drop for the same write workload.

Step 4: Monitor ReplicaLag per region with a WAN-aware threshold

bash
aws cloudwatch put-metric-alarm \
  --region eu-west-1 \
  --alarm-name "appdb-eu-replica-lag" \
  --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=appdb-eu-replica \
  --statistic Average --period 60 --evaluation-periods 3 \
  --threshold 5 --comparison-operator GreaterThanThreshold

Inline verification: Set the threshold above the WAN floor so normal transatlantic lag does not page you — alert on lag that exceeds floor-plus-margin, not on the floor itself. Feed this into the broader stack in detecting and handling replication lag in real time.

Configuration Snippet

Route regional reads to the local replica and keep freshness-sensitive reads honest about the WAN floor, using freshness-based routing:

yaml
# Region-aware read routing (see freshness-based routing guide)
regions:
  eu-west-1:
    reader_endpoint: "appdb-eu-replica.xxxx.eu-west-1.rds.amazonaws.com"
    max_replication_lag_ms: 400     # above the transatlantic floor
    on_lag_exceeded: route_to_source_region

For the decision tree behind these freshness thresholds, see routing queries based on data freshness requirements.

Verification and Rollback

sql
-- On the cross-region replica
SELECT pg_is_in_recovery();        -- t
SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_s;

Promotion for DR (the intended “rollback” of a regional outage):

bash
# Promote the cross-region replica to a standalone writer in the surviving region
aws rds promote-read-replica --region eu-west-1 \
  --db-instance-identifier appdb-eu-replica

After promotion, pg_is_in_recovery() returns f, replication is permanently broken, and you must re-point regional writes and rebuild replicas. Any WAL still in flight across the WAN at outage time is lost — this is the recovery-point cost of asynchronous cross-region replication.

To back out a cross-region replica you no longer want: delete it in the destination region; this stops the WAL stream and ends the transfer charges immediately. The source is unaffected.

Edge Cases and Gotchas

The transfer bill surprises write-heavy databases

Because transfer scales with WAL volume, a database with heavy background writes (bulk imports, large UPDATE batches, high-churn tables) can generate far more egress than its read traffic would suggest. Model the bill against WAL bytes, not query counts, and revisit it whenever write volume grows. wal_compression and reducing write amplification on the source are the two levers that actually lower it.

Cascading a cross-region replica compounds the floor

An RDS replica-of-a-replica placed a further hop away adds a second WAN crossing, stacking latency floors. A read served from a third-region cascade can be a full RTT behind a second-region replica that is already a full RTT behind the source. Keep cross-region topologies shallow, and design them deliberately per designing multi-region read replica topologies.

Promotion is not a load-balancing event

Promoting a cross-region replica is a one-way, permanent break of replication — not a graceful failover you can undo. Never promote to shed read load; promote only for disaster recovery or a planned regional migration, and rehearse the re-pointing and rebuild steps before you need them under pressure.

FAQ

What is the minimum lag I can expect from a cross-region RDS replica?

The floor is roughly the one-way network latency between the two regions plus apply time, because WAL must physically cross the WAN before the replica can replay it. For a nearby pair that is tens of milliseconds; for an intercontinental pair it is often 150 to 300 milliseconds even in perfect conditions, and it rises under write bursts. You cannot tune below the speed of light.

How is cross-region replica data-transfer billed?

AWS charges inter-region data transfer for the WAL stream shipped from the source region to the replica’s region, billed per GB egressed. Your monthly cost scales with write volume, not read volume, so a write-heavy database with a cross-region replica can incur substantial recurring transfer charges independent of how much the replica is read.

Can I promote a cross-region replica during a regional outage?

Yes. Promoting a cross-region read replica turns it into a standalone writable instance in the surviving region, which is the core of an RDS disaster-recovery strategy. Promotion is not instant and breaks replication permanently, so you must re-point writes and rebuild replicas afterward. Rehearse it, because any writes still in flight across the WAN at outage time are lost.

← Back to Managed vs Self-Managed Read Replicas