After this lesson, you will be able to: Choose the right AWS data service beyond RDS: DynamoDB for serverless NoSQL, Aurora for high-scale relational, and ElastiCache (Redis) for caching, and reason about when each fits.
RDS covers managed relational databases, but real AWS architectures reach for more: DynamoDB when they want a serverless key-value/document store that scales without thinking about servers, Aurora when they need relational at higher scale and availability, and ElastiCache when they need a microsecond cache in front of any of them. Picking the wrong one is one of the most expensive early architecture mistakes.
DynamoDB is a fully managed key-value and document database. You never provision a server; you define a table with a partition key (and optional sort key) and AWS handles scaling and replication. It delivers single-digit-millisecond reads at any scale, which is why it backs huge workloads. The catch: you must design around your access patterns up front, because querying efficiently requires the right keys and sometimes secondary indexes. It is not a relational database; joins and ad-hoc queries are not its game. Billing is on-demand (pay per request) or provisioned capacity.
You model the table around how you will read it, not around normalized entities.
// A single-table design keyed by access pattern// PK = partition key, SK = sort key// Get a user: PK=USER#123 SK=PROFILE// List a user's orders: PK=USER#123 SK begins_with ORDER#// Get one order: PK=USER#123 SK=ORDER#456import { DynamoDBClient } from "@aws-sdk/client-dynamodb";import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";const db = DynamoDBDocumentClient.from(new DynamoDBClient({}));// Fetch all of user 123's orders in one query (no join, no scan):await db.send(new QueryCommand({TableName: "app",KeyConditionExpression: "PK = :u AND begins_with(SK, :o)",ExpressionAttributeValues: { ":u": "USER#123", ":o": "ORDER#" },}));// NEVER use Scan for this in production: Scan reads the whole table.
Aurora is AWS's cloud-native relational engine, MySQL- and PostgreSQL-compatible, with storage that auto-grows, up to 15 read replicas, fast failover, and a serverless option (Aurora Serverless v2) that scales capacity with load. Reach for it when RDS's ceiling or failover speed is not enough and you still want SQL. ElastiCache is managed Redis (or Memcached): an in-memory store you put in front of a database to serve hot reads in microseconds, hold sessions, or back a rate limiter. It is the same Redis from the System Design caching lesson, run as a managed AWS service. Cache-aside is the usual pattern: check the cache, fall back to the database, write the result back to the cache.
Using DynamoDB Scan for queries; it reads the entire table and costs scale with table size. Design keys and query instead. Choosing DynamoDB for relational data with lots of joins, then reinventing joins in application code. Treating ElastiCache as durable storage; it is a cache and can evict. The database remains the source of truth. No cache invalidation strategy, so ElastiCache serves stale data after writes. Provisioned DynamoDB/Aurora capacity left high after a spike, quietly burning money. Use on-demand or autoscaling and set billing alarms.
Pick the best fit.
Sign in and purchase access to unlock this lesson.