Database
Managed relational, key-value, in-memory, and purpose-built databases, plus the caching and migration layers around them.
Amazon Aurora
AWS-built MySQL- and PostgreSQL-compatible relational database with self-healing storage spread across three AZs.
- An engine choice inside RDS — same console, backups, and patching, with AWS's own storage layer underneath
- Shared cluster volume: 6 copies across 3 AZs, auto-grows to 256 TiB, no disk to provision
- One writer, up to 15 readers; failover promotes a reader in under 60s — with no reader, expect ~10 minutes
- Serverless bills per second in ACUs (~2 GiB each, 0–256) and pauses at 0 when idle; Global Database adds up to 10 read-only Regions
Exam triggers
Phrases and scenarios that point here.
- "MySQL or PostgreSQL" + "highest availability" or "best performance" → Aurora, not RDS
- Must survive an AZ outage with no failover code written by the customer → Aurora cluster with readers in other AZs
- Global users need local read latency, or recovery from a Region-wide outage → Aurora Global Database
- Spiky, unpredictable, or idle-most-of-the-day database → Aurora Serverless
Not this service
- Oracle, SQL Server, MariaDB, or the cheapest managed SQL → RDS
- Key-value or document data, single-digit ms at any scale → DynamoDB
- Dashboards and analytics over billions of rows → Redshift
Use cases
- Production SaaS backend that must ride out an AZ failure — the cluster endpoint follows the new writer, the app just reconnects
- Read-heavy catalogs and internal dashboards — add readers and point them at the reader endpoint instead of buying a bigger writer
- Moving a self-managed MySQL or PostgreSQL app off EC2 with no driver or schema changes, purely to stop hand-managing replication and backups
- Dev, test, and internal tools that sit idle overnight — Serverless drops to 0 ACUs and wakes on the first connection in roughly 15 seconds
- Global apps writing in one Region while other Regions serve sub-second-stale local reads and double as a warm DR standby
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon DocumentDB
Fully managed, MongoDB API-compatible document database for JSON data.
- MongoDB API-compatible — existing MongoDB apps, drivers, and tools connect with no code changes
- Cluster = one write primary + up to 15 read replicas sharing one storage volume; failover to a replica is automatic
- Storage auto-grows in 10 GiB steps to 4 PiB, replicated 6 ways across 3 AZs — you're billed for one copy
- Two capacity modes: Serverless scales automatically for spiky traffic, provisioned instances for steady, predictable load
Exam triggers
Phrases and scenarios that point here.
- "MongoDB", "JSON documents", "flexible schema", "records with varying attributes" → DocumentDB
- "Move our self-managed MongoDB to AWS without rewriting the app" → DocumentDB, migrated with DMS
- Read traffic is swamping the primary → add read replicas (up to 15), don't just resize the instance
- "NoSQL at any scale" with no mention of MongoDB → DynamoDB, not DocumentDB
Not this service
- Serverless key-value at any scale with no MongoDB API requirement → DynamoDB
- Managed Apache Cassandra workload → Amazon Keyspaces
- Relationships and graph traversal (fraud rings, social graphs) → Amazon Neptune
Use cases
- Product catalogs where every category carries different attributes — a bike frame has geometry numbers, a jersey has sizes — and adding a field doesn't mean a schema migration
- Player and user profiles that keep growing: achievements, inventory, and settings all live in one document fetched in a single read
- Lifting a self-managed MongoDB replica set off EC2 or on-prem when the team wants the same queries and drivers but no more patching, sharding, or backup scripts
- Content and CMS backends — an article with its nested comments, tags, and metadata stored as one document instead of six joined tables
- Vector search for RAG applications, keeping embeddings beside the source documents so one database serves both retrieval and app data
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon DynamoDB
Serverless NoSQL key-value database with single-digit millisecond reads at any scale.
- Key-value and document store — you fetch items by key, you don't join tables; no fixed schema beyond the primary key
- Serverless and multi-AZ by default — nothing to size, patch, or fail over; data is replicated across AZs automatically
- Two capacity modes: on-demand (pay per request, spiky or unknown traffic) vs provisioned (set RCU/WCU, steady traffic)
- Limits: 400 KB max item size, PITR restore up to 35 days back, DAX adds a microsecond-latency in-memory cache
Exam triggers
Phrases and scenarios that point here.
- "NoSQL", "key-value", "single-digit millisecond", "serverless database" → DynamoDB, every time
- Unpredictable spikes with no capacity planning → DynamoDB on-demand mode
- Reads are already fast but need to be faster (microseconds) → put DAX in front, don't re-architect
- Active-active database in multiple Regions → Global Tables
Not this service
- Joins, complex SQL, or an existing relational schema → RDS or Aurora
- Files, images, anything over 400 KB → S3 (store the object there, keep the pointer in DynamoDB)
Use cases
- Session and shopping-cart state — one item per user, read on every page load, cleaned up automatically by TTL instead of a cron job
- Leaderboards and score tables, where traffic sits at zero and then jumps to a million writes the second a match ends
- Device or IoT state tracking — last known reading per device ID, written constantly, always read by key
- The default database behind API Gateway + Lambda, because Lambda has thousands of short-lived invocations and nothing to connection-pool against
- Order tracking for delivery or ride-hailing apps — order ID is the key, status updates overwrite in place, and Streams pushes each change out to the customer's app
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon ElastiCache
Fully managed in-memory cache (Valkey, Redis OSS, Memcached) that serves hot data in microseconds so your database doesn't have to.
- In-memory key-value store — a copy of hot data lives in RAM, so repeat reads never touch the database
- Memcached: simplest model, multi-threaded, no replication and no backups — lose a node and you lose that slice of cache
- Valkey / Redis OSS: replication, Multi-AZ auto-failover, backups, pub/sub, sorted sets — the default pick unless you genuinely want 'just a cache'
- Two ways to run it: Serverless (name it, it scales itself) or node-based clusters (you pick node type, count, and AZ placement)
- Nothing is cached automatically — your app decides what to store and for how long (TTL); the cache sits inside your VPC, never on the public internet
- Exam convention: questions still say "Redis vs Memcached". AWS now leads with Valkey, a Redis fork with the same API — for exam purposes, Valkey and Redis OSS are the same answer
Exam triggers
Phrases and scenarios that point here.
- "Microsecond latency", "in-memory", "read-heavy", "the same query over and over" → ElastiCache
- Database CPU pegged by repeated identical reads → put a cache in front, don't buy a bigger instance
- Session state must survive an instance being terminated → Valkey / Redis OSS, not Memcached
- "Simplest possible cache", "cache objects", "add and remove nodes as demand changes" → Memcached
- Leaderboards, live rankings, real-time counters → Valkey / Redis OSS sorted sets
Not this service
- Caching DynamoDB reads with no application changes → DAX
- Redis-compatible primary database that must not lose data → MemoryDB
- Caching static assets or API responses close to end users → CloudFront
- Scaling relational reads while keeping SQL → RDS read replicas
Use cases
- Sitting in front of RDS so the homepage's top-sellers query runs once a minute instead of ten thousand times
- Session store for a stateless web tier — any instance behind the load balancer can serve any user, and scaling in doesn't log anyone out
- Game leaderboards and live rankings, where a sorted set updates in microseconds and a SQL ORDER BY can't keep up
- API rate limiting — increment a counter key per user per minute and let the TTL clean it up for you
- Lift-and-shift for an app that already speaks Redis or Memcached: point it at the ElastiCache endpoint and ship, no rewrite
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon Neptune
Fully managed graph database for data whose value lives in the connections between things.
- Stores nodes, edges, and properties — 'friend of a friend of a friend' is one traversal, not three JOINs
- Query languages: Gremlin and openCypher (property graph), SPARQL (RDF) — no SQL
- Lives inside your VPC, no public endpoint; storage spans 3 AZs, self-heals, auto-grows 10 GiB → 128 TiB
- Up to 15 read replicas share one storage volume; failover to a replica typically completes in about 30 seconds
Exam triggers
Phrases and scenarios that point here.
- "Highly connected data", "relationships between entities", the word "graph" → Neptune, every time
- Social network, recommendation engine, fraud ring, knowledge graph → Neptune
- Query has to hop several levels deep (who knows who, who owns what) → Neptune, not recursive SQL
- Same person hiding behind 5 accounts, 2 devices, 3 emails → Neptune (identity resolution)
Not this service
- JSON documents, MongoDB-compatible → DocumentDB
- Key-value or wide-column lookups at massive scale → DynamoDB
- Tables, joins, SQL → RDS or Aurora
- Full-text search and log analytics → OpenSearch Service
Use cases
- Fraud rings: five 'unrelated' accounts that quietly share one device fingerprint and two phone numbers — obvious as a graph, invisible as rows
- Recommendations: "people who bought this also bought…" is a two-hop walk from product → buyers → their other purchases
- Identity resolution / customer 360: stitching one human together from email, phone, loyalty card, and device IDs
- Blast-radius mapping: if this switch dies, which apps go down? Walk the dependency graph three hops out instead of reading a wiki page
- Knowledge graphs behind GenAI apps, so the model answers from real relationships ("which suppliers feed this factory") rather than guessing
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon RDS
Managed relational database service — AWS runs the server, you run the schema.
- AWS handles provisioning, OS patching, backups, and failover — you get an endpoint, not a box. No SSH, no OS access
- Six engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2 — plus Aurora, AWS's own MySQL/PostgreSQL-compatible engine
- Multi-AZ = availability: synchronous standby in another AZ, automatic failover, serves zero read traffic
- Read replicas = scale: asynchronous, read-only, promoted manually — a different problem from Multi-AZ
- Limits: 35-day max automated backup retention, up to 15 read replicas per instance on most engines, encryption can only be turned on at creation, stopped instances auto-restart after 7 days
Exam triggers
Phrases and scenarios that point here.
- "Managed relational database", "minimize database admin overhead", "existing MySQL/PostgreSQL app" → RDS, not a database on EC2
- "Survive an AZ outage" → Multi-AZ. "Read-heavy" or "offload reporting" → read replicas. The exam swaps these two constantly
- "Restore to any point in the last N days" → automated backups. "Keep this copy indefinitely" → manual snapshot
- Needs OS-level access, a custom engine build, or an unsupported database → EC2, not RDS
Not this service
- Key-value or document data, serverless, single-digit-millisecond reads → DynamoDB
- MySQL/PostgreSQL-compatible but needs higher throughput or auto-scaling storage → Aurora
- Analytics and BI over billions of rows → Redshift, not a bigger read replica
Use cases
- Lifting a self-managed MySQL box off EC2 so nobody has to babysit patch nights, backup cron jobs, or replication setup again
- The transactional core of an ordinary web app — users, orders, payments — anywhere you need joins, foreign keys, and a transaction that rolls back cleanly
- Pointing the finance team's month-end reporting queries at a read replica so their giant SELECT doesn't slow down checkout
- Multi-AZ in production, Single-AZ in staging — same engine, same code, roughly half the bill where an hour of downtime is survivable
- Manual snapshot before a risky schema migration, so a bad ALTER TABLE at 2am is a restore instead of an incident
Commonly confused with
Verified against AWS documentation · 2026-09-09