While preparing for the AWS SAA-C03, many candidates get confused by Multi-AZ vs. Read Replicas. In the real world, this is fundamentally a decision about Read Scalability vs. High Availability. Let’s drill into a simulated scenario.
The Scenario #
GlobalMart, an e-commerce company, runs a product catalog application accessed by employees at their corporate headquarters. The product inventory data—including SKUs, pricing, stock levels, and supplier information—is stored in an Amazon RDS MySQL database instance.
Recently, the operations team noticed significant performance degradation during peak hours (9 AM - 11 AM and 2 PM - 4 PM). After monitoring, they identified that read-heavy queries (product searches, reporting dashboards) are competing with write operations (inventory updates, price changes) on the same database instance.
The DevOps team needs to quickly optimize application performance by separating read and write traffic without major application refactoring.
Key Requirements #
Rapidly improve database performance by isolating read traffic from write traffic, while maintaining operational simplicity.
The Options #
- A) Modify the existing database to a Multi-AZ deployment. Route read requests to the primary Availability Zone.
- B) Modify the existing database to a Multi-AZ deployment. Route read requests to the standby Availability Zone.
- C) Create a read replica of the database. Configure the read replica’s compute and storage resources to half the capacity of the source database.
- D) Create a read replica of the database. Configure the read replica’s compute and storage resources to match the source database.
Correct Answer #
Option D — Create a read replica with compute and storage resources matching the source database.
Step-by-Step Winning Logic #
This solution addresses the core requirement through three architectural principles:
-
Read Replica Purpose-Built for Read Scaling
RDS Read Replicas use asynchronous replication to create readable copies of your database. Applications can route SELECT queries to replicas, immediately reducing load on the primary instance. -
Compute Parity Prevents Bottlenecks
If the primary database is experiencing read contention, offloading reads to a smaller replica (Option C) would just shift the bottleneck. The replica must handle the same (or greater) read volume, requiring equivalent compute capacity. -
Operational Speed
Creating a Read Replica is non-disruptive (no downtime) and takes minutes, versus Multi-AZ conversion which requires brief maintenance windows.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
Why not Option A? #
“Multi-AZ with reads from the primary AZ”
- Trap: This doesn’t solve anything—you’re still reading from the same overloaded primary instance.
- Reality: Multi-AZ creates a standby in another AZ, but it’s a passive replica for disaster recovery, not read offloading.
Why not Option B? #
“Multi-AZ with reads from the standby AZ”
- Fatal Flaw: The Multi-AZ standby is NOT accessible for read traffic. It’s synchronized via synchronous replication but remains in standby mode until failover.
- Common Misconception: Many candidates think “standby = readable backup,” but AWS explicitly blocks connections to Multi-AZ standbys.
Why not Option C? #
“Read Replica with half the resources”
- Undersizing Risk: If the primary’s read load is causing performance issues, a replica with 50% capacity will struggle with the same queries.
- Cost False Economy: You save ~$200/month but still experience slow queries—defeating the entire purpose.
- When It Works: Only viable if you’re offloading a small subset of read traffic (e.g., analytics queries representing <30% of load).
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
Users[Corporate Users
HQ Network] -->|Write Traffic| Primary[RDS MySQL Primary
db.m5.large
Multi-AZ Enabled]
Users -->|Read Traffic| Replica[RDS Read Replica
db.m5.large
Same Region]
Primary -.->|Asynchronous
Replication| Replica
Primary -.->|Synchronous
Replication| Standby[Multi-AZ Standby
NOT Readable]
style Primary fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style Replica fill:#3F8624,stroke:#232F3E,stroke-width:2px,color:#fff
style Standby fill:#666,stroke:#232F3E,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
classDef userStyle fill:#0073BB,stroke:#232F3E,color:#fff
class Users userStyle
Diagram Note: Write traffic continues to the primary instance (which replicates to a standby for HA), while read traffic is redirected to the Read Replica. The standby remains inaccessible for queries.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | RDS Feature | Est. Monthly Cost* | Read Scalability | Downtime | Complexity | Cons |
|---|---|---|---|---|---|---|
| A | Multi-AZ (reads from primary) | +$180 | ❌ None (same instance) | ~5 min (conversion) | Low | Doesn’t solve read contention |
| B | Multi-AZ (reads from standby) | +$180 | ❌ INVALID (standby not readable) | ~5 min | Low | Architecturally impossible |
| C | Read Replica (half-sized) | +$90 | ⚠️ Partial (bottleneck risk) | Zero | Low | Undersized—likely still slow |
| D ✅ | Read Replica (matched sizing) | +$180 | ✅ Full offload capability | Zero | Low | Higher cost than Option C |
Cost Basis: db.m5.large in us-east-1 (~$180/mo). Multi-AZ adds standby instance (+100%). Read Replica adds separate instance (100% or 50% for half-sized).
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the AWS SAA-C03, always pick Read Replicas when you see:
- “Separate read and write traffic”
- “Read-heavy workload”
- “Offload reporting queries”
Never use Multi-AZ standbys for read scaling: they’re for failover only.
Real World #
In production environments at scale, we typically:
-
Start with Option D for immediate relief (as per the exam scenario).
-
Evolve to Multiple Read Replicas across different instance sizes:
- Large replica (same size as primary) for mission-critical dashboards
- Medium replicas for background analytics (acceptable lag tolerance)
-
Introduce Amazon Aurora if read scaling needs exceed 5 replicas:
- Aurora supports up to 15 read replicas with <10ms replication lag
- Aurora Auto Scaling can automatically add/remove replicas based on CPU load
- Cost optimization: Aurora’s storage auto-scales, eliminating over-provisioning
-
Add ElastiCache (Redis) for frequently accessed product catalog data:
- Cache popular SKU queries with TTL of 5-15 minutes
- Reduces RDS read load by 60-80% for catalog reads
- FinOps impact: Redis cluster (
$50/mo) vs. adding 3 more Read Replicas ($540/mo)
-
Application-side query optimization:
- The real-world performance issue often stems from missing indexes or N+1 query patterns
- Read Replicas are infrastructure band-aids—fix the SQL first
The Trap in Production: Teams often create Read Replicas without updating application connection logic. The replica sits idle while the primary still suffers. Always implement read/write splitting at the application or middleware layer (e.g., using AWS RDS Proxy or ProxySQL).