Database Services: Choosing the Right Store

Domain 3 (Cloud Technology and Services) carries 34% of the CLF-C02 score, and inside it sits a task that is pure decision work: Task 3.4 "Identify AWS database services". Its five skill statements are short and blunt: "Deciding when to use EC2 hosted databases or AWS managed databases", identifying relational databases (Amazon RDS, Amazon Aurora), NoSQL databases (Amazon DynamoDB), memory-based databases (Amazon ElastiCache) and database migration tools (AWS DMS, AWS SCT). Every question built on this task has the same skeleton: a workload stem, four database names, and one right answer. The service names are easy; reading the stem is the exam.

In this lesson you will:

• sort every database question into the five buckets of Task 3.4;
• separate what Amazon RDS manages from what you still own;
• defeat the Multi-AZ versus read replica trap in both directions;
• compare RDS on EC2 versus self-managed using AWS's own responsibility table;
• place Amazon Aurora by compatibility, storage auto-scaling and replica count;
• size DynamoDB capacity in RCU and WCU, and pick the right capacity mode;
• one-line ElastiCache Redis OSS vs Memcached;
• separate OLAP from OLTP so Redshift stops being a distractor;
• place Neptune and DocumentDB from two-word stems;
• split a migration between AWS SCT (schema) and AWS DMS (data);
• run the workload → database decision table end to end;
• check the 2026 updates that touch databases: scope-list additions and removals, Database Savings Plans and the era-dependent Free Tier;
• study four AWS-published case studies (Netflix, Amazon Prime Video, Zendesk and Philip Morris International);
• practise with 14 exam-style questions plus four interactive checks.

---

1. Task 3.4: five buckets and one decision

1.1 The five skill statements, decoded

AWS writes the task as five bullets. Decode each into the one question it will ask you:

Two extra buckets are not named in the task statement but appear on the in-scope list: Redshift (placed under Analytics in the exam guide, taught here only for the warehouse-vs-transaction decision) and Neptune / DocumentDB (graph and MongoDB-compatible document stores).

1.2 The in-scope and out-of-scope lists

• 📚 Did you know? AWS's own "databases on AWS: how to choose" guidance (updated 2 June 2026) advertises 15+ database options, and the databases product page says 15+ database engines; while the CLF-C02 exam guide names six in-scope database services. The exam is not testing breadth; it is testing whether you can pick the six AWS cares about from a catalogue four times larger (as of Oct 2026; verify current before use).

1.3 Worked example E1: bucket a stem in one pass

Read the stem, underline the access pattern, then name the bucket:

The stem's verb is the whole question: aggregate ⇒ Redshift, traverse ⇒ Neptune, cache ⇒ ElastiCache, transact ⇒ RDS/Aurora, scale unpredictably ⇒ DynamoDB.

---

2. Amazon RDS: the managed relational default

2.1 What "managed" actually buys you

AWS defines Amazon Relational Database Service as a managed service that "manages backups, software patching, automatic failure detection, and recovery". The exam's version of this is a responsibility table, and AWS publishes one that compares on-premises, EC2-hosted and RDS-managed databases directly:

AWS's own conclusion is exam-relevant: "We recommend Amazon RDS as your default choice for most relational database deployments." Note the one row that never changes: application optimization (your schema, your queries, your indexes) is yours in all three columns. Shared responsibility for databases is not "AWS does everything".

2.2 Engines, instances and storage

This is the shape the exam means by relational: primary and foreign keys, rows in tables, and answers that come from joining them. The moment a stem says "the application must not JOIN" or "denormalise by design", you have left this diagram and entered NoSQL.

2.3 Multi-AZ vs Read Replicas: THE trap

This is the single most reliable question in the whole lesson, and AWS states the rule twice in the RDS User Guide: "The high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic. To serve read-only traffic, use a Multi-AZ DB cluster or a read replica instead."

Both features can coexist on the same source database: a Multi-AZ deployment for survival and a read replica for reporting. The trap works in both directions:

