Multi-AZ Architecture: High Availability for SAA-C03
In the AWS ecosystem, Multi-AZ (Availability Zone) architecture is the cornerstone of High Availability (HA). It ensures that your application remains operational even if an entire data center facility fails. For the SAA-C03 exam, you must distinguish between Multi-AZ for redundancy and Read Replicas for performance.
The Real-World Analogy
Imagine a high-end restaurant with two separate kitchens in two different buildings across the street from each other. If a pipe bursts in Kitchen A, the chefs in Kitchen B immediately take over the orders. The customers might notice a slight pause, but the restaurant never closes. This is Multi-AZ. (Contrast this with a “Backup” which is just a recipe book stored in a safe—useful, but takes hours to start cooking again).
Core Concepts & Configuration
AWS Regions are composed of multiple Availability Zones. Each AZ is one or more discrete data centers with redundant power, networking, and connectivity. Multi-AZ deployments leverage this isolation to prevent single points of failure.
- Synchronous Replication: Used by RDS Multi-AZ. Data is written to the primary and standby simultaneously before the write is acknowledged.
- Automatic Failover: AWS manages the DNS update to point your endpoint to the standby instance if the primary fails.
- Fault Isolation: AZs are physically separated by miles to protect against fires, floods, or grid failures.
Service Comparison: RDS Multi-AZ vs. Read Replicas
| Feature | Multi-AZ Deployment | Read Replicas |
|---|---|---|
| Primary Purpose | High Availability (HA) & Disaster Recovery | Scalability (Read-heavy workloads) |
| Replication Type | Synchronous | Asynchronous |
| Failover | Automatic (AWS Managed) | Manual (Must promote to standalone) |
| Backups | Taken from Standby (No impact on Primary) | Taken from Primary |
| Visibility | Standby is “invisible” (cannot be read) | Can be queried for reporting/analytics |
Decision Matrix / If–Then Guide
- If you need to survive an AZ failure with zero data loss, Then use RDS Multi-AZ.
- If your application is slow due to heavy SELECT queries, Then add Read Replicas.
- If you need HA for web servers, Then use an ALB with an Auto Scaling Group spanning 3 AZs.
- If you need low-cost storage that survives AZ failure, Then use S3 Standard (not S3 One Zone-IA).
Exam Tips and Gotchas
- Golden Nugget: Multi-AZ is NOT a scaling solution. It provides redundancy, not extra performance.
- Distractor: The exam might suggest Multi-AZ to solve “slow database performance.” This is wrong; Read Replicas or ElastiCache are the correct answers.
- Latency: Because Multi-AZ uses synchronous replication, you may see slightly higher write latency compared to a Single-AZ setup.
- Cross-Zone Load Balancing: For ELB, ensure Cross-Zone Load Balancing is enabled to distribute traffic evenly across all instances in all enabled AZs.
Topics covered:
- Difference between Regions and Availability Zones.
- RDS Multi-AZ vs. Read Replica architecture.
- Auto Scaling Groups (ASG) and Elastic Load Balancing (ELB) integration.
- Storage HA (S3 Standard vs. One Zone, EFS Standard vs. One Zone).
- Data transfer costs and latency trade-offs.
Visualizing Multi-AZ Architecture
Integrations
- CloudWatch: Monitors health and triggers failover alarms.
- Route 53: Can perform health checks for DNS-level failover.
- IAM: Controls permissions for managing DB Subnet Groups.
Scaling & Latency
Multi-AZ provides High Availability, not performance. For scaling, use Read Replicas or ElastiCache. Always place your App and DB in the same AZ to minimize latency for active traffic.
The Price of HA
Multi-AZ usually doubles the cost of your RDS instance. Tip: Use Single-AZ for Dev/Test environments to save money, and Multi-AZ for Production.
Production Banking App
A mission-critical banking application uses Multi-AZ RDS to ensure that even if a data center burns down, no transaction data is lost and the app stays online automatically.