AWS Database Services for CLF-C02: RDS, Aurora, DynamoDB, ElastiCache, DMS

Every database question in CLF-C02 sits on one foundational choice: run the database engine yourself on an Amazon EC2 instance, or hand the operational work to an AWS managed service. Both are legitimate — the exam wants you to know why you would pick each.

Installing a database on EC2 is the self-managed path. You get full control: any engine, any version, any configuration flag, and operating-system access. Some organizations need this — a legacy engine that AWS does not offer as a managed service, a version pinned by a vendor's support contract, or custom OS-level agents and tuning. The cost of that control is that you are the database administrator. You provision the instance, install and patch the engine, patch the OS, configure backups, design high availability and failover, and scale capacity yourself. AWS manages nothing above the hypervisor; under the shared responsibility model, everything from the guest OS up is yours.

A managed database service such as Amazon RDS inverts that. AWS handles provisioning, engine patching, automated backups, and high-availability options for you, and you interact with the database endpoint rather than a server. You give up OS access and are limited to the engines and versions the service supports.

Use this trade-off list to answer exam items:

• Database on EC2: full control, any engine or version, OS access, custom configuration — but you patch, back up, secure, and scale it yourself.
• AWS managed database: AWS provisions, patches, backs up, and offers built-in high availability — less operational burden, less low-level control.

Read the requirement to see which side of the trade-off it sits on. A goal of reducing operational overhead or no longer patching database servers is met by a managed service. A hard need for OS-level access or an engine version no managed service offers can only be met on EC2 — and choosing EC2 means the team, not AWS, takes on OS patching, backups and failover. A managed service never takes over the application side either: the data model, the schema, the SQL queries and the decision about what data to store stay with the customer.

Amazon RDS (Relational Database Service) is the managed home for relational databases on AWS. A relational database stores data in structured tables with rows and columns, enforces a fixed schema, supports SQL queries, joins across tables, and transactions. It is the natural fit for workloads like order systems, financial records, ERP, and any application where data relationships and consistency matter.

RDS runs six familiar engines: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle, and IBM Db2. Every one of them is relational — non-relational engines such as MongoDB, Apache Cassandra or Redis are not RDS engines. Because the engines are standard, existing applications usually connect without code changes: you point them at an RDS endpoint instead of a server you maintain. AWS handles instance provisioning, engine and OS patching, automated backups with point-in-time recovery, and storage scaling, which is exactly the operational work you would otherwise do on EC2.

Two RDS features solve two different problems, and they are easy to mix up:

So a requirement for automatic failover is met by Multi-AZ, and a requirement to take heavy read queries off the primary is met by read replicas; a workload that needs both uses both. Neither a bigger instance class nor longer backup retention provides either one: a larger instance adds capacity to the same single point of failure, and backups restore data after a loss rather than failing over. (RDS also offers a newer Multi-AZ DB cluster deployment for MySQL and PostgreSQL with two readable standbys; the classic Multi-AZ DB instance described above is the one whose standby serves no traffic.)

Amazon Aurora is a relational database engine that AWS built specifically for the cloud, offered within the RDS family. It is compatible with MySQL and PostgreSQL — applications written for either engine can typically use Aurora without modification — but it is not simply hosted MySQL or PostgreSQL. AWS re-architected the storage layer to get cloud-scale performance and durability.

Three facts cover what CLF-C02 expects you to know:

• Higher performance: AWS positions Aurora as delivering several times the throughput of standard MySQL and PostgreSQL. It is the managed relational choice when an application needs MySQL or PostgreSQL compatibility and more performance than the standard engines give.
• Distributed, fault-tolerant storage: an Aurora cluster's storage volume automatically keeps six copies of the data across three Availability Zones — two copies in each AZ. That happens for every Aurora cluster, even one with a single DB instance, because the copies live in the shared storage layer rather than on extra database servers.
• Aurora Serverless: a configuration that automatically scales database capacity up and down with load — you do not choose or resize an instance, and capacity can drop very low (Aurora Serverless v2 can even pause at zero when idle). It suits idle-most-of-the-time, intermittent or unpredictable workloads.