• "Increase read throughput / offload reporting" ⇒ read replica (Multi-AZ does nothing for reads);
• "Survive an Availability Zone failure with automatic failover" ⇒ Multi-AZ (a read replica fails over only if you promote it manually).

⚠️ Multi-AZ is not a scaling solution. AWS's wording is absolute: the high-availability option "isn't a scaling solution for read-only scenarios". Two nuances save marks: a Multi-AZ DB cluster (two readable standbys) does serve read traffic, and a read replica is asynchronous, so a replica can be stale, which is exactly why you must never route writes to one.

2.4 Worked example E2: the reporting spike

The primary MySQL database on RDS handles 400 writes/second. Month-end reporting runs 600 heavy SELECTs/second and the primary's CPU sits at 95%. Two options are proposed: enable Multi-AZ, or create a read replica. Which is correct, and why?

Flip the stem: "the database must survive an AZ outage with automatic failover" ⇒ Multi-AZ, because a read replica's promotion is manual and its replication is asynchronous.

2.5 RDS versus a self-managed database on EC2

Task 3.4 explicitly tests this choice. The deciding question is never "which is more powerful"; it is who does the undifferentiated work.

Worked example E3: choosing between RDS and EC2. Three stems, three verdicts:

1. "A team needs PostgreSQL with AWS-managed backups, patching and Multi-AZ failover, and has no unusual OS requirements." ⇒ Amazon RDS: every requirement is on RDS's managed list, and AWS recommends it as the default.
2. "A regulated workload requires a custom kernel module and full root access on the database host." ⇒ Database on Amazon EC2: RDS does not expose the operating system, so the requirement forces the EC2 route, and the team now owns patching, backups and HA.
3. "The same PostgreSQL workload, but the company already runs its own backup scripts and patch calendar and refuses to change them." ⇒ EC2-hosted is legitimate, but the exam's bias is stated by AWS itself: RDS is the recommended default, so a stem that mentions only convenience of habit is usually fishing for RDS.

2.6 Backups, patching and retention

Worked example E4: the failover budget. Application retry logic must be sized against the slowest documented failover, not the fastest:

A question that praises Aurora's "often less than 30 seconds" while your client timeout is 10 seconds is testing arithmetic, not marketing.

• 📚 Did you know? RDS Free Tier is time-boxed and account-age dependent: AWS documents 750 hours per month of a db.t3.micro or db.t4g.micro in Single-AZ, and that allowance applies to accounts created before 17 July 2025. Older accounts kept the classic 12-month Free Tier; newer accounts get the credit-based Free plan instead, so a stem quoting "750 hours of db.t3.micro" is era-dependent (as of Oct 2026; verify current before use).

---

3. Amazon Aurora: the MySQL/PostgreSQL-compatible high performer

3.1 Compatibility and the shared cluster volume

AWS describes Aurora as compatible with MySQL and PostgreSQL, and it is provisioned and administered through the same RDS console, CLI and API, provisioning, patching, backup and failure detection all behave like RDS. The difference is the storage layer: Aurora uses a single cluster volume whose data is replicated across three Availability Zones, and that volume is independent of the database instances attached to it. Adding a reader therefore does not copy the data, the instance simply attaches to the existing volume.

3.2 Aurora vs RDS: the two-word tie-breaker

Worked example E5: storage ceilings as a decision. Three requirements, three services:

• 📚 Did you know? Aurora's I/O-Optimized configuration has a published break-even: AWS advises switching when your I/O spending reaches 25% or more of your Aurora DB instance spending. It is one of the few database cost thresholds AWS states numerically, and like every figure in this lesson, it is as of Oct 2026 and should be re-verified before you rely on it in production.

---

4. Amazon DynamoDB: serverless NoSQL at single-digit milliseconds

4.1 What it is, and what it refuses to be

AWS's definition is the exam's definition: DynamoDB is "a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale", supporting both key-value and document data models. Read the fine print, because it generates distractors:

4.2 Capacity modes: the second most-tested database fact

