AWS Certified Solutions Architect - Associate (SAA-C03) #12 Domain 3-4 High-Performing Architectures — Choosing a DB
Following #11 Storage, the last topic in the high-performing domain is choosing a database. The most frequent and most decisive divide in SAA’s DB questions is the difference between RDS’s Multi-AZ and read replicas. We start there.
RDS — managed relational database #
RDS offers MySQL , PostgreSQL , MariaDB , Oracle , and SQL Server as managed services. AWS handles backups, patching, and recovery. The core is two scaling/availability mechanisms, and their purposes are completely different.
| Aspect | Multi-AZ | Read Replica |
|---|---|---|
| Purpose | High availability/failover | Read load distribution |
| Replication method | Synchronous | Asynchronous |
| Standby instance | Takes no traffic normally (standby) | Takes read traffic |
| On failure | Automatic failover | Manual promote required |
| Cross-region | Usually same region | Cross-region possible |
- Multi-AZ — keeps a synchronously replicated standby in another AZ and switches over automatically when the primary fails. It’s for high availability, not for read performance. The standby takes no traffic normally.
- Read Replica — keeps an asynchronous replica to distribute read queries. It’s a scaling means for read-heavy workloads, and you can place it cross-region too, so it’s also used for DR and global reads. Note, however, that it’s not automatic failover.
This distinction is an exam staple. “Read load distribution” is the read replica; “high availability/automatic failover” is Multi-AZ. They’re sometimes used together to capture both availability and read scaling at once.
Aurora — cloud-native relational #
Aurora is a relational database that AWS rebuilt for the cloud, compatible with MySQL and PostgreSQL. Its key characteristics are as follows.
- Automatic storage scaling — storage grows automatically as data increases.
- 6 replicas stored across 3 AZs for high durability and availability.
- Up to 15 read replicas for read scaling.
- Aurora Global Database — replicates across regions with sub-second lag (used in #7 DR).
- Aurora Serverless v2 — automatically adjusts capacity to load (variable , intermittent workloads).
If the clue is “MySQL/PostgreSQL compatible yet higher performance and automatic storage scaling,” it’s Aurora.
DynamoDB — managed NoSQL #
DynamoDB is a fully managed NoSQL key-value/document database. It’s serverless, scales virtually without limit, and delivers single-digit millisecond responses (microseconds with DAX).
- Capacity modes — On-Demand (unpredictable traffic , no management needed) vs. Provisioned (predictable , cost-efficient).
- Global tables — multi-region active/active replication.
- DynamoDB Streams — capture data-change events (e.g., a Lambda trigger).
- TTL — automatic item expiration.
- DAX — the microsecond cache from #10.
If it’s “key-value, millisecond responses, unlimited scaling, no server management,” it’s DynamoDB. However, it’s unsuitable for a relational model centered on complex joins or transactions. Those workloads are RDS/Aurora.
Databases by purpose #
Beyond relational and NoSQL, there are workload-specific databases. These are the ones that appear on the exam.
| Workload | Service |
|---|---|
| Analytics/data warehouse (OLAP) | Redshift |
| In-memory cache | ElastiCache (#10) |
| Graph (relationship data) | Neptune |
| MongoDB-compatible document DB | DocumentDB |
| Time series | Timestream |
“Large-scale data analytics/aggregation queries (OLAP)” is not transactional RDS but Redshift. This distinction (OLTP vs. OLAP) comes up often.
Exam question patterns #
- “Read load distribution for a relational DB.” → Read Replica
- “High availability/automatic failover for a relational DB.” → Multi-AZ
- “MySQL compatible + high performance + automatic storage scaling.” → Aurora
- “Multi-region active/active relational.” → Aurora Global Database
- “Key-value, milliseconds, unlimited scaling, serverless.” → DynamoDB
- “Unpredictable NoSQL traffic, avoid capacity management.” → DynamoDB On-Demand
- “Large-scale analytics/data warehouse.” → Redshift
Common traps #
1) Trying to scale reads with Multi-AZ #
The Multi-AZ standby takes no traffic. Read scaling is the read replica.
2) Expecting automatic failover from a read replica #
A read replica is asynchronous and not an automatic switchover. Automatic failover is Multi-AZ.
3) Handling complex joins with DynamoDB #
DynamoDB is NoSQL. Complex relational joins and transactions are best with RDS/Aurora.
4) Handling analytics queries with RDS #
Large-scale analytics (OLAP) is Redshift, not RDS. RDS is for transactions (OLTP).
Wrap-up #
What this post locked in:
- RDS — Multi-AZ (high availability , automatic failover) vs. read replicas (read scaling , asynchronous , cross-region possible). Different purposes
- Aurora — MySQL/PostgreSQL compatible, automatic storage scaling, Global, Serverless v2
- DynamoDB — NoSQL key-value, serverless , unlimited scaling, On-Demand/Provisioned, global tables. Unsuitable for complex joins
- By purpose — analytics is Redshift (OLAP), graph is Neptune, documents are DocumentDB
With this, we finish the high-performing domain (24%, #9–12). We’ve laid out the options for boosting performance from compute → caching → storage → database.
Next — Domain 4-1 Cost Optimization #
The last domain is Cost Optimization (20%). We move on to designs that deliver the same result more cheaply.
In #13 Domain 4-1 Pricing Models we’ll reorganize EC2 purchasing options from a cost perspective (Reserved , Savings Plans , Spot), the cost structure of S3 and storage, data transfer costs, and architecture choices that reduce cost.