Study guide

Technical reference and lesson notes

AWS RDS and Aurora Read Replicas, Multi-AZ, Global Database, and Serverless

Purpose of This Lesson

This lesson focuses on the availability, disaster recovery, read-scaling, cross-Region, multi-writer, and on-demand capacity options available for Amazon RDS and Amazon Aurora. The central decision is whether a requirement calls for failover protection, read scaling, cross-Region recovery, multiple writers, or automatic capacity adjustment.

Key Concepts

RDS Multi-AZ provides a passive standby in a different Availability Zone for disaster recovery and high availability.
RDS read replicas scale read traffic by maintaining a separate readable copy of the database.
Aurora replicas provide regional read scaling and can be promoted if the primary fails.
Aurora storage automatically distributes data across three Availability Zones, with multiple copies of the data.
Aurora MySQL cross-Region replication uses asynchronous replication to copy data to one or more secondary Regions.
Aurora Global Database provides a primary Region and secondary Region(s), with replication through the Aurora storage layer.
Aurora Multi-Master permits reads and writes against multiple Aurora instances in a single Region.
Aurora Serverless adjusts database capacity on demand using Aurora Capacity Units (ACUs).

Availability, Replication, and Scaling Models

RDS Multi-AZ: Standby-Based Disaster Recovery

An RDS Multi-AZ deployment has a primary database instance and a passive standby in another Availability Zone. The primary accepts both reads and writes. Replication to the standby is synchronous, and the standby is primarily intended for availability and disaster recovery rather than read scaling.

If the primary’s Availability Zone experiences a failure, the standby is automatically promoted to become the new primary. Applications continue using the database service endpoint rather than being directed to the standby as a read endpoint during normal operation.

RDS Read Replicas: Read Scaling

An RDS read replica is designed to reduce read pressure on the primary database. Applications can continue writing to the primary while directing read-heavy workloads to the replica.

Read replicas use asynchronous replication, so a replica can experience replication lag. They should not be treated as an exact, always-current standby for automatic Multi-AZ failover. The decisive requirement is workload scaling: use a read replica when the problem is too many reads, not merely when the requirement is Availability Zone failure protection.

Aurora’s Regional Fault Tolerance

Aurora distributes its logical storage volume across three Availability Zones and maintains multiple copies of the data. This provides substantial durability and redundancy even when the cluster has only one primary database instance.

Aurora replicas are separate database instances used primarily for read scaling. They have independent endpoints, allowing applications to send read traffic away from the primary. The lesson identifies support for up to 15 Aurora replicas and replica lag of less than 10 milliseconds under the described capability.

Aurora replicas can also be promoted to become a new primary. Each replica can be assigned a promotion priority, which helps determine the order in which replicas are selected during a primary failure. Aurora can also use auto scaling to add and remove replicas as read demand changes.

Aurora replicas are regional: they exist within one AWS Region and are not themselves cross-Region replicas.

Cross-Region Aurora MySQL Replication

For cross-Region replication using Aurora MySQL, the source cluster in the primary Region replicates data to a secondary Region using the MySQL database engine’s replication mechanism. This replication is asynchronous, and the data can be replicated to multiple AWS Regions.

This option is appropriate when a workload needs a database copy in another Region, but the design must account for replication lag and the possibility that the secondary copy is not fully current at the instant of a failure.

Aurora Global Database

Aurora Global Database uses a primary Region and one or more secondary Regions. The lesson describes replication through the Aurora storage layer rather than through MySQL replication, with synchronous replication as the stated model. Applications can connect to the cluster reader endpoint in a secondary Region for read access.

The important distinction is the replication mechanism: Aurora Global Database relies on the Aurora storage layer, while the cross-Region Aurora MySQL option described above uses MySQL-based asynchronous replication.

Aurora Multi-Master

Aurora Multi-Master provides multiple primary, read/write nodes. Any of these nodes can accept reads and writes, unlike a conventional primary-plus-read-replicas design.

The lecture identifies these constraints and characteristics:

Available for the MySQL engine only.
Supports up to four read/write nodes.
Operates in a single Region.
Does not support cross-Region replicas.
Supports active-active and active-passive workload patterns.
Restarting one DB instance does not impact the other instances.

Multi-Master is therefore a write-availability and multi-writer choice, not simply another name for Aurora read replicas.

Aurora Serverless

Aurora Serverless is an on-demand, auto-scaling Aurora configuration. It can start, stop, and adjust database capacity according to application demand. Applications connect through a router fleet, which directs requests to the available database instances.

A warm pool of capacity helps provide fast response time when capacity is needed. Capacity is expressed in Aurora Capacity Units (ACUs). Each ACU includes 2 GB of RAM plus allocated CPU resources. The configured ACU range determines the capacity available to the workload.

Aurora Serverless is especially useful for:

Infrequently used applications
New applications with unknown usage patterns
Workloads with wide fluctuations in demand
Unpredictable workloads with spikes and quiet periods
Development and test databases
Multi-tenant applications

