Amazon RDS Read Replicas: Creation, Cross-Region DR, and Promotion – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon RDS read replicas provide read scaling and can support disaster recovery designs. This lesson demonstrates creating a MySQL read replica in another AWS Region, identifying its endpoint, promoting it to an independent read/write database, and cleaning up the resources afterward.

The most important architectural distinction is that a read replica is not the same as a Multi-AZ standby. A read replica is intended for read traffic and can be promoted, while Multi-AZ primarily provides synchronous standby failover for availability.

Key Concepts

What an RDS read replica provides

An RDS read replica is a separate DB instance that receives replicated changes from a source DB instance. Applications can send read-only queries to the replica using its own endpoint.

Common uses include:

Scaling read-heavy workloads.
Isolating reporting or analytics queries from the primary database.
Creating a database copy in another Availability Zone or Region.
Supporting disaster recovery when the replica is deployed in a separate Region.
Performing a planned migration or database cutover by promoting the replica.

Replication is asynchronous. A replica can therefore lag behind the source, especially during periods of high write activity or insufficient replica capacity. A design that requires zero data loss must account for this limitation.

Read replica versus Multi-AZ deployment

Capability	RDS Read Replica	RDS Multi-AZ deployment
Primary purpose	Read scaling and replication-based recovery	High availability and automatic failover
Replication model	Asynchronous	Synchronous standby replication for supported configurations
Read traffic	Applications can use the replica endpoint for reads	Standby is generally not used for read traffic
Failover	Requires manual promotion or application cutover	RDS can fail over automatically
Write capability	Replica is read-only until promoted	Primary remains the writer; standby takes over after failover
Typical scope	Same Region or cross-Region, depending on engine and configuration	Typically designed within a Region across Availability Zones

A read replica does not automatically replace Multi-AZ high availability. Conversely, Multi-AZ does not normally provide additional read capacity.

Creating a replica

From the Amazon RDS console, select the source DB instance and choose the action to create a read replica. The configuration includes:

The source DB instance.
The destination Region, if creating a cross-Region replica.
A unique DB instance identifier.
Instance class and storage settings.
Network connectivity, including VPC and security group choices.
Database port and other engine settings.

Creation is asynchronous and can take several minutes. The replica transitions through a provisioning or modifying state before becoming available.

Replica endpoints

The replica has its own DNS endpoint. An application that should use the replica for reads must connect to that endpoint rather than the source DB endpoint.

A production application commonly implements read/write routing, for example:

Send INSERT, UPDATE, and DELETE operations to the primary endpoint.
Send eligible SELECT operations to the read-replica endpoint.
Handle replica lag when recently written data must be read immediately.
Change connection configuration during a promotion or disaster recovery event.

Creating a replica alone does not redirect application traffic.

Cross-Region read replicas

A cross-Region replica can provide a recovery target if the primary Region becomes unavailable. It may also support geographically distributed read traffic, subject to latency, data consistency, networking, and cost considerations.

During a regional disaster, the replica can be promoted. Promotion converts it into an independent DB instance that supports both reads and writes. Promotion breaks its replication relationship with the original source, so it is a recovery or migration action rather than a normal method of restoring read scaling.

Cross-Region replication can involve additional considerations:

Inter-Region data transfer charges.
Replication lag and possible data loss during an unplanned regional failure.
DNS, application configuration, and secret changes during cutover.
VPC connectivity and security group configuration in the destination Region.
Backup and recovery requirements for the promoted database.

Encryption behavior

The replica’s encryption configuration is tied to the source and replica creation rules. Encryption is not an arbitrary setting that can always be changed in the read-replica creation workflow. Verify the source encryption state and the engine’s supported rules before designing the replication path.

For an unencrypted source, do not assume that creating a read replica automatically provides encryption at rest. If encryption is required, plan an appropriate migration or snapshot-based process according to the engine and RDS capabilities.

Promotion workflow

Promotion is appropriate when the replica must become an independent database, such as during:

Disaster recovery.
A planned regional migration.
A database scaling or migration operation.
A controlled cutover to a new database instance.

Before promotion, confirm that the replica has received the required transactions. Promotion is disruptive: the replica is rebooted or otherwise modified, replication stops, and the database becomes writable after the operation completes.

After promotion, update dependent systems, including:

