🧩 1. RDS Multi-AZ DB Cluster (for RDS engines like PostgreSQL or MySQL)
Purpose: High availability (HA) within a single AWS Region.
Architecture:
- One primary (writer) and two standby (readable) replicas in different Availability Zones within the same Region.
- Provides automatic failover in ~35 seconds.
- Includes a reader endpoint to offload read traffic.
- Uses synchronous replication between AZs (strong consistency).
Scope:
- Confined to one Region.
- Cannot replicate data globally.
- Provides regional HA and read scaling, not global distribution.
Example use case:
“We need a highly available RDS PostgreSQL database for our production app in us-east-1.”
🌍 2. Aurora Global Database
Purpose: High availability and low-latency reads across multiple AWS Regions.
Architecture:
- One primary Region with read/write access.
- Up to 5 read-only secondary Regions for global reads and disaster recovery.
-
Uses Aurora’s storage-based replication, which is:
- Asynchronous between Regions (latency < 1 second typically).
- Synchronous within the primary Region (for local HA).
Scope:
- Multi-Region replication (global).
- Secondary Regions can promote to primary in case of a disaster.
- Great for global apps with users across continents.
Example use case:
“We need our database to serve users in North America, Europe, and Asia with low read latency and disaster recovery between Regions.”
⚖️ Summary Table
| Feature | RDS Multi-AZ DB Cluster | Aurora Global Database |
|---|---|---|
| Supported Engines | RDS MySQL, RDS PostgreSQL | Aurora MySQL, Aurora PostgreSQL |
| Replication Type | Synchronous (within Region) | Asynchronous (cross-Region) |
| Failover Time | ~35 seconds | <1 minute (Regional failover) |
| Read Scaling | Within Region (reader endpoint) | Global (across Regions) |
| Cost | Lower | Higher (global replication costs) |
| Use Case | High availability within one Region | Global app with multi-Region read/write needs |
🧠 In short:
- RDS Multi-AZ DB Cluster → Regional HA solution
- Aurora Global Database → Global distribution + disaster recovery
🏗️ Multi-AZ DB Cluster Architecture (for RDS MySQL & PostgreSQL)
When you create a Multi-AZ DB cluster, AWS deploys multiple DB instances that share a single storage volume (using Amazon RDS-managed block storage replication).
✅ Minimum setup:
- 1 Writer (Primary)
- 1 Reader (Standby / Replica) That’s the minimum Multi-AZ cluster — it gives you high availability and automatic failover.
⚙️ But by default, AWS actually creates 3 instances in many configurations:
- 1 Writer (active)
- 2 Readers (readable standbys, in different AZs)
This 3-AZ configuration is the recommended and default deployment for the newer Multi-AZ DB cluster feature (introduced in 2022).
Here’s why:
| Role | Purpose | AZ Placement |
|---|---|---|
| Primary (writer) | Handles writes | AZ1 |
| Reader 1 | Hot standby, can serve reads | AZ2 |
| Reader 2 | Additional standby/read replica | AZ3 |
So even though one standby is technically enough, AWS provisions two readers across two other AZs for stronger fault tolerance (if an AZ goes down, another remains available).
⚡ Why 3 instances make sense:
- Ensures automatic failover can still occur if one AZ is lost.
- Provides additional read capacity without needing separate read replicas.
- Keeps RPO = 0 and RTO < 35 seconds.
- Replication is synchronous, so data is consistent across all nodes.
🧮 Cost and Flexibility
- You can manually scale the number of reader instances (minimum 1).
- If you want to minimize cost, you can choose a 2-instance setup (1 writer + 1 reader).
- If you prioritize HA and read performance, use 3 instances (1 writer + 2 readers across 3 AZs).
🧠 Summary
| Setting | Writer | Readers | AZs Used | Purpose |
|---|---|---|---|---|
| Minimum | 1 | 1 | 2 AZs | Basic HA |
| Default / Recommended | 1 | 2 | 3 AZs | Strong HA + Read scaling |
Top comments (0)