Exam- or Assessment-Relevant Takeaways

For SOA-C03-style scenario analysis, first identify the dominant requirement:

Automatic failover between Availability Zones: Choose RDS Multi-AZ.
Offloading read-heavy traffic: Choose RDS read replicas or Aurora replicas, depending on the database platform and required Aurora capabilities.
Regional Aurora read scaling: Use Aurora replicas; they provide independent read endpoints and can be promoted.
Cross-Region copy using MySQL replication: Use cross-Region Aurora MySQL replication and account for asynchronous lag.
Cross-Region Aurora architecture using the storage layer: Use Aurora Global Database as described in the lesson.
Multiple read/write database nodes: Consider Aurora Multi-Master, while checking its MySQL-only, single-Region, four-node limit.
Unknown, intermittent, or highly variable capacity needs: Consider Aurora Serverless.

Do not confuse the purpose of a passive Multi-AZ standby with that of a read replica. Multi-AZ is primarily for availability and recovery; read replicas are primarily for read scaling.

Tool / Feature Decision Guide

Requirement	Appropriate feature	Key reason or limitation
Recover automatically from an Availability Zone failure	RDS Multi-AZ	Passive standby with synchronous replication and automatic promotion
Reduce read load on an RDS primary	RDS read replica	Readable copy using asynchronous replication
Scale reads within an Aurora Region	Aurora replicas	Independent read endpoints, up to 15 replicas in the lesson
Maintain Aurora data in another Region using MySQL replication	Aurora MySQL cross-Region replication	Asynchronous replication; replication lag is possible
Use Aurora storage-layer replication across Regions	Aurora Global Database	Provides primary and secondary Regions with secondary reader access
Allow several Aurora nodes to accept writes	Aurora Multi-Master	MySQL only, single Region, up to four read/write nodes
Adjust Aurora capacity for intermittent or unpredictable demand	Aurora Serverless	On-demand scaling through router fleet and ACUs

Common Traps / Misconceptions

Trap: Treating Multi-AZ as a read-scaling feature. The standby is passive and is primarily for disaster recovery; use read replicas to distribute reads.
Trap: Assuming read replicas use synchronous replication. The RDS read-replica model described here uses asynchronous replication, so lag is possible.
Trap: Assuming an Aurora replica is automatically cross-Region. Aurora replicas are within one Region.
Trap: Confusing Aurora replicas with Multi-Master. Aurora replicas are primarily read scaling; Multi-Master provides multiple read/write nodes.
Trap: Overlooking Multi-Master constraints. It is MySQL-only, limited to four read/write nodes in the lesson, single-Region, and cannot have cross-Region replicas.
Trap: Assuming a secondary Region is always fully current. Cross-Region Aurora MySQL replication is asynchronous.
Trap: Treating Aurora’s replicated storage as the same thing as multiple DB instances. Aurora’s logical volume is distributed across three Availability Zones even when the cluster has only one primary instance.
Trap: Selecting Aurora Serverless solely because it is newer. Its strongest fit is intermittent, unknown, highly variable, or unpredictable demand.

Real-World Engineer / Analyst Notes

Start architecture discussions with the failure or scaling mode: instance failure, Availability Zone failure, read saturation, Region failure, write availability, or variable capacity.
Use replication semantics to evaluate recovery-point expectations. Synchronous replication reduces the replication gap in the described Multi-AZ model, while asynchronous replicas can lag.
Route read traffic deliberately. A read replica or Aurora reader endpoint is useful only when applications and connection patterns can direct eligible reads away from the writer.
Promotion priorities matter in Aurora designs with multiple replicas. They provide a way to influence which replica becomes primary during a failure.
Cross-Region designs should account for network distance, replication lag, endpoint behavior, and the operational process for promoting or using a secondary Region.
Aurora Serverless is a capacity-management choice, not a replacement for every high-availability or cross-Region design. Its value comes from matching capacity to demand.

Quick Reference Summary

RDS Multi-AZ: primary plus passive standby in another Availability Zone; synchronous replication; automatic failover; disaster recovery and availability.
RDS read replica: readable copy for read scaling; asynchronous replication; writes remain on the primary.
Aurora storage: logical volume spread across three Availability Zones with multiple data copies.
Aurora replicas: regional read scaling; independent endpoints; up to 15 in the lesson; can be promoted; promotion priority supported.
Aurora MySQL cross-Region replication: asynchronous MySQL-based replication to secondary Regions.
Aurora Global Database: primary and secondary Regions using Aurora storage-layer replication; secondary reader endpoint available.
Aurora Multi-Master: MySQL-only, single-Region, up to four read/write nodes; supports active-active and active-passive patterns.
Aurora Serverless: on-demand scaling through a router fleet; uses ACUs, each providing 2 GB RAM plus CPU; suited to variable or infrequent workloads.

Flashcards

Q: An RDS database must automatically recover when its Availability Zone fails, and the secondary instance should not normally serve application reads. Which feature fits?
A: RDS Multi-AZ. It uses a passive standby in another Availability Zone and synchronous replication for automatic failover.

