Multi-AZ and fault tolerance: SOA-C03 study notes and practice questions
What to know about Multi-AZ and fault tolerance for the SOA-C03 exam, from the Reliability and Business Continuity domain (22% of the exam guide), then 1 free question to test it. Part of the SOA-C03 study guide.
These questions show a setup with a hidden single point of failure and ask how to remove it, or describe an outage and ask why it happened.
Patterns
Layer
Highly available setup
Compute
Auto Scaling group across at least two AZs behind a load balancer
Load balancer
Enabled in multiple AZs (cross-zone load balancing spreads traffic evenly)
Database
RDS Multi-AZ or Aurora with replicas in other AZs
Cache
ElastiCache (Valkey/Redis OSS) with replicas and Multi-AZ automatic failover
Outbound internet
A NAT gateway in each AZ, with each AZ’s private subnets routed to their own
Shared files
EFS Regional file system; FSx Multi-AZ
On-premises link
Two VPN tunnels, two Direct Connect connections, or Direct Connect plus VPN backup
RDS Multi-AZ failover
Failover changes the DNS record behind the DB endpoint to point at the standby. Applications must connect with the endpoint name, not an IP address, and should not cache DNS for long.
Typical failover takes 60 to 120 seconds for a Multi-AZ instance; Multi-AZ DB clusters and Aurora are faster.
RDS Proxy keeps client connections open during failover and reconnects to the new primary.
An RDS event notification (through EventBridge or SNS) tells you when a failover happens.
You can test with Reboot with failover.
Other ideas
Static stability: keep enough capacity in each AZ so the loss of one doesn’t depend on launching new instances.
Elastic IP addresses can move to a standby instance in a simple active-passive setup.
Route 53 health checks move users away from a failed Region.
Common traps
Applications that hard-code the database IP break after failover.
One NAT gateway for all AZs. Losing its AZ cuts internet access for the others.
Read replicas as the failover plan for RDS (non-Aurora). Promotion is manual and asynchronous.
A solar installer's scheduling application connects to an Amazon RDS for MySQL Multi-AZ DB instance.
During a planned failover test, the database failed over in under two minutes, but the application kept timing out for 40 minutes until its servers were restarted.
Investigation shows the application resolves the database endpoint name once at startup and then reuses the IP address.
What should a CloudOps engineer recommend so that the application recovers automatically from future failovers?
Choose one answer.
AA. Convert the DB instance to a Single-AZ deployment with automated backups, so that the endpoint IP address never changes.
BB. Create a read replica in another Availability Zone and point the application at the replica's IP address during failover tests.
CC. Add an Elastic IP address to the DB instance so that the same address moves to the standby during each failover.
DD. Make the application honor DNS TTLs and re-resolve the DB endpoint name when it reconnects.
D. Right: Correct. During failover RDS points the endpoint's DNS record at the new primary. Clients that re-resolve the name reconnect within minutes, while clients that cache the old IP address keep failing. Learn more: Failover process for Amazon RDS (opens in a new tab)
Explanation
RDS Multi-AZ failover works by changing the DNS record behind the DB endpoint to the standby's address. Applications must connect by endpoint name and must not cache DNS results longer than the record's TTL, or they keep reaching the failed address. Long client-side DNS caches are a common reason failovers look longer than they are.
Want more on Multi-AZ and fault tolerance? The 5 full-length practice sets have 5 more Multi-AZ and fault tolerance questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →