Determine High-Performing Database Solutions

Core Idea

AWS gives you purpose-built engines (relational, key-value, document, in-memory, graph, time series, ledger) and removes undifferentiated ops work (provisioning, patching, backups). The exam wants depth beyond "pick a database" — it wants how these services actually behave under load.

Selection Drivers

Optimal database choice varies on: availability, consistency, partition tolerance, latency, durability, scalability, query capability. A recurring failure mode called out explicitly: teams pick a database by organizational default rather than by matching these requirements — don't do that on the exam either. Also consider non-database options (graph/time-series/in-memory stores) when they fit the access pattern better.

RDS Read Scaling

• Read Replicas: offload read traffic from the primary — a genuine performance lever.
• Multi-AZ: purely for availability; the standby is not directly accessible and adds no read performance. (Same distinction as in Domain 2 — it recurs because it's a favorite exam trap.)

Aurora vs. RDS — Architectural Differences, Not Just Marketing

• Aurora is part of the RDS family but architecturally distinct.
• Aurora = a cluster: one primary + zero-or-more read replicas.
• Aurora read replicas double as both read-offload and Multi-AZ-style availability — unlike vanilla RDS, where those are separate mechanisms (Read Replica vs. Multi-AZ).
• Aurora storage is a shared cluster volume, not per-instance local storage — this is why Aurora gets faster provisioning, better availability, and better performance than RDS.

Engine Selection Nuance

• Within relational, engine choice (e.g., PostgreSQL vs. MySQL) matters for scenario fit — don't assume "RDS" is a complete answer.
• DynamoDB vs. Aurora for consistent single-digit-millisecond latency at extreme volume: DynamoDB is the fit — consistent response times regardless of load, no tuning effort, SSD-backed, data replicated across multiple storage nodes by default. Also handles backups, point-in-time recovery, encryption at rest, and event-driven integration (react to table changes) natively.
• Regional failover with a relational engine: RDS MySQL is Region-bound (tolerates AZ loss only); Aurora Global Database is the answer when the requirement spans Regions.

Caching & Throughput Optimization

• ElastiCache: managed in-memory cache, two engines — Redis and Memcached.
• DynamoDB Accelerator (DAX): DynamoDB-specific accelerator, millisecond-to-microsecond reads, with item cache and query cache.
• RDS Proxy (again cross-referenced): purpose-built for compute like Lambda that opens many DB connections — pools established connections, reduces stress on DB compute/memory, supports high connection frequency/volume without hurting performance/scalability.

Capacity Planning

• Choosing the right instance type and size for a database is an explicit exam skill, not an afterthought.
• RDS storage auto-scaling: available for unpredictable workloads, but there's a subtlety — auto-scaling does not trigger if the increment needed would be equal to or exceed the configured maximum storage threshold. Know this edge case; it's exactly the kind of "gotcha" that shows up in a scenario answer.

Aurora Serverless

• On-demand, auto-scaling Aurora variant for infrequent, intermittent, or unpredictable workloads — cost-effective because compute scales to match usage and can shut down entirely when idle.
• Uses ACUs (Aurora Capacity Units) — you set a min/max ACU range and the cluster scales within it based on load.
• Still gets Aurora's underlying resilience: 6 copies of data across 3 AZs, same shared-cluster-storage model — provisioning is just handled differently (no manual instance sizing).
• Big cost feature: ACUs can scale to zero and pause after inactivity — while paused, you pay only for storage, not compute. This is the standout cost-optimization angle for Aurora Serverless specifically.

Exam Angle

Expect "Read Replica vs. Multi-AZ" trick questions (again), "DynamoDB vs. Aurora for extreme low-latency" scenario fit, "why didn't my RDS storage auto-scale" edge-case questions, and "unpredictable workload, minimize idle cost" pointing to Aurora Serverless.

Practical Examples

Picking a database by requirement, not habit: An IoT platform ingesting millions of sensor readings/second, needing consistent single-digit-millisecond writes at unpredictable scale → DynamoDB (key-value, near-infinite horizontal scale, no schema rigidity). A financial reporting system needing complex multi-table JOINs and strict ACID transactions → Aurora/RDS (relational). A social network's "who's connected to whom, 3 hops out" query → Amazon Neptune (graph) — none of these are interchangeable even though "just use RDS for everything" is the tempting default the lesson explicitly warns against.

Aurora replica doing double duty: An Aurora MySQL cluster has 1 writer + 2 reader instances. The readers simultaneously (a) serve read-heavy reporting queries offloaded from the writer, and (b) act as automatic failover targets if the writer dies — one Aurora replica gives you both benefits that in vanilla RDS would require a separate Read Replica and a separate Multi-AZ standby.

DynamoDB + DAX for a real-time bidding system: An ad-tech platform must respond to bid requests in under 10ms at massive scale. Base DynamoDB read latency (single-digit ms) is already close to the budget — adding DAX in front drops repeated key lookups to microseconds, buying back headroom for the rest of the request pipeline.

RDS storage auto-scaling gotcha, concretely: An RDS instance has 100 GB allocated with a 200 GB maximum, and auto-scaling configured to add storage in 20 GB increments once free space drops below a threshold. If usage suddenly jumps such that the next 20 GB increment would take it to 220 GB (over the 200 GB max), auto-scaling does not fire — the DB can still run out of space even with auto-scaling "on." The fix is raising the max threshold with headroom, not just trusting auto-scaling blindly.

Aurora Serverless v2 for a spiky internal tool: A monthly financial close process spins up heavy DB usage for 3 days, then the database sits nearly idle for the rest of the month. Running provisioned Aurora 24/7 means paying full price for 27 idle days. Aurora Serverless v2, configured with a low min-ACU and a higher max-ACU, scales up automatically during the close and back down (or to near-zero) afterward — you pay roughly for what you use.

RDS Proxy for a Lambda-heavy serverless backend: A serverless order-processing system fans out to dozens of concurrent Lambda invocations during a flash sale, each opening its own RDS connection — the DB's max-connections limit gets exhausted and new orders start failing. Inserting RDS Proxy between the Lambdas and RDS pools and reuses a small number of real connections regardless of how many Lambda invocations are in flight.