Cargando...
Cargando...
Know exactly which to deploy — availability, read scaling, or global reach — and never lose an exam point again
Availability vs Read Scalability vs Global Resilience — three tools, three jobs, zero overlap in purpose
| Feature | RDS Multi-AZ Automatic failover for high availability | Read Replicas Scale reads, offload reporting workloads | Aurora Global Sub-second replication across AWS regions |
|---|---|---|---|
Primary Purpose The exam loves to test: Multi-AZ does NOT improve read performance. Read Replicas do NOT provide automatic failover. Aurora Global does both, but costs more. | High Availability — automatic failover if primary fails | Read Scalability — offload SELECT queries from primary | Global Resilience & Disaster Recovery across regions |
Replication Type CRITICAL: Multi-AZ is synchronous = zero RPO possible. Read Replicas are asynchronous = potential data loss. Aurora Global uses dedicated replication infrastructure for <1s lag. | Synchronous replication to standby (no data loss on failover) | Asynchronous replication (small replication lag possible) | Aurora-native storage-level replication with typically <1 second lag cross-region |
Standby/Replica Readable? This is the #1 Multi-AZ trap. Candidates assume the standby can serve reads — it cannot. You pay for the standby but get ZERO read throughput benefit from it. | NO — standby instance is NOT accessible for reads or any traffic (pure standby) | YES — replicas serve live read traffic via their own endpoint | YES — secondary regions are readable; primary region handles writes |
Failover Scope For a region-level disaster, only Aurora Global provides managed cross-region failover. Multi-AZ only protects against AZ failure. | Within a single AWS Region (cross-AZ failover only) | Manual promotion required; no automatic failover (for RDS); Aurora Read Replicas can auto-promote within cluster | Cross-region failover — secondary region can be promoted in typically <1 minute |
Failover Time Aurora Global's RPO is typically <1 second and RTO is typically <1 minute for cross-region. Multi-AZ RTO is ~1-2 minutes within region. | Typically 60–120 seconds (DNS-based cutover to standby) | Manual promotion — minutes to hours depending on replica lag and process | Typically under 1 minute for managed cross-region failover |
Number of Replicas/Standbys Live docs did not specify exact Multi-AZ cluster limits beyond the 3-node structure. Aurora's 15 replicas per cluster and 5 secondary regions are well-documented advantages. | 1 standby (Multi-AZ instance) or up to 2 standbys (Multi-AZ cluster — 3 total nodes) | Up to 5 Read Replicas per source DB instance (RDS); up to 15 Aurora Replicas within a cluster | Up to 5 secondary AWS Regions; up to 16 Aurora Replicas per secondary region |
Cross-Region Support Cross-Region Read Replicas exist but use asynchronous replication over the internet. Aurora Global uses a dedicated low-latency replication layer — a fundamentally different architecture. | NO — operates within a single region across multiple AZs only | YES — Cross-Region Read Replicas supported for RDS and Aurora (for DR or local reads) | YES — purpose-built for multi-region; dedicated replication infrastructure |
Write Capability on Secondary Aurora Global's write forwarding feature allows applications in secondary regions to issue writes — they are forwarded to the primary region transparently. Adds latency but simplifies app architecture. | NO — standby only accepts writes after promotion (failover) | NO — replicas are read-only until manually promoted to standalone DB | NO writes on secondary regions by default; write forwarding feature available (forwards writes to primary) |
Endpoint Architecture Multi-AZ failover is transparent — the application connection string does not change. Read Replicas require application-level routing logic to distribute queries. | Single endpoint — DNS automatically points to active primary; failover is transparent to app | Each replica has its own endpoint; applications must be coded to use read endpoint(s); Aurora has cluster reader endpoint | Per-region cluster endpoints; applications in each region connect to local cluster endpoint |
Supported Database Engines Aurora Global is Aurora-only. If the question involves SQL Server or Oracle with global requirements, you'd use Cross-Region Read Replicas or a different strategy. | MySQL, MariaDB, Oracle, PostgreSQL, SQL Server (instance); MySQL, PostgreSQL (Multi-AZ cluster) | MySQL, MariaDB, PostgreSQL, Oracle, SQL Server (with limitations); all Aurora engines | Aurora MySQL and Aurora PostgreSQL only |
Storage Architecture Aurora Replicas within a cluster share storage — replication lag is near-zero within a region. This is architecturally different from RDS replicas which maintain separate storage. | Separate EBS volumes on primary and standby; synchronous block-level replication | Separate EBS volumes per replica (RDS); Aurora replicas share the same distributed storage layer as primary | Aurora distributed storage replicated across regions; secondary regions have their own storage copies |
Automated Backups on Replica Multi-AZ reduces backup I/O impact on production — a performance benefit often overlooked. This is a secondary benefit of Multi-AZ beyond HA. | Backups can be taken from the standby, reducing I/O impact on primary | Automated backups disabled on Read Replicas by default (RDS); can enable manually | Automated backups on primary cluster; secondary clusters do not have independent automated backups |
Cost Model Read Replicas can be right-sized independently. Multi-AZ standby must match primary instance class. Aurora Global has significant cross-region data transfer costs. | Approximately 2x the cost of a Single-AZ instance (you pay for standby instance + storage) | Pay per replica instance + storage; each replica billed at same rate as a DB instance | Pay for primary cluster + all secondary region clusters + cross-region data transfer; highest cost tier |
Use Case — Primary Scenario | Production databases requiring HA with automatic failover; compliance requiring minimal downtime | Read-heavy workloads; reporting/analytics offload; geographic read distribution; disaster recovery (manual) | Globally distributed applications; GDPR/data residency requirements; RPO <1s and RTO <1min across regions |
Promotion to Primary After promoting an RDS Read Replica, it becomes a standalone DB — it is NO LONGER a replica and replication does not resume automatically. | Automatic — AWS detects failure and promotes standby; no manual action required | Manual — must explicitly promote replica to standalone DB instance; breaks replication permanently | Managed — detach secondary region and promote to standalone cluster; requires application DNS update |
Data Durability / RPO For zero data loss within a region, Multi-AZ is the answer. For near-zero data loss across regions, Aurora Global is the answer. | RPO = 0 (synchronous replication; no committed transactions lost on AZ failure) | RPO > 0 (asynchronous; some transactions may not yet be replicated at time of failure) | RPO typically <1 second cross-region (dedicated replication infrastructure) |
Summary
Use RDS Multi-AZ when your primary concern is automatic failover and zero data loss within a single region — it's your HA safety net, not a performance tool. Use Read Replicas when you need to scale read throughput, offload analytics, or build a cost-effective manual DR strategy. Choose Aurora Global when your application spans multiple AWS regions and you need sub-second RPO and sub-minute RTO across a geographic footprint — it's the premium, purpose-built solution for global database resilience.
🎯 Decision Tree
If the scenario mentions 'automatic failover' or 'minimize downtime during AZ failure' → Multi-AZ. If the scenario mentions 'read-heavy workload', 'reporting', 'offload reads', or 'scale reads' → Read Replicas. If the scenario mentions 'cross-region', 'global users', 'region-level disaster recovery', 'RPO under 1 second across regions', or 'data residency in multiple regions' → Aurora Global. If Multi-AZ + read scaling needed within one region → Multi-AZ + Read Replicas together. If standby must serve reads → NOT Multi-AZ (use Aurora Replicas or Read Replicas instead).
CRITICAL — Multi-AZ standby is NEVER readable: The standby in a traditional RDS Multi-AZ deployment cannot serve read traffic under any circumstances. It exists solely for failover. If a question asks how to 'improve read performance' and lists Multi-AZ as an option, it is WRONG. Only Read Replicas or Aurora Replicas improve read throughput. This single misconception causes more exam failures than any other RDS topic.
CRITICAL — Synchronous vs Asynchronous determines RPO: Multi-AZ uses synchronous replication → RPO = 0 (no data loss on AZ failure). Read Replicas use asynchronous replication → RPO > 0 (potential data loss). Aurora Global uses near-synchronous dedicated replication → RPO typically <1 second cross-region. When a scenario demands 'no data loss' within a region, the answer is Multi-AZ. When it demands 'minimal data loss' across regions, the answer is Aurora Global.
CRITICAL — Aurora Replicas vs RDS Read Replicas are architecturally different: Aurora Replicas share the same distributed storage volume as the primary — failover promotes a replica in under 30 seconds with no data loss. RDS Read Replicas have separate storage and asynchronous replication — promotion takes longer and may lose data. On exams, 'fastest failover within a region' points to Aurora, not RDS Multi-AZ.
IMPORTANT — Read Replicas can be used for DR but require manual intervention: You CAN promote a Read Replica to a standalone DB for disaster recovery, but this is manual, breaks replication permanently, and has RPO > 0 due to async lag. For automated DR, use Multi-AZ (within region) or Aurora Global (cross-region). Exam scenarios testing 'automated failover' should never resolve to Read Replicas alone.
IMPORTANT — Aurora Global enables write forwarding from secondary regions: Secondary regions in Aurora Global are read-only by default, but the write forwarding feature allows applications in secondary regions to issue write statements — Aurora transparently forwards them to the primary region. This adds latency (cross-region round trip) but simplifies multi-region application architecture. Exam may test whether you know secondary regions are read-only by default.
IMPORTANT — Multi-AZ is a regional construct, not a global one: Multi-AZ protects against Availability Zone failure within a single AWS Region. It does NOT protect against a full regional outage. If a scenario describes a region going down and asks for the recovery solution, Multi-AZ alone is WRONG. The answer will involve Cross-Region Read Replicas, Aurora Global, or a backup/restore strategy.
NICE-TO-KNOW — Multi-AZ reduces backup I/O impact: AWS performs automated backups from the Multi-AZ standby, not the primary. This eliminates the I/O suspension (or reduction in performance) that occurs during backups on Single-AZ instances. This is a secondary benefit of Multi-AZ beyond high availability — occasionally appears in cost/performance optimization questions.
NICE-TO-KNOW — You can combine Multi-AZ AND Read Replicas: These features are not mutually exclusive. A production database can have Multi-AZ enabled (for HA/failover) AND Read Replicas deployed (for read scaling). This is a common architecture for high-traffic production workloads. Exam may present this as the correct answer when both HA and read scaling are required.
The #1 exam trap: Assuming the RDS Multi-AZ standby instance can serve read traffic. It absolutely cannot — it is invisible to applications and only activates during failover. Candidates who confuse Multi-AZ with Read Replicas will choose Multi-AZ to 'scale reads' or 'improve performance', which is always wrong. Remember: Multi-AZ = Availability (not performance), Read Replicas = Performance (not automatic HA).
CertAI Tutor · SAA-C03 · 2026-02-22
Services
Comparisons