High-Performing Databases: Aurora vs RDS, DynamoDB, DAX and ElastiCache

SAA-C03 rarely asks what a database service is; it describes how an application reads and writes, then asks which database fits. So the first skill is translating access patterns into database types. A relational database — Amazon RDS or Aurora — wins when the scenario needs transactions across multiple rows or tables, complex joins, ad hoc SQL queries, or an existing schema-driven application being lifted to AWS. A key-value database — DynamoDB — wins when access patterns are known in advance (get item by key, query by key and range), traffic must scale to millions of requests with consistent single-digit-millisecond latency, and the flexibility of ad hoc joins is not required. An in-memory store — ElastiCache, or DAX in front of DynamoDB — wins when the requirement is microsecond-to-sub-millisecond latency, almost always as a cache in front of another database rather than as the system of record.

Beyond those three, the exam expects recognition of the purpose-built engines: Amazon Neptune for graph workloads — social networks, fraud rings, recommendation engines, any scenario stressing "highly connected data" or "relationships between entities"; Amazon Timestream for time-series data — IoT sensor telemetry, metrics analyzed over time windows; and Amazon DocumentDB for MongoDB-compatible document workloads — the word "MongoDB" in the stem is the entire signal. You will not be asked to design with these; you will be asked to spot them among relational distractors.

One engine-level note from the guide: choosing between MySQL and PostgreSQL on RDS is usually decided by compatibility — a homogeneous migration (same engine, e.g., on-premises MySQL to RDS MySQL) is the low-friction default, while a heterogeneous migration (changing engines) adds schema conversion work and needs a strong reason.

The exam tests this section as elimination: a scenario with joins and transactions makes DynamoDB wrong no matter how attractive its scaling sounds, and a scenario with a fixed key-based access pattern at massive scale makes RDS the option that falls over first. Match the pattern before you compare features.

These two RDS features are confused by design in exam options, and the split is one sentence: read replicas are for performance; Multi-AZ is for availability. Everything else follows from how each replicates.

A read replica is a separate, readable database instance kept in sync by asynchronous replication. Because it is readable, you point read-heavy traffic at it — reporting jobs, dashboards, product-catalog reads — and the primary keeps its capacity for writes. Because replication is asynchronous, a replica can lag the primary by moments, so replicas suit reads that tolerate slight staleness. You can create multiple replicas per source, and replicas can live in another Region, which serves two purposes: low-latency reads close to remote users, and a disaster-recovery bonus, since a replica can be manually promoted to a standalone writable database. Applications must be written to send reads to the replica endpoints — RDS does not automatically split traffic for you.

A Multi-AZ deployment keeps a standby copy in a different Availability Zone using synchronous replication, and fails over to it automatically when the primary fails — the endpoint DNS repoints, and the application reconnects. The standby in the classic Multi-AZ instance deployment cannot serve reads. It adds zero read capacity and zero performance; what it buys is surviving an AZ failure or instance crash with minimal downtime and no data loss from the synchronous copy.

Production designs commonly use both: Multi-AZ for failover plus read replicas for scale. But the exam tests whether you keep the purposes straight. "Read performance is degrading" or "offload reporting queries" answered with Multi-AZ is wrong — the standby is not readable. "Survive an Availability Zone outage with automatic failover" answered with a read replica is also wrong — replication is asynchronous and promotion is manual. When a question stacks both requirements, the correct option is the one that uses each feature for its own job rather than stretching one to cover both.

Amazon Aurora is a MySQL- and PostgreSQL-compatible relational engine, and at the Associate level you need its performance architecture at decision depth, not internals depth. The core idea: Aurora separates compute from storage. Data lives in a shared, distributed storage volume that spans three Availability Zones (keeping six copies of your data), and every database instance — the writer and all readers — attaches to that same volume. Storage grows automatically as data grows, so there is no volume-sizing exercise.

That shared volume is why Aurora replicas behave differently from RDS read replicas. An RDS replica maintains its own copy of the data via asynchronous replication, so it lags. An Aurora replica reads the same shared storage as the writer, so replica lag is typically minimal, and you can run up to 15 replicas per cluster. Aurora exposes a reader endpoint that load-balances connections across all replicas automatically — your application uses one writer endpoint and one reader endpoint instead of juggling per-replica connection strings. Replicas double as failover targets: if the writer fails, Aurora promotes a replica quickly, so the same fleet serves both read scaling and high availability. AWS advertises substantially higher throughput than the community MySQL and PostgreSQL engines on equivalent hardware; treat that as directional — Aurora is the answer when a scenario needs a relational engine pushed harder than standard RDS comfortably goes.

Two extensions to recognize. Aurora Global Database replicates a cluster to secondary Regions with low, typically sub-second lag, giving remote users local reads and giving you a cross-Region DR path where a secondary Region can be promoted in minutes. Aurora Serverless v2 scales database capacity up and down automatically in fine-grained increments, fitting variable, spiky, or intermittent workloads — development environments, unpredictable new applications — where provisioning for peak wastes money.

