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.
On this page
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.
Bottleneck-first database tuning
The strongest answer usually comes from naming the real bottleneck before naming the service.
| Bottleneck | Strongest first lever | Why |
|---|---|---|
| Repeated identical reads | ElastiCache | Removes avoidable database work entirely |
| Relational read traffic overwhelming the writer | Read replicas or Aurora reader endpoints | Offloads read volume while preserving the primary write path |
| Connection storms from web or serverless tiers | RDS Proxy | Smooths connection churn without changing the engine |
| Storage throughput or latency limits on relational databases | Instance or storage configuration such as Provisioned IOPS where the workload fits | The issue may be capacity planning rather than query logic |
| Key-value scale with simple predictable access patterns | DynamoDB table and key design | Performance depends on model fit, not only on service choice |
Engine fit and migration fit still matter
SAA-C03 can also test whether you keep a workload in the right relational engine family instead of treating all relational answers as interchangeable.
| Requirement | Strongest first check | Why |
|---|---|---|
| Existing operational tooling and application assumptions already fit one SQL engine well | Homogeneous migration and same-engine fit | Staying in the same family can reduce migration risk and tuning surprises |
| Feature or extension requirements push toward a different engine family | Engine-specific requirement | The cheapest migration is not always the one with the fewest changes if it misses a hard requirement |
| Massive scale with managed relational behavior and fast reader growth | Aurora family fit | Often appears when AWS wants a more cloud-native relational answer |
Common high-performance relational pattern
flowchart LR
A["Application tier"] --> P["RDS Proxy"]
P --> W["Primary writer"]
A --> C["ElastiCache"]
A --> R["Read replicas or Aurora readers"]
What to notice:
- connection management, caching, and read scaling solve different performance problems
- adding read replicas does not reduce connection churn by itself
- adding a proxy does not reduce repeated read traffic by itself
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
Capacity planning is part of the answer, not an afterthought
The official task statement includes database capacity planning for a reason. SAA-C03 may describe the issue as poor throughput, storage latency, or scaling pain even when the engine family is already correct.
| Constraint | Strongest first check | Why |
|---|---|---|
| Relational storage latency under load | Storage configuration and IOPS fit | The bottleneck may be the storage profile rather than the engine family |
| Spiky or bursty relational reads | Cache plus read-scaling fit | Compute resizing alone may waste money without fixing the pattern |
| NoSQL performance degrades at scale | Partition key and access-pattern design | Purpose-built NoSQL still fails when the data model creates hot partitions |
| App tier scales, but DB connections do not | Proxy and connection pooling strategy | A scaling event can turn into a connection problem quickly |
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 |
| Storage-bound relational queries stay slow after query tuning | IOPS and storage-performance profile | Capacity planning can be the missing performance lever |
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
- assuming larger instances always solve a storage-throughput or connection-management problem
- choosing DynamoDB just because it is scalable even when the workload is strongly relational
Quiz
Loading quiz…
Continue with 3.4 Network Architectures to move from the data layer into routing, edge, and connection-path performance.