SAA-C03
Deep Dive
Database questions on the SAA-C03 usually test the difference between Multi-AZ (HA/failover) and Read Replicas (scaling reads). Aurora adds its own native layer of resilience. DynamoDB Global Tables for active-active multi-region.
Contents
This is the most important and most frequently tested distinction on the exam. Multi-AZ = High Availability. Read Replicas = scaling reads.They are not interchangeable.
| Feature | Multi-AZ | Read Replicas |
|---|---|---|
| Main purpose | Automatic failover (HA) | Scale read queries |
| Replication type | Synchronous (same time) | Asynchronous (eventual) |
| Automatic failover | Yes — ~60 seconds, DNS switch | No — manual or manual promotion |
| Can receive read traffic | No (standby is passive) | Yes — separate endpoint |
| Location | Another AZ in the same region | Another AZ, region or account |
| Maximum number | 1 standby | 5 (RDS), 15 (Aurora) |
| Cost | Double the instances/storage | One instance per replica |
| Exam usage | "If the primary instance fails..." | "High read traffic, dashboards, reports..." |
Exam trap question
"Does Multi-AZ improve read performance?"→ NO. The Multi-AZ standby replica is passive — it does not serve read queries. To scale reads, you need Read Replicas, not Multi-AZ.
Aurora reimagines database storage. Instead of a replicated EBS volume, Aurora uses a distributed storage cluster that automatically keeps 6 copies across 3 AZs.
Storage architecture
6 copies across 3 AZs
2 copies per AZ. Can lose up to 2 copies without losing write availability.
Write quorum
4 of 6 copies must confirm the write.
Read quorum
3 of 6 copies for a consistent read.
Self-healing
Detects and repairs corrupted blocks automatically.
Auto-scaling storage
Grows from 10GB to 128TB automatically with no downtime.
Aurora vs RDS comparison
Aurora Serverless v2
Automatically scales from 0.5 ACUs to 128 ACUs in fractions of a second. Ideal for unpredictable workloads, dev/test, applications that aren't used 24/7. Exam signal: "intermittent or unpredictable workload".
Features
Exam signals
DynamoDB is multi-AZ by default — data is automatically replicated across 3 AZs within a region. For global resilience, DynamoDB Global Tables extends this to multiple regions.
DynamoDB Global Tables
Active-active replicas across multiple regions. Writes accepted in any region. Asynchronous replication in <1 second.
Exam
"Global application that needs local writes in each region" → Global Tables.
Point-in-Time Recovery (PITR)
Restores the table to any point within the last 35 days. For recovering from accidental deletes or corruption.
Exam
"User accidentally deleted DynamoDB items" → PITR to restore.
DynamoDB Streams
Captures changes (inserts, updates, deletes) to the table in chronological order. Retained for 24 hours. Triggers Lambda.
Exam
"Process DynamoDB changes in real time" → Streams + Lambda.
On-Demand vs Provisioned
On-Demand: scales automatically, pay per request. Provisioned: you define RCUs/WCUs, cheaper for predictable load.
Exam
"Unpredictable or variable load" → On-Demand. "Stable load with cost savings" → Provisioned + Auto Scaling.
ElastiCache Redis
•Persistence (snapshots)
•Multi-AZ replication with failover
•Pub/Sub messaging
•Sorted sets, lists (complex data structures)
•Cluster mode: horizontal sharding
When to use
User sessions, gaming leaderboards, pub/sub, task queues, DB cache with persistence.
ElastiCache Memcached
•No persistence
•Multi-threaded (better for multi-core)
•Simple horizontal sharding
•No replication
•For simple objects in cache
When to use
Simple object caching with no need for persistence. When speed matters more than durability.
Sessions in stateless apps
If multiple EC2 instances handle requests, user sessions should not be stored in local memory. Use ElastiCache Redis for shared sessions — any instance can read the user's session. The exam calls this "stateless application design".
| Exam scenario | Service | Reason |
|---|---|---|
| Automatic failover in <60s | RDS Multi-AZ | Synchronous replica, automatic DNS failover |
| Scale thousands of read queries | RDS Read Replicas | Read load distribution |
| Maximum-performance MySQL/PostgreSQL | Aurora | 5x faster, 15 read replicas |
| Active-active global database | DynamoDB Global Tables | Writes across multiple regions |
| Unpredictable or intermittent DB load | Aurora Serverless v2 | Scales to 0, no capacity management |
| Microsecond latency for NoSQL | DynamoDB + DAX | DAX adds an in-memory cache in front of DynamoDB |
| Session cache with persistence | ElastiCache Redis | Persistence + Multi-AZ + complex data structures |
| Simple multi-threaded cache with no persistence | ElastiCache Memcached | Multi-threaded, simpler, no HA |
| Data warehouse for analytics | Amazon Redshift | Columnar, petabytes, BI tools |
| Full-text search | Amazon OpenSearch Service | Elasticsearch, integrated Kibana |
Did you get this topic?
Test what you just learned
An application has a Multi-AZ enabled RDS MySQL database. Reports run by the analytics team are degrading the performance of the main application. What is the most appropriate solution?
Put what you learned to the test with original SAA-C03 exam questions.
Start SAA-C03 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.