The exam tests Aurora as a comparison: RDS MySQL with five lagging replicas versus Aurora with 15 low-lag replicas behind one reader endpoint; "global users, local read latency" pointing at Global Database; "unpredictable load, minimize cost and management" pointing at Serverless v2.

DynamoDB performance questions start with the capacity mode, because it decides both cost and behavior under load. Provisioned capacity means you declare read capacity units (RCUs) and write capacity units (WCUs) in advance. Requests beyond the provisioned rate get throttled — the application sees throughput-exceeded errors — so provisioned mode demands that you actually know your traffic. It is the cheaper mode for steady, predictable workloads running at healthy utilization, and auto scaling softens the planning burden by adjusting provisioned capacity between a floor and ceiling as consumption changes. Auto scaling reacts to observed traffic, though, so a sudden vertical spike can still throttle before capacity catches up.

On-demand capacity removes the declaration entirely: you pay per request, and the table absorbs traffic as it arrives, scaling instantly to workloads it has seen before and adapting quickly to new peaks. It is the answer for unpredictable, spiky, or brand-new workloads — "traffic patterns are unknown," "requests vary by orders of magnitude," "the team cannot forecast demand" are all on-demand signals. The trade-off is unit price: at sustained, well-utilized throughput, provisioned capacity costs less. Tables can switch between modes, so starting on-demand and moving to provisioned once traffic stabilizes is a legitimate design, not a trap.

The decision rule the exam rewards: predictable and sustained → provisioned (with auto scaling); unpredictable or spiky → on-demand. Cost qualifiers flip between them — MOST cost-effective for a steady workload is provisioned, while MOST cost-effective for an idle-then-bursty workload is on-demand, because paying for idle provisioned capacity is the waste.

Expect scenarios that describe throttling errors during a flash sale on a provisioned table (fix: on-demand mode, or auto scaling with honest limits), and cost-review scenarios where an over-provisioned table wants right-sizing. When throttling persists even though total provisioned capacity looks sufficient, capacity mode is not the culprit — partition key design is, which is the next section.

DynamoDB distributes a table's data and throughput across partitions by hashing the partition key. That makes key choice a performance decision: capacity is spread across partitions, so the table only delivers its full throughput when requests are spread evenly across many key values. A partition key with few distinct values, or one where a handful of values dominate traffic — today's date as the key, one celebrity user, one popular game — concentrates requests on a single partition. That is a hot partition, and it throttles even when the table as a whole has plenty of unused capacity. The signature in a question stem is exactly that contradiction: "the table is throttling although consumed capacity is well below provisioned capacity."

The fix is key design, not more capacity. Choose a high-cardinality partition key that traffic naturally spreads across (user ID, order ID rather than status or date), use a composite of attributes when no single attribute has enough spread, or apply write sharding — appending a random or calculated suffix to the key value so one logical hot key becomes many physical keys. Buying more RCUs/WCUs or switching to on-demand does not rescue a skewed key: the skew moves with it.

Secondary indexes let you query by attributes other than the primary key, and the exam wants the decision-level split. A global secondary index (GSI) defines a completely different partition key (and optional sort key), can be added to an existing table at any time, carries its own capacity settings, and serves eventually consistent reads. A local secondary index (LSI) keeps the table's partition key but adds an alternative sort key, must be created when the table is created, shares the table's capacity, and can serve strongly consistent reads. The practical rule: reach for a GSI — "query by a different attribute" almost always means GSI; an LSI is only right when you need an alternative sort order within the same partition key, decided it at table-creation time, and possibly need strong consistency on that index.

Exam questions here reward diagnosing the hot partition and rejecting the throw-capacity-at-it distractor.

Two caching decisions repeat across SAA-C03, and each compresses to a table. The first: DAX or ElastiCache? DynamoDB Accelerator (DAX) is a purpose-built, write-through cache that sits in front of DynamoDB and is API-compatible with it — the application swaps its client and keeps its code, and reads that hit the cache return in microseconds. DAX exists for exactly one job: accelerating read-heavy or bursty-read DynamoDB workloads, including absorbing hot-key read traffic. ElastiCache is the general-purpose in-memory cache: it fronts RDS, Aurora, or any backend — including application-level objects and session state — but the application must implement the caching logic itself (check cache, fall back, populate).

The second decision lives inside ElastiCache: Redis or Memcached? Redis is the feature-rich choice: data persistence via snapshots, replication with Multi-AZ automatic failover, rich data structures — sorted sets (the leaderboard answer), lists, hashes — plus pub/sub messaging. Memcached is the deliberately simple one: multi-threaded, scales horizontally by adding nodes, but offers no persistence, no replication, no failover — cached data on a lost node is simply gone.

The exam tests these as one-fact eliminations: "leaderboard" means Redis sorted sets; "cache must survive node failure" means Redis; "simplest cache for database query results, data loss acceptable" means Memcached; "microsecond DynamoDB reads without rewriting the application" means DAX, not ElastiCache.

Choosing the cache service is half the decision; the exam also tests how the cache is kept populated, at the level of two named strategies and their trade-offs.

