AWS Certified Solutions Architect - Associate (SAA-C03) · High-Performing Storage, Compute, and Databases

High-Performing Database Solutions

~13 min

By the end of this lesson

Choose between Amazon Aurora, Amazon RDS, and Amazon DynamoDB for a given workload's data model and scale.
Choose a DynamoDB capacity mode and caching strategy for a given traffic pattern.

Choosing a database starts with the data model and the scale. Amazon RDS runs a familiar relational engine (MySQL, PostgreSQL, and others) as a managed service. Amazon Aurora is AWS's own MySQL- and PostgreSQL-compatible relational engine, built on a distributed storage layer replicated across three Availability Zones independently of compute — which is what lets an Aurora cluster support up to 15 low-lag read replicas. Amazon DynamoDB is a fully managed key-value and document database with single-digit-millisecond latency at any scale, for workloads that fit a simpler access pattern (fetch or write by key) rather than complex multi-table joins.

The dominant signal for which one fits: if the workload needs joins, transactions across many tables, or ad hoc queries, a relational engine (RDS or Aurora) is the natural fit. If the access pattern is predictable — look up an item by a known key, at very high and unpredictable scale — DynamoDB usually performs better and scales with less operational effort.

bash

aws dynamodb update-table \
  --table-name Orders \
  --billing-mode PAY_PER_REQUEST

Switch a DynamoDB table to on-demand capacity mode.

DynamoDB tables choose between two capacity modes. On-demand is serverless: DynamoDB scales instantly to any previously reached traffic level, bills per request, and needs no capacity planning — the default and recommended starting point, especially for unpredictable or spiky traffic. Provisioned capacity has you set read and write capacity units ahead of time; it costs less at a steady, predictable load, but under-provisioning it means requests get throttled.

Encryption ties back to a choice you already know from securing data: every DynamoDB table is encrypted at rest, using either an AWS owned key, an AWS managed key, or a customer managed KMS key — the same customer-managed-vs-AWS-managed tradeoff that applies to any AWS KMS key. A finance table with an auditor-mandated rotation schedule needs a customer managed key for exactly the same reason a finance dataset in general does: only a customer managed key lets you set your own rotation and deletion schedule.

When a hot set of read queries repeatedly hits the same rows — a product catalog, a leaderboard — Amazon ElastiCache can absorb that load in memory in front of RDS, Aurora, or DynamoDB. Lazy loading (cache-aside) only loads data into the cache when it's actually requested: check the cache first, and on a miss, read from the database and write the result into the cache for next time. It tolerates a completely empty cache node gracefully — every request just falls through to the database — but data can go stale until it's requested again. Write-through updates the cache every time the application writes to the database, so cached data is never stale, at the cost of writing data to the cache that might never be read, and failing outright if the cache node it's writing to is unavailable.

A cache node used for write-through caching goes down for 10 minutes. What happens to writes to the database during that window?Answer it yourself first, then open this.

They can fail outright, because write-through tries to update the cache on every write — unlike lazy loading, which only touches the cache on reads and keeps working with a downed or empty cache node.