RDS Multi-AZ: SAA-C03 study notes and practice questions
What to know about RDS Multi-AZ for the SAA-C03 exam, from the Design Resilient Architectures domain (26% of the exam guide), then 1 free question to test it. Part of the SAA-C03 study guide.
The single most tested database idea on SAA-C03: Multi-AZ is for availability, read replicas are for read performance. Mixing them up is the classic wrong answer.
Key facts
Multi-AZ DB instance deployment: one primary and one standby in a different Availability Zone, kept in step with synchronous replication. The standby can’t serve reads. If the primary or its zone fails, RDS fails over automatically, usually within 60 to 120 seconds, and the same DNS endpoint points to the new primary.
Multi-AZ DB cluster deployment (MySQL and PostgreSQL): a writer and two readable standbys in three zones, with faster failover (typically under 35 seconds) and reader endpoints you can use for reads.
Aurora stores six copies of data across three zones whatever you choose. For fast failover, add at least one Aurora Replica in another zone; Aurora promotes it automatically. Without one, Aurora has to create a new instance, which takes longer.
Failover is triggered by loss of the primary, its zone, network or storage, and also by a manual reboot with failover (good for testing).
Backups and maintenance run from the standby where possible, which reduces I/O impact on the primary.
Read replicas use asynchronous replication, can be in another Region, and must be promoted by hand (they’re not automatic failover for a standard RDS instance).
How to choose
The scenario says
Look for
Survive an Availability Zone failure with no data loss and automatic failover
Multi-AZ
Reads are overloading the database
Read replicas (or Aurora Replicas)
Both
Multi-AZ DB cluster, or Aurora with replicas in other zones
Survive a Region failure
Cross-Region read replica or Aurora Global Database (see disaster recovery)
Fastest possible failover for MySQL or PostgreSQL
Multi-AZ DB cluster or Aurora, plus RDS Proxy to hold connections
Common traps
Sending reads to the Multi-AZ standby. In a Multi-AZ DB instance deployment, you can’t.
Choosing a read replica for “automatic failover with zero data loss”. Asynchronous replication can lose recent writes, and failover isn’t automatic.
Hard-coding the instance IP. Always connect through the DB endpoint so failover is transparent.
An insurance company runs its policy administration system on a Single-AZ Amazon RDS for PostgreSQL DB instance.
After a recent Availability Zone outage, the business set new targets: the database must fail over automatically within a few minutes, and no committed transaction may be lost.
Reporting already runs on a separate data warehouse, so a standby does not need to serve reads.
Which solution meets these requirements MOST cost-effectively?
Choose one answer.
AA. Convert the DB instance to a Multi-AZ DB instance deployment, so that RDS keeps one synchronous standby in another Availability Zone.
BB. Convert to a Multi-AZ DB cluster deployment, with one writer and two readable standby instances in three Availability Zones.
CC. Create a read replica in another Availability Zone, and use an RDS event notification and a Lambda function to promote it after a failure.
DD. Keep automated backups with point-in-time recovery, and script a restore to a new DB instance in another Availability Zone after a failure.
Show the answer and explanation
Answer: A
A. Right: Correct. The standby is updated synchronously, so committed transactions are not lost, and RDS fails over to it automatically, typically in 60 to 120 seconds. It runs one extra instance, the least needed for automatic failover. Learn more: Multi-AZ DB instance deployments (opens in a new tab)
B. Wrong: A Multi-AZ DB cluster commits only after at least one reader acknowledges the change, and it fails over automatically, so it meets the targets. But it runs three DB instances, and the extra readable standby is something the company said it does not need. A Multi-AZ DB instance deployment meets the targets for less. Learn more: Multi-AZ DB cluster deployments for Amazon RDS (opens in a new tab)
C. Wrong: Read replicas are updated asynchronously, so transactions committed just before the failure may not have reached the replica. The promotion logic is also custom code that the team must maintain. Multi-AZ replicates synchronously and fails over without custom automation. Learn more: Working with DB instance read replicas (opens in a new tab)
D. Wrong: Point-in-time restore usually reaches only to within the last five minutes, so recent transactions can be lost. The restore also creates a new instance with a new endpoint, which takes far longer than a few minutes for a large database. It is cheap, but it misses both targets. Learn more: Backup and recovery for Amazon RDS (opens in a new tab)
Explanation
Zero data loss needs synchronous (or semisynchronous) replication, and failover within minutes needs it to be automatic. Both Multi-AZ options meet that; read replicas and backups do not. Because the standby does not need to serve reads, the single-standby Multi-AZ DB instance deployment is the cheaper fit.
Want more on RDS Multi-AZ? The 5 full-length practice sets have 10 more RDS Multi-AZ questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →