This chapter covers Amazon RDS Read Replicas, focusing on their creation, cross-region deployment, and promotion to standalone instances. Understanding read replicas is critical for the SAA-C03 exam, as they appear in roughly 10-15% of questions related to high availability, disaster recovery, and read scaling. You will learn the internal mechanics of replication, configuration steps, and exam-specific pitfalls that differentiate a correct answer from a common wrong one.
Jump to a section
Imagine a central library (primary RDS instance) with a single original manuscript. Patrons can read it, but if the library is damaged or closed, the manuscript is lost. To protect against this, the library creates photocopies (read replicas) of the manuscript. These copies are exact duplicates and can be used by patrons for reading, but no one can write in them. The copies are stored in different branches (different AZs or regions). The copying process works like this: a librarian continuously monitors the original manuscript for any changes. Whenever a change is made (e.g., a new paragraph is written), the librarian writes that change in a logbook (binary log). Periodically, a messenger takes the logbook to each branch library, and the branch librarian applies the changes to their copy in the exact order they were made. This ensures the copy is eventually consistent with the original. If the original library is destroyed, the head librarian can promote one of the branch copies to become the new original. However, this promotion process is not instantaneous: the branch librarian must first apply all pending log entries, and during promotion, the copy becomes unavailable for reading. Once promoted, the new original can accept writes, but the other copies now point to it. The key point: copies are for read scaling and disaster recovery, not for writing. Writing to a copy would cause divergence, so it is physically blocked.
What RDS Read Replicas Are and Why They Exist
Amazon RDS Read Replicas are asynchronous copies of an RDS database instance that can offload read traffic from the primary instance. They exist to solve two primary problems: scaling read-heavy workloads and improving disaster recovery readiness. In a typical web application, reads often outnumber writes by a factor of 10:1 or more. Without read replicas, the primary instance must handle all queries, leading to CPU saturation, increased latency, and connection limits. By creating read replicas, you distribute SELECT queries across multiple endpoints, reducing load on the primary. Additionally, read replicas can be placed in different AWS regions for cross-region disaster recovery, providing resilience against regional outages.
How It Works Internally
RDS Read Replicas use the database engine's native replication mechanism. For MySQL and MariaDB, this is asynchronous binary log replication. For PostgreSQL, it uses streaming replication. For Oracle, it uses Oracle Active Data Guard. For SQL Server, it uses Always On Availability Groups. The primary instance continuously writes changes to its transaction log (binlog in MySQL, WAL in PostgreSQL). A replication thread on the primary sends these log changes to the replica over an encrypted TLS connection. The replica receives the changes and applies them to its own storage, maintaining an eventually consistent copy.
Key points:
Replication is asynchronous: the primary does not wait for the replica to confirm receipt before committing a write. This means the replica can lag behind the primary by seconds or more under heavy load.
The replica is read-only: you cannot write to a read replica. Any attempt to write (INSERT, UPDATE, DELETE) will fail. This ensures data integrity across replicas.
Replication uses the same storage engine and version compatibility: the replica must be running a compatible database engine version. For cross-region replicas, the replica can be a different instance class than the primary.
Key Components, Values, Defaults, and Timers
Replication Lag: The time delay between a write on the primary and its appearance on the replica. Measured in seconds. RDS CloudWatch metrics: ReplicaLag. Normal values are sub-second to a few seconds. If lag exceeds 5 minutes, RDS may consider the replica unhealthy.
Max Replication Lag: An optional parameter for Multi-AZ DB clusters, but for read replicas, there is no automatic failover based on lag. You must monitor it.
Encryption: If the primary is encrypted with AWS KMS, the replica must also be encrypted, either with the same KMS key (same region) or a different KMS key (cross-region).
Backup Retention: The replica inherits backup settings from the primary, but you can configure separate backup windows for the replica.
Multi-AZ vs Read Replica: Multi-AZ provides synchronous replication for high availability within a region. Read replicas provide asynchronous replication for read scaling and can be cross-region.
Configuration and Verification Commands
To create a read replica using the AWS CLI:
aws rds create-db-instance-read-replica \
--db-instance-identifier mydb-replica \
--source-db-instance-identifier mydb \
--db-instance-class db.r5.large \
--region us-west-2 \
--source-region us-east-1To verify replication status:
aws rds describe-db-instances --db-instance-identifier mydb-replicaLook for StatusInfos with Status: replicating.
Interaction with Related Technologies
Multi-AZ: You can create read replicas from a Multi-AZ primary. The replica is created from the primary, not the standby. If a Multi-AZ failover occurs, the replica continues to replicate from the new primary automatically.
Aurora: Amazon Aurora uses a different replication mechanism. Aurora read replicas (Aurora Replicas) share the same underlying storage volume, so replication is near-instantaneous and there is no replication lag. However, Aurora also supports cross-region replicas using Aurora Global Database.
DMS: You can use AWS Database Migration Service to create a read replica-like setup for heterogeneous migrations, but native RDS replicas are preferred for homogeneous engines.
Promotion to Standalone Instance
Promoting a read replica converts it into a standalone, writable DB instance. This is useful for disaster recovery: if the primary fails, you can promote a replica to become the new primary. The promotion process: 1. The replica stops replication and applies any remaining changes from the log. 2. The replica becomes a full, standalone instance with its own endpoint. 3. The original primary (if still running) is unaffected; it continues as an independent instance. 4. After promotion, the new instance cannot be turned back into a replica; it is permanent.
Important considerations:
Promotion can take from minutes to hours depending on the backlog of changes.
During promotion, the replica is briefly unavailable (a few minutes).
You can promote a replica to a different instance class or storage type, but you must do so after promotion.
For cross-region replicas, the promoted instance remains in the target region.
Limitations and Edge Cases
Replicas cannot be created from a source that has backups disabled (for MySQL, binlog must be enabled).
Maximum of 5 read replicas per primary (some engines allow more, check documentation).
Cross-region replicas incur data transfer costs.
You cannot create a read replica of a read replica (cascading replicas) for most engines; only for MySQL 5.6 and later.
If the primary is in a VPC, the replica must be in the same VPC (same region) or a different VPC (cross-region) with proper peering/VPN.
Create a Read Replica
Navigate to the RDS console, select the primary DB instance, and choose 'Create read replica'. Specify the DB instance identifier, instance class, storage type, and target region if cross-region. Optionally enable Multi-AZ for the replica (not available for all engines). The creation process begins: RDS takes a snapshot of the primary (if no snapshot exists) and uses it to seed the replica. For large databases, this can take hours. Once seeded, replication starts from the point of the snapshot.
Configure Replication Settings
For cross-region replicas, you must enable automatic backups on the primary (backup retention period > 0). The primary's binlog (MySQL) or WAL (PostgreSQL) must be retained long enough for the replica to catch up. Default binlog retention is 1 day. You can adjust it with `rds_set_configuration` for MySQL. For PostgreSQL, WAL retention is managed automatically. Encryption: if the primary uses KMS, you must specify a KMS key for the replica (same region) or a different KMS key (cross-region).
Monitor Replication Lag
Use CloudWatch metric `ReplicaLag` to track delay. A lag of 0 indicates the replica is fully caught up. If lag increases, the replica is falling behind. Common causes: heavy write load on primary, insufficient replica instance size, network latency. Action: scale up the replica or reduce write load. If lag exceeds 5 minutes, consider promoting the replica or troubleshooting network issues. You can also query `SHOW SLAVE STATUS` on MySQL replicas to see `Seconds_Behind_Master`.
Promote the Read Replica
When needed (e.g., primary failure, planned failover), select the replica in the console and choose 'Promote'. RDS stops replication and applies all pending changes. The replica becomes a standalone instance with a new endpoint. The original primary remains unchanged. Promotion is irreversible: you cannot turn the instance back into a replica. After promotion, you can create new read replicas from the promoted instance.
Redirect Application Traffic
After promotion, update your application's database connection string to point to the new primary's endpoint. For disaster recovery, use Route53 DNS failover or application-level retry logic. If using Multi-AZ with read replicas, consider using a custom endpoint (e.g., Amazon RDS Proxy) to abstract the endpoint changes. To minimize downtime, pre-configure the application to connect to a DNS name that you update after promotion.
Scenario 1: E-commerce Platform with Global Read Scaling
A large e-commerce company serves customers worldwide. Their primary RDS MySQL instance is in us-east-1. To reduce latency for users in Europe and Asia, they create read replicas in eu-west-1 and ap-southeast-1. These replicas handle product catalog reads, user reviews, and inventory queries. Write operations (orders, payments) go to the primary. The replicas are configured with the same instance class as the primary (db.r5.4xlarge) to handle peak traffic. CloudWatch alarms monitor replicaLag; if lag exceeds 2 seconds, they scale up the replica or reduce batch jobs. This setup reduces read latency from 200ms to 30ms for European users.
Scenario 2: Disaster Recovery with Cross-Region Replica Promotion
A financial services firm uses RDS PostgreSQL for its transaction database. They maintain a cross-region read replica in us-west-2 from the primary in us-east-1. In the event of a region-wide outage, they promote the replica to a standalone instance. The promotion process takes about 15 minutes for a 500GB database. They use a Route53 failover DNS record with health checks on the primary endpoint. When the primary fails, Route53 automatically routes traffic to the promoted replica's endpoint. They also have a script that updates application configurations to use the new endpoint. After the primary region recovers, they create a new read replica from the promoted instance to restore the cross-region setup.
Common Misconfiguration: Insufficient Replica Capacity
A startup created a read replica with a smaller instance class (db.t3.medium) than the primary (db.r5.large). During a flash sale, write traffic surged, causing replication lag to exceed 30 minutes. The replica could not keep up because its CPU and I/O were saturated. Queries on the replica returned stale data, and some read-heavy features broke. The fix: promote the replica to a larger instance class after the sale, or recreate it with matching capacity. Lesson: always size replicas to handle the read workload plus the write volume from replication.
What the SAA-C03 Tests on This Topic
The exam focuses on (1) when to use read replicas vs Multi-AZ, (2) cross-region replication use cases, (3) promotion behavior, and (4) replication lag implications. Objective 2.3 specifically asks about 'designing resilient architectures' using read replicas for disaster recovery and read scaling.
Common Wrong Answers and Why Candidates Choose Them
'Read replicas can be used for disaster recovery because they are synchronous.' Wrong. Read replicas are asynchronous, so they may lag. Multi-AZ is synchronous. Candidates confuse the two.
'You can write to a read replica to reduce primary load.' Wrong. Read replicas are read-only. Writing would break replication. Candidates think they can split writes.
'Promoting a read replica automatically updates the primary's DNS.' Wrong. Promotion creates a new standalone instance; you must manually update application endpoints.
'Read replicas can be created in the same region only.' Wrong. Cross-region replicas are supported and commonly tested.
Specific Numbers and Terms That Appear on the Exam
Maximum of 5 read replicas per primary (exact number tested).
Replication lag measured in seconds; if lag > 5 minutes, consider action.
Cross-region replicas require automatic backups enabled on primary.
For MySQL, binlog must be enabled.
Promotion is irreversible.
Edge Cases and Exceptions
If the primary is in a VPC, the replica must be in the same VPC (same region) or you need VPC peering.
You cannot create a read replica of a read replica (cascading) for most engines; only MySQL 5.6+ allows it.
Encryption: cross-region replicas require a KMS key in the target region.
Read replicas are not supported for SQL Server with Mirroring or Multi-AZ configurations.
How to Eliminate Wrong Answers
If the question mentions 'synchronous', think Multi-AZ, not read replicas.
If the question asks about 'offloading read traffic', think read replicas.
If the question involves 'cross-region failover', think read replicas + promotion.
If the question mentions 'automatic failover', think Multi-AZ, not read replicas (which require manual promotion).
Read replicas are asynchronous copies used for read scaling and cross-region disaster recovery.
Maximum of 5 read replicas per primary (some engines allow more).
Replicas are read-only; writes are blocked.
Cross-region replicas require automatic backups enabled on the primary.
Promotion is irreversible and creates a standalone writable instance.
Replication lag is measured by CloudWatch metric ReplicaLag; normal is sub-second to seconds.
Multi-AZ provides synchronous replication and automatic failover, not read scaling.
These come up on the exam all the time. Here's how to tell them apart.
Multi-AZ
Synchronous replication (no data loss on failover).
Automatic failover to standby if primary fails.
Only one standby in a different AZ.
Cannot be used for read scaling (standby is not accessible).
No cross-region support.
Read Replicas
Asynchronous replication (potential data loss if primary fails).
Manual promotion required for failover.
Up to 5 replicas per primary.
Can be used for read scaling (serves SELECT queries).
Supports cross-region replication.
Mistake
Read replicas are synchronous and always up-to-date with the primary.
Correct
Read replicas use asynchronous replication. There is always some replication lag, typically milliseconds to seconds. The replica may serve stale data if lag exists.
Mistake
You can write to a read replica to distribute write load.
Correct
Read replicas are read-only. Any write attempt fails. Writes must go to the primary instance only.
Mistake
Promoting a read replica automatically makes it the new primary and updates all connections.
Correct
Promotion creates a standalone instance with a new endpoint. You must manually redirect application traffic to the new endpoint.
Mistake
Read replicas can be created from any RDS instance without prerequisites.
Correct
The primary must have automatic backups enabled (backup retention > 0) and, for MySQL, binary logging must be on.
Mistake
Cross-region read replicas replicate synchronously to avoid data loss.
Correct
All read replicas, including cross-region, use asynchronous replication. Synchronous replication is only available with Multi-AZ (within region).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Multi-AZ provides synchronous replication within a region and automatic failover, ensuring zero data loss. Read replicas are asynchronous and require manual promotion for failover, which may result in data loss. Use Multi-AZ for high availability, read replicas for read scaling and cross-region DR.
For most database engines, cascading read replicas are not supported. However, MySQL 5.6 and later allow creating a read replica from another read replica. Check engine documentation.
Use Amazon CloudWatch metric `ReplicaLag` for the replica instance. For MySQL, you can also query `SHOW SLAVE STATUS` and check `Seconds_Behind_Master`.
The replicas continue to exist and retain their last synchronized state. They will not automatically become the new primary. You must promote one replica to a standalone instance and direct traffic to it.
Yes, you can modify the read replica's instance class, storage, or other settings. However, some modifications require a reboot. For cross-region replicas, modifications are applied in the target region.
If the primary is encrypted, the replica must also be encrypted. For cross-region replicas, you specify a KMS key in the target region. If the primary is not encrypted, the replica can be unencrypted or encrypted (by specifying a KMS key).
Creation time depends on the size of the primary database. RDS takes a snapshot of the primary and restores it to the replica. For a 100GB database, it may take 30-60 minutes. During creation, the primary experiences a brief I/O impact from the snapshot.
You've just covered RDS Read Replicas: Cross-Region and Promotion — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?