Application connection strings.
DNS records or service discovery entries.
Secrets and configuration stores.
Monitoring and alerting targets.
Backup policies.
Security group rules, if the access pattern changes.

Exam-Relevant Takeaways

Use an RDS read replica to scale read traffic or create a replication-based recovery target.
Read replicas use asynchronous replication, so replica lag and potential data loss must be considered.
A cross-Region read replica can support disaster recovery, but it does not provide automatic regional failover by itself.
Promoting a read replica makes it an independent read/write DB instance and terminates replication from the original source.
A replica has its own endpoint; applications must be explicitly configured to use it.
Multi-AZ and read replicas solve different problems: Multi-AZ targets availability and failover, while read replicas target read scaling and recovery flexibility.
Promotion does not automatically reconfigure applications, DNS, secrets, or dependent services.
Database encryption, backup retention, network placement, and security group settings must be designed before creating the replica.
A small or development-sized DB instance may be suitable for a lab but not for production read throughput or recovery objectives.

Architecture Decision Guide

Requirement	Preferred approach	Important qualification
Automatic failover for a regional database failure	Multi-AZ for in-Region failures; a cross-Region DR design for regional failures	A cross-Region read replica normally requires manual promotion and application cutover
More capacity for read-heavy queries	RDS read replica or replicas	Route reads explicitly and monitor replica lag
Offload reporting queries	Read replica	Reporting queries can still overwhelm an undersized replica
Recovery copy in another Region	Cross-Region read replica	Consider asynchronous lag, transfer cost, and recovery automation
Zero or near-zero data loss requirement	Evaluate synchronous or purpose-built HA/DR options	An asynchronous read replica cannot guarantee zero data loss
New writable database from a replica	Promote the read replica	Replication stops and the application must be redirected
Transparent database failover with minimal application changes	Multi-AZ or an appropriate managed failover architecture	Read replicas do not automatically assume the primary endpoint

Common Exam Traps

Treating a read replica as a standby: A read replica is not automatically a Multi-AZ failover target.
Assuming replication is synchronous: RDS read replicas are asynchronous, so lag is possible.
Expecting automatic failover across Regions: A cross-Region replica does not automatically promote itself and reconfigure the application.
Sending writes to a normal replica: Before promotion, the replica is intended for read access.
Forgetting the endpoint change: The replica has its own endpoint, and promotion does not magically update application connection settings.
Ignoring data freshness: A read immediately after a write may return stale data if it is sent to a lagging replica.
Assuming promotion preserves replication: Promotion breaks the source-replica relationship.
Using the wrong solution for read scaling: Multi-AZ improves availability but is not generally a read-scaling mechanism.
Assuming encryption can be changed freely during replica creation: Validate encryption compatibility and plan conversions explicitly.
Confusing DB instance size with feature purpose: A small instance may support a lab but does not establish production performance or recovery capacity.

Real-World Engineer Notes

Monitor replica lag and define an application policy for reads that require read-after-write consistency.
Use separate connection pools for primary writes and replica reads where appropriate.
Test promotion regularly. A recovery design is incomplete if DNS, secrets, IAM permissions, security groups, and application startup behavior have not been validated.
Document the recovery point objective. Asynchronous replication means the promoted database may not contain the most recent committed transactions from the primary.
Keep the promoted database protected with automated backups and an appropriate retention period.
Use least-privilege security groups. The replica should accept database traffic only from approved application or administrative sources.
For cross-Region designs, account for network transfer, database engine limitations, regional service availability, and the operational process for returning to the preferred Region.
After a lab, delete unused replicas and decide whether final snapshots or retained automated backups are required. In production, deletion protection and recovery requirements should be reviewed before removal.

Quick Reference Summary

Read replica: Separate, read-focused DB instance receiving asynchronous changes from a source.
Endpoint: Each replica has its own endpoint; applications must use it explicitly.
Cross-Region replica: Useful for regional reads or disaster recovery, but incurs operational and transfer considerations.
Promotion: Converts the replica into an independent read/write database and stops replication.
Multi-AZ: Primarily an availability and failover feature, not a read-scaling feature.
Main risks: Replica lag, stale reads, manual cutover, application reconfiguration, and possible data loss during an unplanned failure.

Flashcards

Q: What is the primary purpose of an Amazon RDS read replica?

