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.

If a question says the team wants to reduce operational overhead or stop patching database servers, the answer is a managed service. If it says the team needs OS-level access or an unsupported engine version, the answer is EC2.

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 familiar engines you may already use on-premises: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, and Oracle (RDS also offers Db2). 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 patching, automated backups with point-in-time recovery, and storage scaling options, which is exactly the operational work you would otherwise do on EC2.

Two RDS features appear on the exam at recognition level, and it pays to keep them straight:

• Multi-AZ deployment is for high availability. RDS keeps a standby copy of the database in a different Availability Zone and fails over to it automatically if the primary has a problem. The standby does not serve application traffic — it exists for resilience.
• Read replicas are for read scaling. RDS copies data to one or more replicas that your application can query for read-heavy traffic, taking load off the primary. Replicas can also be placed in other Regions.

Memorize the pairing: Multi-AZ = availability, read replicas = read performance. CLF-C02 loves to swap those two in the answer choices. If the scenario mentions structured data, SQL, transactions, or an existing MySQL/PostgreSQL/SQL Server/Oracle application that the team no longer wants to administer, the answer is Amazon RDS.

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 on equivalent hardware. When a question asks for the highest-performing managed relational option compatible with MySQL or PostgreSQL, Aurora is the answer.
• Distributed, fault-tolerant storage: Aurora automatically replicates data across three Availability Zones in a Region, keeping multiple copies of your data. Durability and availability are built into the storage layer rather than bolted on.
• Aurora Serverless: an on-demand configuration that automatically scales database capacity up and down based on load — you do not choose an instance size. It suits variable, intermittent, or unpredictable workloads, such as a development database used a few hours a day or an application with sharp traffic spikes.

How do you tell an Aurora question from a plain RDS question? Plain RDS is the answer when the scenario names an engine Aurora does not speak — SQL Server, Oracle, MariaDB — or simply asks for a managed relational database. Aurora is the answer when the scenario stresses MySQL or PostgreSQL compatibility plus superior performance, storage replicated across multiple Availability Zones, or a relational database that scales capacity automatically (Aurora Serverless). 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.

Lock in the trigger phrases. When a question says "key-value", "flexible schema", "serverless database", "millisecond latency at any scale", or "massive scale with consistent performance", the answer is DynamoDB. When it says SQL, joins, or complex transactions across related tables, DynamoDB is the distractor and a relational service is the answer. DynamoDB is a database, not a cache — sub-millisecond and microsecond latency requirements point to 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 guarantees 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.

The third database family holds data in memory (RAM) instead of on disk, trading durability guarantees for extreme speed. Reads served from memory take microseconds to sub-milliseconds — faster than even DynamoDB — which is why the exam ties this family to the words caching and lowest possible latency.

Amazon ElastiCache is the managed in-memory service you must know. It runs two popular open-source engines: Redis and Memcached. AWS handles the provisioning, patching, and node management, just as RDS does for relational engines. ElastiCache's classic role is as a cache in front of another database: your application checks the cache first, and only queries the slower disk-based database (RDS, for example) on a cache miss. That offloads read traffic, cuts latency dramatically, and can reduce database cost. Beyond caching, common uses include session stores for web applications, real-time leaderboards, and other workloads needing microsecond-to-sub-millisecond reads.

Amazon MemoryDB is the one-liner to recognize: a Redis-compatible, durable, in-memory database designed to serve as a primary database — in-memory speed with data persisted durably across multiple Availability Zones — whereas ElastiCache is positioned for caching alongside another data store.

One adjacent purpose-built service occasionally appears as an answer choice and only needs one-line recognition: Amazon Neptune is AWS's managed graph database for highly connected data such as social networks, recommendations, and fraud detection. Knowing what Neptune is stops it from working as a distractor.

Exam triggers for this section: "improve read performance of an existing database", "cache frequently accessed data", "session store", and "microsecond latency" all point to ElastiCache. "Redis-compatible durable primary database" points to MemoryDB. "Relationships between highly connected data" points to Neptune.

Task 3.4 explicitly names two migration tools, and the exam tests whether you know which does what — and when you need both.

AWS Database Migration Service (AWS DMS) moves the data. It migrates databases to AWS (and between databases) while the source database stays fully operational — applications keep reading and writing during the migration, so downtime is minimal. DMS can also run continuous replication, keeping a target in sync with a source after the initial load. It supports two migration shapes:

• Homogeneous migration: same engine on both sides — for example, on-premises MySQL to RDS for MySQL, or Oracle to Oracle. The schemas already match, so DMS alone is sufficient.
• Heterogeneous migration: different engines — for example, Oracle to Aurora PostgreSQL, or SQL Server to RDS for MySQL. The table definitions, data types, stored procedures, and other database code differ between engines, so the schema must be converted first.

That conversion is the job of the AWS Schema Conversion Tool (AWS SCT). SCT converts the schema and database code — tables, views, stored procedures, functions — from the source engine's format into the target engine's format, and reports which objects it can convert automatically versus which need manual work. SCT does not move your data; DMS does not convert your schema.

The pairing rule to memorize: DMS moves the data; SCT converts the schema. Same engine = DMS alone. Different engines = SCT first, then DMS. A typical exam item: a company wants to migrate its on-premises Oracle database to Aurora PostgreSQL with minimal downtime — which tools does it need? Different engines means SCT converts the schema, and DMS migrates the data while the Oracle source keeps running. Both tools, one answer choice.

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, converting between engines adds SCT.

Finally, keep one-line recognition ready for the rest of the portfolio: MemoryDB (durable Redis-compatible primary) and Neptune (graph). CLF-C02 will not make you configure any of these — it only asks you to identify the right one, and the trigger words in the table do exactly that.