Determine High-Performing Database Solutions for SAA-C03
Study the Aurora, RDS, DynamoDB, read-replica, proxy, and caching choices that drive SAA-C03 database-performance questions.
Database questions on SAA-C03 often look like performance questions, but they are really access-pattern questions. The best answer usually comes from matching the workload to the right database type, replication model, cache layer, and connection behavior.
What AWS is explicitly testing
The exam guide points to caching strategies, data access patterns, capacity planning, database connections and proxies, engine choice, replication, and database type selection across relational, non-relational, and in-memory designs.
Database chooser
| Requirement | Strongest first fit | Why |
|---|---|---|
| Relational workload with managed HA and familiar engines | RDS or Aurora | Strong fit for SQL-centric transactional systems |
| Highly scalable key-value or document workload | DynamoDB | Fits low-latency non-relational access patterns |
| Read-heavy database pressure | Read replica plus cache review | Splits read load from the primary path |
| Repeated hot reads | ElastiCache | Offloads repeated reads before the database becomes the bottleneck |
Access-pattern questions that decide the answer
| Question | Why it matters on SAA-C03 |
|---|---|
| Is the workload relational or key-value first? | This often decides RDS or Aurora versus DynamoDB immediately |
| Is the bottleneck reads, writes, or connections? | Read replicas, ElastiCache, and RDS Proxy solve different problems |
| Does the system need strong SQL joins and transactions? | That usually keeps the answer in the relational family |
| Is the scale pattern unpredictable and huge? | That often pushes the design toward purpose-built managed NoSQL or caching layers |
The distinctions that matter most
- Multi-AZ is about availability.
- Read replicas are about read scaling and some DR patterns.
- RDS Proxy is about connection management.
- ElastiCache is about reducing repeated database work.
Those four ideas appear together constantly, and AWS counts on candidates to mix them up.
Example: design the access pattern into a DynamoDB table
1Resources:
2 OrdersTable:
3 Type: AWS::DynamoDB::Table
4 Properties:
5 BillingMode: PAY_PER_REQUEST
6 AttributeDefinitions:
7 - AttributeName: pk
8 AttributeType: S
9 - AttributeName: sk
10 AttributeType: S
11 KeySchema:
12 - AttributeName: pk
13 KeyType: HASH
14 - AttributeName: sk
15 KeyType: RANGE
What to notice:
- this is not just “create a table”
- the performance story is encoded in the key design
- SAA-C03 often rewards the database model that matches the access pattern up front, not the one with the most features
Failure patterns worth recognizing
| Symptom | Strongest first check | Why |
|---|---|---|
| Primary database CPU is fine but connections keep spiking | RDS Proxy or connection behavior | The issue may be connection churn, not raw query cost |
| Reads swamp the writer | Read replicas and cache path | This is a read-scaling question, not a Multi-AZ question |
| Query latency grows with scale in a key-value workload | Partition or access pattern design | Purpose-built databases still depend on correct key design |
| Repeated identical reads dominate load | Cache fit before engine change | The cheapest and fastest fix may be caching rather than migration |
Common traps
- choosing read replicas when the real problem is connection exhaustion
- using Multi-AZ as if it were a read-scaling feature
- moving to a new engine when the real fix is caching or access-pattern redesign
- choosing DynamoDB just because it is scalable even when the workload is strongly relational
Quiz
Continue with 3.4 Network Architectures to move from the data layer into routing, edge, and connection-path performance.