A: To scale read workloads, isolate read-heavy operations, or provide a replication-based recovery target.

Q: Is RDS read-replica replication synchronous or asynchronous?

A: Asynchronous.

Q: Can applications read from an RDS read replica?

A: Yes. They connect to the replica’s separate endpoint.

Q: Can a normal RDS read replica accept writes?

A: No. It must first be promoted to become an independent writable database.

Q: What happens when a read replica is promoted?

A: It becomes an independent read/write DB instance, and replication from the original source stops.

Q: Why deploy an RDS read replica in another Region?

A: To support cross-Region reads or provide a recovery target for a regional disaster.

Q: Does a cross-Region read replica automatically fail over?

A: No. Promotion and application cutover generally require an operational process or automation.

Q: How does Multi-AZ differ from a read replica?

A: Multi-AZ primarily provides high availability and failover, while read replicas provide read scaling and asynchronous replication.

Q: What consistency issue can occur when using read replicas?

A: Replica lag can cause a read to return data that has not yet been replicated.

Q: What must an application do to use a replica for reads?

A: Route eligible read queries to the replica’s endpoint.

Q: What should be evaluated before promoting a replica during DR?

A: Replication lag, required transaction completeness, backup status, connectivity, and the application cutover process.

Q: What happens to the original replication relationship after promotion?

A: It is terminated; the promoted database operates independently.

Practice Questions

Question 1

A company runs an RDS for MySQL database in us-east-1. Reporting queries are consuming resources on the production writer. The company wants to offload reports while accepting eventual consistency. Which solution is most appropriate?

A. Enable Multi-AZ and send reports to the standby instance.
B. Create an RDS read replica and direct reporting connections to its endpoint.
C. Promote the production database’s standby and use it for reports.
D. Export all production data to Amazon S3 before every report.

Correct answer: B

Explanation: An RDS read replica is designed to offload read workloads. Multi-AZ standby instances are for availability and are not normally used as read endpoints. Promotion would stop replication and is unnecessary for this requirement.

Question 2

A workload requires recovery from a complete outage of its primary AWS Region. The business accepts a small amount of data loss but requires the recovery process to be documented and tested. Which design best fits the requirement?

A. Deploy a cross-Region RDS read replica and promote it during regional recovery.
B. Deploy Multi-AZ only in the primary Region.
C. Use an RDS read replica in the same Availability Zone as the primary and rely on automatic failover.
D. Increase the primary DB instance size.

Correct answer: A

Explanation: A cross-Region read replica provides a recovery copy outside the primary Region. Because replication is asynchronous, some data loss is possible, and promotion plus application redirection must be part of the DR runbook. Multi-AZ alone does not protect against a regional outage.

Question 3

An application writes a customer record to the RDS primary and immediately reads it through a read-replica endpoint. Occasionally, the record is missing from the response. What is the most likely cause?

A. The replica is encrypted.
B. The replica endpoint supports writes only.
C. Asynchronous replication lag caused a stale read.
D. Multi-AZ automatically rejected the read.

Correct answer: C

Explanation: Read replicas replicate asynchronously. A read sent to a replica immediately after a write to the primary may occur before the change reaches the replica. The application should use the primary for read-after-write operations or implement an appropriate consistency strategy.

Question 4

A cross-Region RDS read replica is promoted during a disaster. Which additional action is required for the application to use the promoted database?

A. Nothing; the original primary endpoint automatically resolves to the promoted database.
B. Update the application’s connection configuration, DNS, or service-discovery target.
C. Re-enable Multi-AZ on the original primary before any application changes.
D. Convert the promoted database back into a read replica.

Correct answer: B

Explanation: Promotion creates an independent writable database but does not automatically update application connection settings. The recovery process must redirect clients to the promoted database and validate security, credentials, and dependent services.

Question 5

An architect is asked to provide automatic failover with minimal application intervention for an RDS workload in one AWS Region. Which choice most directly addresses this requirement?

A. A read replica in another Region with manual promotion.
B. A same-Region Multi-AZ deployment.
C. A read replica used as a permanent write target.
D. A larger DB instance class without redundancy.

Correct answer: B

Explanation: Multi-AZ is designed for high availability and managed failover within a Region. A read replica is primarily for read scaling and requires promotion and application redirection when used for recovery.