Skip to main content
This page explains Amazon RDS cross‑region read replicas: what they are, when to use them, operational characteristics, and important cost and security considerations. Problem statement
  • You run your primary RDS instance in one AWS region (for example, US‑East) because most users are there.
  • As your application grows globally, users from other regions (for example, Africa) access the same primary database, increasing latency and degrading read performance for those distant users.
Solution overview
  • Create a cross‑region read replica in the target region closer to those users.
  • A read replica serves read traffic locally, reducing latency and improving user experience.
  • Read replicas are read‑only copies that receive updates from the primary database asynchronously; they are intended for read scaling and geographic locality—not synchronous, zero‑lag replication.
A slide titled "RDS Cross-Region Read Replicas" showing a stylized map with a database icon in North America connected by a dashed line labeled "AWS Secure communication channel" to a database icon in Africa labeled "Cross-region read replica."
How cross‑region replication works
  • Replication traffic is routed over AWS’s managed backbone. Data in transit is protected (for example, TLS/SSL where applicable).
  • Replication between source and cross‑region replica is asynchronous — occasional replication lag is normal.
  • If the source DB is encrypted at rest, any cross‑region snapshot or replica must also be encrypted. This requires KMS keys in the replica’s region; see AWS KMS documentation for cross‑region key management: https://docs.aws.amazon.com/kms/latest/developerguide/.
Operational characteristics
  • Asynchronous replication: expect eventual consistency for replica reads.
  • Read‑only by default: replicas cannot process writes until promoted to a standalone primary.
  • Promotion: you can promote a read replica to read/write, but promotion changes topology and can result in downtime during switchover.
  • Engine differences: features and cross‑region behaviors vary by engine. For example, Amazon Aurora provides a dedicated Global Database feature optimized for low‑latency global reads: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html.
Cross‑region read replicas are designed to improve read latency and scale reads for geographically distributed users. They are asynchronous and intended for read scaling and geographic locality — not for synchronous cross‑region writes or instant failover.
Cost, security, and operational considerations
ConsiderationImpactRecommendation
Inter‑region data transferReplication traffic incurs AWS inter‑region transfer chargesEstimate ongoing transfer costs before provisioning replicas
Additional compute & storageEach replica is a separate instance with its own hourly and storage costsRight‑size replica instance and storage; consider reserved instances or savings plans
Replication lagAsynchronous replication can cause stale reads on the replicaUse for workloads that tolerate eventual consistency (analytics, reporting, regional reads)
Encryption & KMSCross‑region replicas of encrypted sources require KMS keys in the target regionPlan KMS key replication or use separate KMS keys and adjust snapshot copy operations
Failover behaviorFailover is not automatic to a cross‑region replicaImplement application routing and runbooks for promotion and DNS updates
When to use cross‑region read replicas
Use caseWhy a cross‑region replica helps
Large read‑heavy user base in another regionReduces network latency and improves read performance
Regional analytics or reporting pipelinesOffloads analytics reads from primary and keeps compute local
Geographic locality requirements for readsProvides local read endpoints without running active writes in multiple regions
When not to use them
  • Only a very small portion of traffic is from the remote region — added costs may not justify benefits.
  • Your application requires synchronous, strongly consistent cross‑region writes — cross‑region read replicas cannot provide this.
Promotion and failover
  • You can promote a cross‑region read replica to a standalone read/write instance when needed.
  • Promotion typically requires application cutover (DNS changes, failover testing) and may create a second writable primary; plan for potential downtime and data reconciliation needs.
Alternatives and engine‑specific options
Before creating cross‑region read replicas, evaluate replication lag tolerance, ongoing inter‑region transfer and instance costs, and encryption key requirements in the target region (KMS). For Aurora workloads, consider Aurora Global Database as a lower‑latency alternative.
Links and references Summary
  • Cross‑region read replicas are a practical way to reduce read latency and scale read throughput for geographically distributed users.
  • They are asynchronous and read‑only; plan for replication lag, cross‑region costs, and KMS key management.
  • Choose cross‑region replicas when geographic read locality and read scalability outweigh added cost and operational complexity.

Watch Video