Compare Aurora's storage with the standard RDS pattern, because the two are near-twins:

A cross-AZ read replica is not the same thing either: it copies data asynchronously to one more instance, and a self-managed MySQL server on EC2 with an EBS volume keeps its data in the one AZ where that volume lives. Plain RDS fits when the workload needs an engine Aurora does not speak — SQL Server, Oracle, MariaDB or Db2 — or simply a managed relational database. Aurora is still relational: tables, SQL, joins, and transactions all apply.

Amazon DynamoDB is AWS's fully managed, serverless NoSQL database. NoSQL databases drop the rigid table schema of relational systems in favor of a flexible schema: DynamoDB stores items as key-value pairs and documents, and different items in the same table can carry different attributes. You retrieve data primarily by its key rather than by joining tables with SQL, which lets the database scale horizontally to enormous sizes without slowing down.

DynamoDB's headline promise — and the exam's favorite phrase — is single-digit millisecond latency at any scale. Whether a table holds a thousand items or billions, and whether it serves ten requests a second or millions, read and write latency stays consistently low. That property makes DynamoDB the go-to for gaming leaderboards and player state, shopping carts, user profiles and session data, IoT telemetry, and mobile or web backends with unpredictable, spiky traffic.

Serverless is the second pillar: there are no database instances to choose, provision, patch, or scale. You create a table, and AWS handles all the infrastructure invisibly. Capacity can scale automatically with demand, and you pay for the throughput and storage you use. Contrast that with RDS and Aurora (outside Aurora Serverless), where you still pick and manage instance classes even though AWS operates them.

Recognize DynamoDB by its properties: key-value and document items, a flexible schema (only the key attributes are fixed; other attributes can differ item by item), no instances, and consistent millisecond latency at massive, spiky scale. It is the wrong fit when a workload needs SQL joins across many normalized tables or ad hoc relational reporting — that is relational territory. DynamoDB is a database, not a cache: microsecond reads of repeated results come from the in-memory services covered next.

The single most common Task 3.4 discrimination is Amazon RDS versus Amazon DynamoDB. Both are managed databases; the difference is the data model and the operational model. Run through this head-to-head until it is automatic:

• Data model: RDS is relational — structured tables, fixed schema, rows and columns. DynamoDB is NoSQL — key-value and document items with a flexible schema.
• Query style: RDS speaks full SQL with joins across tables and multi-row transactions. DynamoDB is accessed primarily by key lookups through its API.
• Scaling: RDS scales up (bigger instances) and scales reads with replicas. DynamoDB scales out horizontally and automatically to virtually any request volume.
• Infrastructure: RDS still exposes instances you size and choose. DynamoDB is serverless — no instances exist for you to manage at all.
• Latency profile: DynamoDB delivers consistent single-digit millisecond performance at any scale; RDS performance depends on instance size and workload.
• Typical workloads: RDS — e-commerce orders, financial and inventory systems, existing SQL applications being lifted to AWS. DynamoDB — leaderboards, session stores, carts, user profiles, IoT event data.

A realistic exam scenario: a startup is launching a mobile game that must store millions of player scores with consistent millisecond reads during global traffic spikes, and the team wants zero servers to manage. Every clause — flexible player data, massive scale, millisecond latency, serverless — points to DynamoDB. Change the scenario to an accounting application that joins customer, invoice, and payment tables with SQL transactions, and the answer flips to RDS. Read the data shape first; the service follows.

Memory-based databases hold data in memory (RAM) instead of reading it from disk, which lets them answer in microseconds to sub-milliseconds — faster than disk-based databases, including DynamoDB. AWS offers two, with different jobs.