4.3 Worked examples: the arithmetic the exam actually uses

Worked example E6: provisioned sizing (AWS's own worked pattern, as of Oct 2026).

Worked example E7: mode economics. A table provisioned with 100 RCU + 50 WCU:

Worked example E8: burst headroom. The previous traffic peak on an on-demand table was 50,000 reads/second. AWS documents that on-demand can instantly scale to twice the previous peak:

4.4 When the exam picks DynamoDB

Two DynamoDB satellites also appear:

• Amazon DynamoDB Accelerator (DAX): an in-memory cache for DynamoDB only, API-compatible, delivering "up to 10 times" faster reads and moving latency "from milliseconds to microseconds". The stem is read-heavy repeated-key hotspots on a DynamoDB table.
• Global tables: multi-Region, multi-active, 99.999% availability SLA with no primary table to fail over. The stem is geographic distribution.

DAX fixes latency; global tables fix geography. Confusing them is a reliable way to lose a mark.

---

5. Amazon ElastiCache: the in-memory layer

5.1 What it is

AWS defines ElastiCache as "a distributed in-memory data store or cache environment" that works with the Valkey, Memcached and Redis OSS engines, and AWS's choosing guidance puts a number on it: microsecond reads and sub-millisecond writes as an ephemeral cache. That last phrase is the whole exam position: ElastiCache accelerates a primary database; it is never the system of record.

5.2 Redis OSS vs Memcached: the one-liners

Worked example E9: choosing the cache engine.

⚠️ ElastiCache is never the answer to "where is the data stored durably?" It is an ephemeral cache. If the stem needs a durable primary database, the answer is RDS, Aurora, DynamoDB or DocumentDB, and if it asks for a durable in-memory database, the marketing-page option is Amazon MemoryDB, which is out of scope for CLF-C02 and therefore never correct.

---

6. Amazon Redshift: the warehouse, not the transaction

6.1 The OLAP vs OLTP trap

AWS defines Amazon Redshift as a "fully managed, petabyte-scale data warehouse" that is "specifically designed for online analytic processing (OLAP)". The trap is that both halves of the pair are databases, both answer SQL questions, and only one of them is right for your stem.

AWS also states that OLTP features such as secondary indexes and efficient single-row data manipulation operations have been omitted from Redshift. That is the tell: a database that deliberately removed single-row manipulation is not where you put a shopping cart.

Worked example E10: the two-column question.

6.2 Redshift Spectrum

AWS documents that Redshift Spectrum lets you "query data directly from files on Amazon S3" using servers independent of your cluster. The exam-visible consequence: you can query the warehouse and the data lake in one SQL statement without paying for extra cluster nodes to hold the lake data.

• 📚 Did you know? The exam guide files Amazon Redshift under Analytics, not under Database, yet Task 3.4 still expects you to make the warehouse-vs-transaction decision. Category placement is a metadata detail, never a reason to rule an in-scope service out of an answer (as of Oct 2026).

---

7. Amazon Neptune and Amazon DocumentDB: the two specialised stores

7.1 Neptune: the graph answer

AWS describes Amazon Neptune as a "fully managed graph database service" that handles billions of relationships with milliseconds latency, supporting Gremlin and openCypher for property graphs and SPARQL for RDF, with up to 15 Neptune Replicas on a shared three-AZ volume and automatic failover.

The graph stores answer a question a relational schema answers slowly: as the number of hops grows, the JOIN count explodes, while Neptune walks the edges directly. That trade is the entire justification for the graph bucket.

7.2 DocumentDB vs DynamoDB: the MongoDB tie-breaker

Rule of thumb: the word MongoDB ⇒ DocumentDB; the words serverless, capacity mode or single-digit millisecond ⇒ DynamoDB.

---

8. Migration: AWS Schema Conversion Tool and AWS Database Migration Service

8.1 The split you must memorise

Both tools sit in the exam guide's Migration and Transfer category, and the exam has never asked about them without testing the division of labour:

A third answer is a distractor catcher: "rehost whole servers or VMs" is the AWS Application Migration Service, not a database tool at all.

8.2 Worked example E11: an Oracle exit

An insurance company runs Oracle Database on-premises with 400 PL/SQL procedures and wants Amazon Aurora PostgreSQL, with minimal downtime. Sequence the tools:

---

9. The decision table: workload → store

9.1 One table for the whole task

9.2 Worked example E12: one stem, two wrong answers each time

"A food-delivery startup needs: (a) order records with joins to restaurants and drivers, (b) a driver-location feed keyed by driver ID with extreme spikes at dinner time, (c) a session cache returning in under a millisecond, and (d) a quarterly analytics warehouse."

---

10. Staying current: what changed for databases

2026 Updates (as of October 2026)

• 📚 Did you know? The current in-scope list is officially labelled "non-exhaustive and subject to change" and carries no version number at all: the only stamped artefact AWS ever published for this exam is the launch-era Version 1.0 CLF-C02 guide, while today's PDF prints nothing but "Copyright © 2026", and the uiVersion=2024.10 string on the docs page is the AWS Docs site template version, not a guide revision. That is precisely why every figure in this lesson is dated "as of Oct 2026": with no changelog to cite, the access date is the version (exam guide landing page and PDF, accessed 2026-10; verify current before use).

---

Real-World Case Studies

AWS publishes what these patterns look like in production. Every figure below is customer- or AWS-claimed and unaudited, quoted with its source so you can check it: the examinable point is the pattern (which store was chosen, which limit it removed, which number moved), not the marketing.

Case A, Netflix: consolidating relational infrastructure on Amazon Aurora

Exam lesson: "up to 75%" is a ceiling, not a promise, and it is a customer result. What transfers to exam day is the shape of the decision: a team with a large relational estate chose a managed MySQL/PostgreSQL-compatible service rather than staying on self-managed instances.

Case B, Amazon Prime Video: DynamoDB behind a live sports peak

Exam lesson: the operation worth memorising is unglamorous: partitions were doubled from the console before the spike. Capacity for a known event was arranged deliberately, which is precisely the difference between a planned provisioned change and the automatic burst of on-demand capacity.

What the two cases share

Case C, Zendesk: better price-performance on the same Aurora engine

Exam lesson: up to 42% is Zendesk's ceiling, not an AWS guarantee, attribute it as a customer result with its access date. The transferable move is the ordering: before you change database products, exhaust instance class, processor architecture (Graviton) and right-sizing, and remember AWS's standing caveat that Graviton requires code or container-image compatibility work first.

Case D, Philip Morris International: Amazon RDS as the landing zone for 400 applications

Exam lesson: AWS's own page admits the initial aggressive "lift and shift" "yielded suboptimal results", the savings appeared when workloads were replatformed onto managed services. That is the 6 Rs in one story (rehost first, replatform after), and the database choice is part of the migration strategy, not a footnote. Keep the qualifiers: "up to 50% savings on some RDS costs" is scoped and customer-claimed, never restate it as an RDS price cut.

What Cases C and D add

• 📚 Did you know? Capital One's "all in on AWS" estate names Amazon RDS among the 30+ AWS services it runs, and the bank reports building 80% of its nearly 2,000 applications cloud-native while cutting the time needed to build a development environment from 3 months to minutes (aws.amazon.com Capital One case-study pages, accessed Oct 2026). At that scale the managed-database argument in §2.1 stops being a convenience: when AWS owns patching, backups and failure detection, a fresh development environment, including its database, becomes a minutes-long task instead of a hardware-and-licence project.

• 📚 Did you know? AWS's own "how to choose a database" page illustrates the mixed estate with AWS's e-commerce stack: Amazon DocumentDB for the catalog, Amazon DynamoDB for browsing and cart, and Amazon Aurora for relational order data (aws.amazon.com/databases, updated 2 June 2026). One retailer, three database engines, each chosen by access pattern; which is the whole argument of this lesson, made by AWS about its own storefront.

---

Practice Questions