Q: An RDS primary is overloaded by read traffic, but applications still need to write to the primary. Which feature should be considered?
A: An RDS read replica. Applications can continue writing to the primary while directing read requests to the replica.

Q: What replication behavior distinguishes the RDS read-replica use case from the RDS Multi-AZ standby use case?
A: RDS read replicas use asynchronous replication and can lag, while the Multi-AZ standby uses synchronous replication in the described model.

Q: Why can Aurora provide strong storage redundancy even with only one primary DB instance?
A: Aurora’s logical storage volume is spread across three Availability Zones and maintains multiple copies of the data.

Q: A regional Aurora application needs independent endpoints for read scaling and a possible failover target. What should it use?
A: Aurora replicas. They serve read traffic, can be promoted to primary, and can be assigned promotion priorities.

Q: Are Aurora replicas automatically cross-Region, and what is their regional scope?
A: No. Aurora replicas are within one AWS Region; cross-Region replication requires a separate cross-Region capability.

Q: Which Aurora option in the lesson uses MySQL-based asynchronous replication to copy data to another Region?
A: Cross-Region Aurora MySQL replication. It can replicate to multiple AWS Regions, but asynchronous replication means lag is possible.

Q: How does Aurora Global Database differ from cross-Region Aurora MySQL replication in the described architecture?
A: Global Database uses the Aurora storage layer for replication, while the other option uses the MySQL database engine’s replication mechanism. Secondary-Region applications can use the cluster reader endpoint with Global Database.

Q: A workload requires several Aurora instances to accept both reads and writes in one Region. Which feature is relevant, and what major engine restriction applies?
A: Aurora Multi-Master is relevant, and it is available for the MySQL engine only.

Q: What are the key limits and scope of Aurora Multi-Master stated in the lesson?
A: It supports up to four read/write nodes, is single-Region only, and cannot have cross-Region replicas.

Q: When is Aurora Serverless a stronger choice than permanently provisioned database capacity?
A: When usage is infrequent, unknown, highly variable, or unpredictable, including development/test and multi-tenant workloads. It adjusts capacity on demand.

Q: What is an Aurora Capacity Unit in the lesson’s description?
A: An ACU represents 2 GB of RAM plus allocated CPU resources. The configured ACU amount determines the available serverless capacity.

Practice Questions

Question 1

A production RDS database receives a large volume of read requests. The application can route reporting queries separately, and a small amount of replication lag is acceptable. Which design best addresses the stated problem?

A. Add an RDS Multi-AZ standby and send reports to it
B. Add an RDS read replica and route reporting reads to it
C. Convert the database to Aurora Multi-Master
D. Use Aurora Serverless without changing the application’s read routing

Correct answer: B

Explanation: The requirement is read scaling, and RDS read replicas are readable asynchronous copies designed to offload reads. Multi-AZ is primarily for failover and the other options do not match the stated RDS read-scaling need.

Question 2

An Aurora MySQL workload needs a copy in a second AWS Region. The team understands that the secondary may temporarily lag behind the primary. Which option best matches this requirement?

A. Aurora replicas in the primary Region
B. RDS Multi-AZ
C. Cross-Region Aurora MySQL replication
D. Aurora Multi-Master

Correct answer: C

Explanation: Cross-Region Aurora MySQL replication uses asynchronous MySQL-based replication and can copy data to secondary Regions. The other choices are regional or do not provide the described cross-Region model.

Question 3

A database design requires multiple Aurora nodes to accept both reads and writes. It must remain in one Region, and the engine can be MySQL. Which feature should be evaluated first?

A. Aurora Multi-Master
B. Aurora read replicas only
C. RDS Multi-AZ
D. Aurora Serverless

Correct answer: A

Explanation: Aurora Multi-Master provides multiple read/write nodes and is described as MySQL-only and single-Region. Read replicas primarily scale reads, while Multi-AZ uses a passive standby.

Question 4

A new multi-tenant application will have unpredictable demand, including long quiet periods followed by sudden spikes. The team wants capacity to start, stop, and scale according to demand. Which option is the best fit?

A. RDS Multi-AZ only
B. Aurora Serverless
C. Aurora Multi-Master
D. A single Aurora primary with no replicas

Correct answer: B

Explanation: Aurora Serverless is designed for infrequent, variable, and unpredictable workloads and adjusts capacity on demand through its router fleet and ACU-based capacity model.

WordPress Metadata

Suggested Slug:
aws-rds-aurora-read-replicas-multi-az

Meta Description:
Study RDS Multi-AZ, read replicas, Aurora replicas, cross-Region replication, Multi-Master, and Aurora Serverless for AWS Certified CloudOps Engineer Associate SOA-C03.

Tags:
AWS, Amazon RDS, Amazon Aurora, Multi-AZ, Read Replicas, Disaster Recovery, High Availability, Aurora Global Database, Aurora Serverless, Database Scaling, SOA-C03