Lazy loading (cache-aside) populates the cache only on demand: the application checks the cache, and on a miss it reads the database and writes the result into the cache for next time. Its strengths — only requested data occupies cache memory, and a cache node failure just means more misses, not an outage — come with two costs: a miss penalty (a miss takes three trips: cache, database, cache write) and staleness, because updates to the database do not touch cached copies until they expire. Write-through inverts this: every database write also updates the cache, so cached data is never stale and reads never pay a miss penalty for written data. Its costs: every write does double work, and the cache fills with data that may never be read. The reconciliation tool for both is the TTL — an expiry on each cached item. A TTL bounds how stale lazy-loaded data can get and evicts write-through data nobody reads; real designs typically combine lazy loading, selective write-through for read-critical data, and TTLs everywhere. The exam phrase "users see outdated data after updates" points at lazy loading without (or with too long) a TTL; "data must be current immediately after writes" points at write-through.

The other performance drag at the database boundary is connection churn. Serverless and highly concurrent applications — Lambda functions especially — can each open their own database connection, and thousands of short-lived connections exhaust RDS memory and connection limits. RDS Proxy sits between the application and the database, pooling and multiplexing connections so many application connections share few database connections; it also shortens failover impact by holding application connections while the database recovers. "Lambda functions are exhausting database connections" or "too many connections errors during traffic spikes" resolve to RDS Proxy — not a bigger instance, which just raises the ceiling on the same problem.

Task 3.3 frames capacity planning around one question: is the workload read-intensive or write-intensive? Reads scale by adding copies and caches: read replicas (or Aurora's reader fleet) absorb query load, and a cache — ElastiCache or DAX — absorbs repeated reads before they reach the database at all. Writes are harder, because every write must reach the system of record; caches do not help. Write-intensive designs scale by distributing writes — DynamoDB with a well-spread partition key is the canonical horizontally-scaling write store — by scaling the writer up (bigger instance class, or Provisioned IOPS storage when the bottleneck is disk I/O rather than CPU), or by buffering: putting an SQS queue in front of the database so a consumer writes at a steady, sustainable rate while spikes wait in the queue rather than overwhelming the writer.

Know the planning units at recognition level. For RDS and Aurora, capacity is the instance class (CPU and memory — memory-optimized classes suit large working sets and heavy query engines) plus the storage's IOPS; when a scenario says queries are slow and metrics show the disk is saturated, the answer is Provisioned IOPS storage, not a cache. For DynamoDB, capacity is RCUs and WCUs — and reads cost double when they are strongly consistent, so a stem that relaxes consistency to eventual is quietly halving read cost. Matching the fix to the measured bottleneck — CPU, memory, disk I/O, connections, or a single hot partition — is the skill; upgrading the wrong dimension is the standing distractor.

With that framing, most Task 3.3 questions reduce to a lookup from requirement phrase to feature:

The exam tests this table with qualifiers: two rows will both "work," and MOST cost-effective, LEAST operational overhead, or a latency number picks between them. Anchor on the latency and consistency words first — they eliminate fastest.

Scenario 1. An e-commerce application on RDS for MySQL is slowing down: the reporting team runs heavy analytical queries against the production database every hour, and page loads degrade during each run. The database must also remain available during maintenance. Options include enabling Multi-AZ, adding a read replica, or adding ElastiCache. What improves performance MOST directly?

Reasoning: Multi-AZ is eliminated first — its standby serves no reads, so it cannot relieve query load; it answers the availability sentence, not the performance one. Between a replica and a cache, look at the workload's shape: analytical reporting queries are heavy, varied, and not repeated identically, so a cache would miss constantly — caches pay off for repeated reads of the same data. A read replica is the answer: point the reporting tool at the replica endpoint and production reads never compete with reports again. Slight replica lag is acceptable for hourly reports. If the question had instead described the same product pages being read thousands of times per minute, ElastiCache with lazy loading and a TTL would win — repeated identical reads are exactly what caches absorb. Both features offload reads; the access pattern picks between them.

Scenario 2. A gaming backend stores player scores in a DynamoDB table with provisioned capacity, partition key game_id. During tournaments for a popular game, write requests are throttled — yet CloudWatch shows consumed capacity well below what is provisioned. What should the architect fix?

Reasoning: Throttling with headroom to spare is the hot-partition signature. All tournament writes carry the same game_id, so they hash to one partition, and that partition's share of the throughput is exhausted while the rest of the table idles. Adding capacity or switching to on-demand moves the ceiling but not the skew — the correct fix is partition key design: shard the hot key by appending a suffix (for example, game_id#1 through game_id#10) so writes spread across partitions, or re-key on a higher-cardinality attribute such as player_id.

Scenario 3. A startup is launching a new application on DynamoDB. Traffic is impossible to forecast and may spike by orders of magnitude after press coverage. Which capacity mode minimizes both throttling risk and idle cost?

Reasoning: Provisioned capacity requires a forecast the team does not have: set it high and pay for idle capacity, set it low and throttle during the spike, and auto scaling reacts too slowly for a sudden press-driven surge. On-demand is the designed answer — pay per request, no idle cost, immediate absorption of spikes. Once traffic settles into a steady pattern, switching to provisioned with auto scaling becomes the cost optimization, which is often the follow-up question.