Amazon ElastiCache is a managed in-memory cache. It runs three open-source-compatible engines: Valkey, Redis OSS, and Memcached. AWS handles the provisioning, patching, and node management (there is also a serverless option with no nodes to size). ElastiCache's classic role is a cache in front of another database: the application checks the cache first and only queries the slower database (RDS, for example) on a cache miss, storing the result in the cache for next time. Reads that hit the cache skip the disk-based database entirely, so response times fall to microseconds and the database's load drops. Common uses include caching query results, session stores for web applications, and real-time leaderboards.

Two other things are called caching or read scaling, and neither does what ElastiCache does:

• RDS read replicas are copies of the database, not caches. Every query sent to a replica is executed again against its disk-based storage, so an expensive query is still expensive — the work just moves off the primary. A cache stores the result and hands it back without running the query.
• Amazon CloudFront caches content delivered to end users — web pages, images, video, API responses — at edge locations close to those users. It sits between users and the application, not between the application and its database, so it does not keep database query results in memory for the application to read.

Amazon MemoryDB is a durable in-memory database, compatible with Valkey and Redis OSS, built to be the primary data store. It keeps in-memory speed but also writes data durably to a transaction log across multiple Availability Zones, so data survives node failures. The distinction is the role: ElastiCache is a cache alongside another data store; MemoryDB is the database itself.

One adjacent purpose-built service needs one-line recognition: Amazon Neptune is AWS's managed graph database for highly connected data — social networks, recommendations, and fraud rings — where queries traverse relationships several hops deep (for example, friend-of-friend recommendations).

AWS DMS moves a database's data; AWS SCT (or DMS Schema Conversion) converts its schema and code when the database engine changes. Task 3.4 names both tools, and the skill being tested is knowing which does what — and when you need both.

AWS Database Migration Service (AWS DMS) migrates data to AWS (and between databases) while the source database stays fully operational — applications keep reading and writing during the migration, so downtime is limited to a short cutover. A DMS task can do a full load of the existing data and then change data capture (CDC), continuously replicating ongoing changes so the target stays in sync until you switch over. DMS supports two migration shapes:

• Homogeneous migration: same engine on both sides — for example, on-premises MySQL to RDS for MySQL, or PostgreSQL to Aurora PostgreSQL (Aurora PostgreSQL is PostgreSQL-compatible). The schemas already match, so DMS alone is sufficient; adding a schema-conversion step only adds work.
• Heterogeneous migration: different engines — for example, Oracle to Aurora PostgreSQL, or SQL Server to Aurora MySQL. Table definitions, data types, views, stored procedures and functions differ between engines, so the schema must be converted before the data is loaded.

Schema conversion can be done two ways:

• AWS Schema Conversion Tool (AWS SCT) — a downloadable application that converts the schema and database code from the source engine's format to the target's and reports which objects need manual work.
• DMS Schema Conversion — the same kind of conversion as a managed feature inside the AWS DMS console, with no tool to install.

The two jobs stay separate: a DMS full-load + CDC task copies data and can create basic target tables, but it does not convert schema objects or code (views, stored procedures, functions, secondary indexes) from one engine to another, and SCT does not move data. Same engine = DMS alone. Different engines = convert the schema (SCT or DMS Schema Conversion), then migrate the data with DMS.

Two other AWS migration services look similar but solve different problems:

Pull the families together. On the exam, you identify the database from the data shape, the scale and latency needs, and the trigger words in the scenario:

Work scenarios in this order. First, classify the data: structured tables with relationships means relational; key-value items at huge scale means DynamoDB; a speed layer for existing data means in-memory. Second, check the operational ask: "no servers to manage" leans DynamoDB or Aurora Serverless; "full control and OS access" leans EC2-hosted. Third, scan for a migration angle: moving data means DMS; changing engines adds SCT or DMS Schema Conversion.

CLF-C02 will not make you configure any of these — it asks you to identify the right one from what the workload needs, which is what the table summarizes.