examhub .cc The most efficient path to the most valuable certifications.
Vol. I
In this note ≈ 21 min

Database Services (RDS, Aurora, DynamoDB, DMS)

4,120 words · ≈ 21 min read

AWS database services span fully managed relational engines such as Amazon RDS and Amazon Aurora, purpose-built NoSQL engines such as Amazon DynamoDB, in-memory caches such as Amazon ElastiCache and Amazon MemoryDB for Redis, specialty engines for graph (Amazon Neptune), analytics (Amazon Redshift), document (Amazon DocumentDB), and time-series (Amazon Timestream) workloads, plus migration tooling delivered by AWS DMS and the AWS Schema Conversion Tool. For CLF-C02 task statement 3.4, you need to know the category each service belongs to, the representative use case, and the main trade-offs between Amazon RDS, Amazon Aurora, and Amazon DynamoDB. This guide walks through every AWS database service in scope, compares the common trap pairings, and closes with scenario practice prompts, memorize callouts, and FAQs tailored to the CLF-C02 exam blueprint.

What Are AWS Database Services?

AWS database services are a portfolio of purpose-built, fully managed data stores that remove the operational burden of running databases on self-managed infrastructure. Instead of provisioning EC2 instances, installing a database engine, patching it, configuring backups, and building high availability from scratch, you can pick an AWS database service that matches your workload shape: relational, key-value, document, graph, columnar analytics, in-memory, or time-series. The CLF-C02 exam expects you to recognise each service, know whether it is relational or non-relational, and match it to a scenario prompt.

Amazon RDS is the flagship managed relational database. Amazon Aurora is the AWS-native relational engine built on top of the RDS platform. Amazon DynamoDB is the flagship managed NoSQL service. AWS DMS is the migration tool that gets existing databases into any of those AWS database services with minimal downtime. Together, RDS, Aurora, DynamoDB, and DMS cover most exam questions, while ElastiCache, Neptune, Redshift, DocumentDB, Timestream, and MemoryDB appear as distractor options in scenario questions.

Why AWS Database Services Exist

On-premises databases require capacity planning, licensing, patching, backup tape rotation, and manual failover rehearsals. Moving to AWS database services converts these capital expenses and labour hours into a pay-as-you-go operational cost. AWS database services are also integrated with AWS Identity and Access Management, Amazon CloudWatch, AWS Backup, and AWS Key Management Service, so security, observability, and data protection work consistently across Amazon RDS, Amazon Aurora, Amazon DynamoDB, and the AWS DMS pipeline.

Where This Topic Sits in the CLF-C02 Blueprint

Task statement 3.4 in the AWS CLF-C02 exam guide asks you to identify AWS database services. This topic lives inside Domain 3 (Cloud Technology and Services, 34% of the exam). You will face scenario questions that ask you to pick between Amazon RDS, Amazon Aurora, and Amazon DynamoDB, plus recall questions that ask which AWS database service handles a specific workload — for example graph traversal (Amazon Neptune) or time-series telemetry (Amazon Timestream).

Plain-Language Explanation: AWS Database Services

If the service names still feel abstract, these three analogies reframe AWS database services in everyday terms. Use whichever one sticks in your memory best when you see an AWS database services scenario question on exam day.

Analogy 1: The Restaurant Kitchen

Think of AWS database services as different kitchens inside a giant food court. Amazon RDS is a well-equipped European kitchen where the chef still cooks personally but the dishwasher, ventilation, and pantry restocking are handled by the building. Amazon Aurora is the chef's own signature kitchen engineered by AWS: it runs five times faster than a standard MySQL kitchen and three times faster than a standard PostgreSQL kitchen because the storage layer is rebuilt for cloud scale. Amazon DynamoDB is a ramen vending machine — no chef, no menu negotiation, you pick a key and get your bowl in single-digit milliseconds. Amazon ElastiCache is the pass-through window that keeps ready-made dishes warm so hungry diners do not wait for the kitchen. AWS DMS is the moving company that relocates the entire restaurant from the old building to the food court without making customers skip a meal.

Analogy 2: The Public Library

Imagine the library is your organisation's data. Amazon RDS is the reference section where books are organised on shelves with a strict Dewey Decimal index — perfect for SQL queries across structured tables. Amazon Aurora is the same reference section but with AWS-designed robotic shelving that retrieves five books at once. Amazon DynamoDB is the coat-check room: give me a ticket number (the partition key) and I return your item instantly without caring what is inside. Amazon Redshift is the archive basement where historical newspapers are scanned so researchers can run analytical queries across decades. Amazon Neptune is the genealogy room where family trees connect people through relationships. Amazon DocumentDB is the magazine rack where each issue is a self-contained document. AWS DMS is the moving crew that transports the old library's contents into the new branch while patrons keep borrowing books.

Analogy 3: The Open-Book Exam

Picture your application as a student taking an open-book exam. Amazon RDS is the bound textbook: every page is indexed, cross-references are guaranteed consistent, and you can answer essay questions that require joining chapters. Amazon Aurora is the same textbook printed on faster paper — same table of contents, but you flip pages quicker. Amazon DynamoDB is the cheat-sheet card: one key, one answer, instant lookup, but no joins, no ad-hoc SQL, and you must plan which facts to include up front because reorganising later is painful. ElastiCache is your short-term memory — you memorise the first 50 facts so you do not have to reopen the textbook. Amazon Timestream is your stopwatch log that records every second of the exam for later analysis. AWS DMS is the scribe who copies your textbook into a new binder while you keep reading.

Core Operating Principles: Managed vs Self-Managed Databases

The fundamental CLF-C02 distinction is managed versus self-managed. When you run MySQL, PostgreSQL, Oracle, or SQL Server on an Amazon EC2 instance, you own the operating system patches, database engine updates, backups, failover automation, and high-availability configuration. When you use AWS database services such as Amazon RDS, Amazon Aurora, or Amazon DynamoDB, AWS takes over the undifferentiated heavy lifting: OS patching, engine patching, automated backups, point-in-time recovery, Multi-AZ replication, and read-replica provisioning.

Shared Responsibility for AWS Database Services

Under the AWS shared responsibility model, AWS is responsible for security of the cloud (physical hosts, hypervisor, managed engine patches for AWS database services such as Amazon RDS and Amazon Aurora). You remain responsible for security in the cloud: database users, table-level permissions, encryption key selection via AWS KMS, network access controls via security groups, and audit logging via Amazon CloudWatch Logs and AWS CloudTrail. Amazon DynamoDB pushes the line even further — AWS runs every piece of the storage tier because DynamoDB is serverless.

Storage Paradigms You Must Recognise

  • Relational (SQL): Amazon RDS engines and Amazon Aurora — structured schema, ACID transactions, SQL joins.
  • Key-value / document (NoSQL): Amazon DynamoDB — horizontally scaling, schemaless, single-digit millisecond latency.
  • In-memory: Amazon ElastiCache and Amazon MemoryDB for Redis — microsecond reads for caching, leaderboards, session stores.
  • Graph: Amazon Neptune — relationship-heavy workloads such as social networks and fraud detection.
  • Data warehouse / OLAP: Amazon Redshift — petabyte-scale columnar analytics.
  • Document: Amazon DocumentDB — MongoDB-compatible for JSON documents.
  • Time-series: Amazon Timestream — IoT sensor and DevOps monitoring data.

AWS database services are fully managed, purpose-built data stores offered by AWS — including Amazon RDS, Amazon Aurora, Amazon DynamoDB, Amazon ElastiCache, Amazon Neptune, Amazon Redshift, Amazon DocumentDB, Amazon Timestream, and Amazon MemoryDB for Redis — complemented by migration tooling in AWS DMS and the AWS Schema Conversion Tool. Reference: https://aws.amazon.com/products/databases/

Amazon RDS — The Flagship Managed Relational Database

Amazon RDS (Relational Database Service) is the AWS service most candidates first associate with AWS database services. Amazon RDS runs six database engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon Aurora (which is technically an RDS engine option even though it is also branded as its own service). Amazon RDS automates the lifecycle: provisioning, patching, backups, monitoring, and failover.

Amazon RDS Core Features

  • Automated backups with configurable retention (up to 35 days) and point-in-time recovery.
  • Multi-AZ deployments that synchronously replicate the primary to a standby in a second Availability Zone for high availability.
  • Read replicas (up to 5 for MySQL, MariaDB, PostgreSQL; up to 15 for Aurora) for read scaling and disaster recovery.
  • Encryption at rest via AWS KMS and encryption in transit via SSL/TLS.
  • Integration with Amazon CloudWatch for metrics and Amazon RDS Performance Insights for query-level observability.

When to Pick Amazon RDS

Choose Amazon RDS when your application was built on standard SQL and you need ACID-compliant transactions, structured schemas, joins, and familiar tooling. Common workloads include commerce platforms, content management systems, ERP back ends, and any line-of-business application that already speaks MySQL, PostgreSQL, or SQL Server. Amazon RDS removes every operational task except data modelling and application-level tuning.

Multi-AZ in Amazon RDS creates a synchronous standby for automatic failover — it does not serve read traffic. If you need to scale reads across Amazon RDS, provision read replicas instead. Confusing Multi-AZ with read replicas is one of the most frequent traps in CLF-C02 scenario questions. Reference: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

Amazon RDS Pricing Model Snapshot

Amazon RDS is billed per DB instance hour, per provisioned storage GB-month, per IOPS for io1/io2 volumes, per backup storage beyond the free allotment, and per cross-region data transfer. You can use Reserved Instances for Amazon RDS to commit one or three years and save up to 69% compared with On-Demand rates.

Amazon Aurora — AWS-Native High-Performance Relational

Amazon Aurora is an AWS-native relational database engine that is both (a) an engine option inside Amazon RDS and (b) separately branded. Amazon Aurora is MySQL-compatible and PostgreSQL-compatible, which means your existing drivers and SQL work unchanged. What changes is the storage layer: Amazon Aurora replaces the engine's disk subsystem with a distributed, self-healing, six-way replicated, SSD-backed fabric that spans three Availability Zones.

Why Amazon Aurora Is Faster

Amazon Aurora delivers up to 5× the throughput of standard MySQL on RDS and up to 3× the throughput of standard PostgreSQL on RDS, according to AWS benchmarks. The speedup comes from offloading redo-log processing to the storage tier, eliminating the need to write full data pages across the network.

Amazon Aurora Deployment Options

  • Aurora Provisioned — you pick the DB instance class (compute) and pay for uptime.
  • Aurora Serverless v2 — capacity scales in fine-grained ACUs (Aurora Capacity Units) based on demand, ideal for spiky or development workloads.
  • Aurora Global Database — extends a primary cluster to up to five secondary AWS Regions with typical replication lag under one second, giving you low-latency global reads and cross-region disaster recovery.

If your workload is already on MySQL or PostgreSQL, migrate to Amazon Aurora instead of staying on the stock engine — you keep your SQL, your drivers, and your tooling while getting 3×–5× the throughput and a storage layer that is self-healing across three Availability Zones. Aurora Serverless v2 is a particularly strong choice for dev/test environments. Reference: https://aws.amazon.com/rds/aurora/faqs/

Amazon DynamoDB — Serverless NoSQL at Any Scale

Amazon DynamoDB is a fully managed, serverless, key-value and document NoSQL database that delivers single-digit millisecond latency at any scale. DynamoDB has no servers for you to manage, no storage to provision, and no clusters to patch. You create a table, define a partition key (and optionally a sort key), and Amazon DynamoDB handles capacity, replication across three Availability Zones, and backups.

Amazon DynamoDB Capacity Modes

  • On-Demand — pay per read request unit and per write request unit; perfect for unpredictable workloads.
  • Provisioned — you declare RCUs (read capacity units) and WCUs (write capacity units); cheaper for predictable workloads and you can pair it with Auto Scaling.

Amazon DynamoDB Key Features

  • Global tables: active-active multi-Region replication for globally distributed apps, typically replicating within seconds.
  • DynamoDB Streams: ordered change log that integrates with AWS Lambda for event-driven patterns.
  • DynamoDB Accelerator (DAX): in-memory cache that delivers microsecond reads in front of DynamoDB.
  • Point-in-time recovery for up to 35 days and continuous backups with AWS Backup integration.
  • Fine-grained access control via IAM policies at the table, item, and attribute level.

When to Pick Amazon DynamoDB

Choose Amazon DynamoDB when you need predictable low latency at massive scale, the access pattern is known and simple (look up by key, write by key), and you do not need server-side joins or complex ad-hoc queries. Common use cases include gaming leaderboards, session stores, IoT device state, shopping carts, user profiles, and any serverless microservice that must scale from zero to millions of requests per second.

DynamoDB is schemaless in the traditional sense but still requires rigorous up-front data modelling. You must design your partition keys, sort keys, and global secondary indexes around the queries your application will run. You cannot write ad-hoc SQL against DynamoDB. Candidates who assume "NoSQL means no planning" fail scenario questions that pair DynamoDB with relational workloads that need joins or complex transactions. Reference: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

Amazon ElastiCache — In-Memory Caching for Sub-Millisecond Reads

Amazon ElastiCache is a fully managed in-memory data store that supports two engines: ElastiCache for Redis and ElastiCache for Memcached. ElastiCache lives in front of your primary AWS database services (Amazon RDS, Amazon Aurora, Amazon DynamoDB) to cache hot items, session tokens, authentication state, or pre-computed feeds.

ElastiCache for Redis vs ElastiCache for Memcached

  • ElastiCache for Redis — rich data types (lists, sets, sorted sets, hashes, streams), replication, persistence, pub/sub, Lua scripting, Multi-AZ with automatic failover, and encryption.
  • ElastiCache for Memcached — multi-threaded, pure cache, no persistence, no replication, horizontal sharding only.

ElastiCache accelerates reads for data that ultimately lives elsewhere. The source of truth is still Amazon RDS, Amazon Aurora, or Amazon DynamoDB. If the exam scenario asks for a durable primary store, ElastiCache is the wrong answer even though it is fast. If the scenario explicitly says "cache", "sub-millisecond latency", or "reduce database load", ElastiCache is the right answer. Reference: https://aws.amazon.com/elasticache/

Amazon MemoryDB for Redis — Durable In-Memory Primary Database

Amazon MemoryDB for Redis blurs the line between ElastiCache and a primary store. MemoryDB uses the Redis API but adds Multi-AZ durability with a distributed transaction log that persists writes across Availability Zones. Applications that need microsecond reads and single-digit millisecond writes with durability (for example, real-time banking, gaming state, or streaming platforms) can use MemoryDB as their primary database instead of ElastiCache plus a separate durable store.

Amazon Neptune — Managed Graph Database

Amazon Neptune is a fully managed graph database that supports both property-graph (Apache TinkerPop Gremlin) and RDF (SPARQL) query models. Graph databases model data as nodes and edges, which is ideal when relationships are the primary query target. Typical Amazon Neptune workloads include social networks, fraud detection, knowledge graphs, recommendation engines, and identity resolution. On the CLF-C02 exam, Amazon Neptune is the correct answer whenever the scenario emphasises "highly connected data" or "relationship traversal".

Amazon Redshift — Petabyte-Scale Data Warehouse

Amazon Redshift is AWS's fully managed, columnar, massively parallel data warehouse designed for online analytical processing (OLAP). Redshift is optimised for complex analytic queries over terabytes to petabytes of structured and semi-structured data. Redshift Spectrum extends queries to data stored directly in Amazon S3, and Redshift Serverless removes capacity planning for spiky analytics workloads.

Redshift is a columnar data warehouse. It is optimised for large aggregate queries across millions of rows, not for transactional workloads that insert or update single rows at low latency. If the scenario mentions a commerce checkout, session state, or user profile writes, do not pick Redshift — pick Amazon RDS, Amazon Aurora, or Amazon DynamoDB instead. Redshift belongs to the analytics portfolio and gets deeper treatment in the ai-ml-analytics-services topic. Reference: https://aws.amazon.com/redshift/

Amazon DocumentDB — MongoDB-Compatible Document Store

Amazon DocumentDB (with MongoDB compatibility) is a managed document database that supports the MongoDB 3.6, 4.0, and 5.0 APIs. Applications that store self-describing JSON documents — product catalogs, content management, user profiles with evolving schema — can use Amazon DocumentDB as a drop-in for MongoDB while offloading operations to AWS. DocumentDB decouples compute from storage similarly to Amazon Aurora and scales read replicas up to 15 per cluster.

Amazon Timestream — Time-Series Database

Amazon Timestream is a purpose-built time-series database for IoT telemetry, DevOps observability, and industrial sensor data. Time-series data has unique patterns: high write volume, append-only writes, time-based queries (last minute, last hour, rolling window), and data that ages from "hot" to "cold". Amazon Timestream has tiered storage (in-memory for recent data, magnetic for historical) and built-in time-series analytic functions that would be awkward to implement on a generic relational engine.

AWS Database Migration Service (AWS DMS)

AWS Database Migration Service migrates databases to AWS quickly and securely. The source database remains fully operational during the migration, minimising downtime for applications that depend on it. AWS DMS works across a huge matrix of source and target engines.

Homogeneous vs Heterogeneous Migration

  • Homogeneous migration — source and target engines are the same (for example, on-premises MySQL → Amazon RDS for MySQL; Oracle → Amazon RDS for Oracle). AWS DMS handles data movement directly.
  • Heterogeneous migration — source and target engines differ (for example, Oracle → Amazon Aurora PostgreSQL; SQL Server → Amazon RDS for PostgreSQL). You combine AWS DMS for data with the AWS Schema Conversion Tool (AWS SCT) for schema objects such as tables, views, and stored procedures.

AWS Schema Conversion Tool (AWS SCT)

AWS SCT converts the source database schema and most of the application code (views, stored procedures, functions) to a format compatible with the target engine. Objects that cannot be automatically converted are flagged for manual rewrite in an assessment report. AWS SCT pairs with AWS DMS: SCT moves the schema shell, DMS moves (and continually replicates) the data.

Continuous Data Replication

AWS DMS can perform a one-time full load, a full load followed by change data capture (CDC), or a CDC-only ongoing replication. The CDC mode keeps source and target in sync, enabling cutover when you are ready — typical downtime is minutes rather than days.

For the CLF-C02 exam, remember the canonical pairing: if the scenario migrates from a commercial engine (Oracle, SQL Server) to an open-source or AWS-native engine (PostgreSQL, MySQL, Amazon Aurora), the correct answer is AWS DMS for the data movement and AWS Schema Conversion Tool for the schema conversion. If both sides are the same engine, only AWS DMS is required. Reference: https://aws.amazon.com/dms/

AWS Database Services Comparison Matrix

The exam rewards candidates who can quickly map a scenario keyword to the right AWS database service. The following comparison compresses the portfolio into one reference view.

Relational vs NoSQL

Amazon RDS and Amazon Aurora are relational: rigid schema, SQL queries, ACID transactions, JOINs across tables. Amazon DynamoDB is NoSQL key-value/document: flexible attributes, access by partition key, horizontal scale without hand-tuning.

Managed vs Serverless

Amazon RDS and Amazon Aurora Provisioned are managed — you still pick an instance class and pay per hour. Amazon DynamoDB (On-Demand) and Aurora Serverless v2 are serverless — you pay per request or per scaled capacity unit. Amazon ElastiCache and Amazon MemoryDB for Redis are managed node-based clusters.

Purpose-Built Engines Recap

  • RDBMS: Amazon RDS (six engines), Amazon Aurora (AWS-native).
  • Key-value / document NoSQL: Amazon DynamoDB.
  • In-memory cache: Amazon ElastiCache (Redis, Memcached).
  • In-memory durable DB: Amazon MemoryDB for Redis.
  • Graph: Amazon Neptune.
  • Data warehouse / analytics: Amazon Redshift.
  • Document (MongoDB-compatible): Amazon DocumentDB.
  • Time-series: Amazon Timestream.
  • Ledger (immutable, cryptographically verifiable): Amazon QLDB (foundational awareness only on CLF-C02).
  • Wide-column: Amazon Keyspaces for Apache Cassandra (foundational awareness only).

Key Numbers to Memorize

  • Amazon RDS supports 6 engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Amazon Aurora).
  • Amazon Aurora delivers up to 5× throughput over MySQL and 3× over PostgreSQL, with 6-way replicated storage across 3 AZs.
  • Amazon Aurora Global Database supports up to 5 secondary Regions.
  • Amazon DynamoDB offers single-digit millisecond latency, with microseconds via DAX.
  • Amazon RDS automated backups retain up to 35 days; DynamoDB point-in-time recovery also covers 35 days.
  • Amazon RDS supports up to 5 read replicas per source (MySQL/PostgreSQL/MariaDB); Aurora supports up to 15.

Relational and SQL required → Amazon RDS or Amazon Aurora. NoSQL at scale with known keys → Amazon DynamoDB. Cache in front → Amazon ElastiCache. Graph relationships → Amazon Neptune. Analytics over terabytes → Amazon Redshift. JSON documents (MongoDB) → Amazon DocumentDB. Sensor or time-series → Amazon Timestream. Migrate databases into AWS → AWS DMS (plus AWS SCT if engines differ). Reference: https://aws.amazon.com/products/databases/

Common Exam Traps for AWS Database Services

The CLF-C02 question bank reliably hits the following gotchas. Work through each one before exam day.

Trap 1: Amazon RDS vs Amazon DynamoDB Selection

The question will describe a workload and ask which AWS database service fits. Amazon RDS is the answer when the scenario mentions SQL, joins, transactional integrity, or "relational". Amazon DynamoDB is the answer when the scenario mentions key-value access, millions of requests per second, massive scale, or "NoSQL". If the scenario says "schemaless key-value lookups at any scale with single-digit millisecond latency", the correct answer is Amazon DynamoDB — not Amazon RDS.

Trap 2: Aurora Is an RDS Engine and a Separate Brand

Amazon Aurora is both an engine option inside Amazon RDS and a separately marketed service. If two answers include "Amazon RDS for PostgreSQL" and "Amazon Aurora PostgreSQL-Compatible Edition", the more AWS-native answer (Aurora) is usually the right choice when the scenario emphasises performance, cloud-scale storage, or global deployment.

Trap 3: ElastiCache Is Not a Primary Database

Scenarios that mention "reduce read pressure on the database", "session caching", or "sub-millisecond leaderboard" call for Amazon ElastiCache. Scenarios that mention durability, transactions, or source of truth do not.

Trap 4: Redshift Is Not for OLTP

Redshift is a data warehouse for analytics. Do not pick it for user-facing transactional applications even if the scenario says "SQL".

Trap 5: DMS Alone vs DMS + SCT

Heterogeneous migrations need both AWS DMS and AWS SCT. Homogeneous migrations only need AWS DMS. Questions that describe "moving from Oracle to PostgreSQL" are the classic heterogeneous trigger — the correct answer pair is AWS DMS + AWS SCT.

Trap 6: Self-Managed Databases on EC2

You can always run any database on EC2, but the CLF-C02 exam favours AWS database services over self-managed installations whenever the scenario prioritises low operational overhead, automatic backups, or high availability. If the correct answer involves "minimum operational effort", lean towards Amazon RDS, Amazon Aurora, or Amazon DynamoDB over EC2-hosted databases.

AWS Database Services vs AWS Storage Services — Know the Boundary

Candidates sometimes confuse Amazon S3 with a database because it stores data. S3 is object storage: optimised for durability and throughput, not for indexed row-level queries or ACID transactions. Amazon RDS, Amazon Aurora, and Amazon DynamoDB are AWS database services that return records and enforce schemas (relational) or access patterns (NoSQL). The CLF-C02 exam guide keeps task statement 3.4 (AWS database services) distinct from task statement 3.6 (AWS storage services) for this reason.

Real-World Pattern: Choosing the Right AWS Database Service

A realistic AWS solution typically combines multiple AWS database services. Consider a retail platform:

  • Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL — orders, invoices, and customer records that need ACID transactions and joins.
  • Amazon DynamoDB — shopping cart, session state, and product catalog lookups at massive scale.
  • Amazon ElastiCache for Redis — leaderboard of trending products and cached search results.
  • Amazon Redshift — business intelligence queries over years of sales history.
  • Amazon Neptune — recommendation graph connecting customers, products, and purchase behaviour.
  • AWS DMS — continuous replication from the legacy on-premises Oracle system into Amazon Aurora during the migration window.

CLF-C02 will not require you to architect this mosaic, but it will test whether you can match a single scenario line to the correct AWS database service.

Database Security and Observability Across AWS Database Services

All AWS database services integrate with AWS Identity and Access Management for authentication, AWS KMS for encryption at rest, Amazon CloudWatch for metrics, AWS CloudTrail for API auditing, and AWS Backup for centralized backup policies. Amazon RDS, Amazon Aurora, and Amazon DynamoDB additionally support VPC-based network isolation, with Amazon DynamoDB accessed via AWS service endpoints (including VPC endpoints via AWS PrivateLink). Encryption in transit is enforced via SSL/TLS for Amazon RDS and Amazon Aurora, and via HTTPS for Amazon DynamoDB.

Cost Levers for AWS Database Services

  • Amazon RDS — choose engine, instance class, storage type (gp3 vs io1/io2), Multi-AZ on/off, Reserved Instance term.
  • Amazon Aurora — Provisioned vs Serverless v2, storage auto-scales and you only pay for what is used.
  • Amazon DynamoDB — On-Demand vs Provisioned capacity, DAX cache size, global tables replication cost.
  • Amazon ElastiCache — node type and count, Reserved Node discounts.
  • Amazon Redshift — Provisioned vs Serverless, reserved nodes, Redshift Spectrum data scanned.
  • AWS DMS — replication instance size and hours, cross-region data transfer.

Before deploying Amazon RDS, Amazon Aurora, Amazon DynamoDB, or any other AWS database service, plug instance class, storage, backup retention, and cross-region replication into the AWS Pricing Calculator. Amazon RDS and Amazon Aurora are typically billed per hour plus storage; Amazon DynamoDB is billed per capacity unit (Provisioned) or per request (On-Demand). Getting the math right up front avoids end-of-month billing surprises. Reference: https://calculator.aws/

Key Numbers and Must-Memorize Facts

  • Amazon RDS supports 6 engines (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Amazon Aurora).
  • Amazon Aurora: MySQL-compatible and PostgreSQL-compatible, up to 5× MySQL / 3× PostgreSQL performance.
  • Amazon Aurora storage: 6 copies across 3 Availability Zones.
  • Amazon DynamoDB: serverless NoSQL key-value/document, single-digit millisecond latency, global tables for multi-Region active-active.
  • Amazon ElastiCache: Redis (rich data types, replication) or Memcached (multi-threaded, simple cache).
  • Amazon MemoryDB for Redis: durable Redis-compatible primary database.
  • Amazon Neptune: graph (Gremlin + SPARQL).
  • Amazon Redshift: petabyte columnar data warehouse for analytics.
  • Amazon DocumentDB: MongoDB-compatible document store.
  • Amazon Timestream: purpose-built time-series database.
  • AWS DMS: homogeneous and heterogeneous migrations with minimal downtime, plus CDC-based ongoing replication.
  • AWS SCT: schema conversion for heterogeneous migrations; pairs with AWS DMS.

Practice Question Cues for Task 3.4

When you see these keywords on the CLF-C02 exam, map immediately to the AWS database service:

  • "Relational", "SQL", "joins", "ACID", "existing PostgreSQL/MySQL/Oracle/SQL Server workload" → Amazon RDS.
  • "Cloud-native performance, MySQL/PostgreSQL-compatible, cross-region disaster recovery under 1 second RPO" → Amazon Aurora.
  • "Key-value", "single-digit millisecond", "serverless NoSQL", "massive scale with simple access patterns" → Amazon DynamoDB.
  • "Cache", "in-memory", "sub-millisecond read", "reduce database load" → Amazon ElastiCache (Redis or Memcached).
  • "Durable Redis primary", "in-memory with persistence and Multi-AZ" → Amazon MemoryDB for Redis.
  • "Graph", "relationships", "social network", "fraud ring detection" → Amazon Neptune.
  • "Data warehouse", "analytics", "petabyte-scale aggregation" → Amazon Redshift.
  • "MongoDB-compatible", "JSON documents" → Amazon DocumentDB.
  • "Time-series", "IoT telemetry", "monitoring metrics" → Amazon Timestream.
  • "Migrate existing database with minimum downtime" → AWS DMS (add AWS SCT if engines differ).

FAQ — AWS Database Services Top Questions

1. What is the main difference between Amazon RDS and Amazon DynamoDB?

Amazon RDS is a managed relational database that runs one of six SQL engines (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Amazon Aurora) and supports joins, transactions, and structured schemas. Amazon DynamoDB is a serverless NoSQL key-value and document database that delivers single-digit millisecond latency at any scale but does not support SQL joins. Pick Amazon RDS when the scenario needs relational constructs. Pick Amazon DynamoDB when the scenario stresses massive scale, serverless operations, or simple key-based access patterns.

2. Is Amazon Aurora part of Amazon RDS or its own service?

Both. Amazon Aurora is an engine option inside Amazon RDS (so it inherits the RDS management plane for backups, monitoring, and patching), but it is also separately branded because AWS rewrote the storage layer to deliver higher throughput and native cloud features such as Aurora Global Database and Aurora Serverless v2. For exam purposes, treat Amazon Aurora as the AWS-native high-performance RDS engine when the scenario emphasises cloud-scale performance or global deployments.

3. When should I use Amazon ElastiCache instead of Amazon DynamoDB?

Amazon ElastiCache is a cache in front of a primary database. Use ElastiCache when reads are hot and repeatable (session tokens, leaderboards, cached lookups) and you want microsecond response times without hitting your primary store. Amazon DynamoDB is the primary store itself — durable, replicated across AZs, and backed by point-in-time recovery. If the scenario needs durability as the source of truth, DynamoDB wins. If the scenario needs to offload read traffic from an existing database, ElastiCache wins.

4. What is the difference between AWS DMS and AWS Schema Conversion Tool (AWS SCT)?

AWS DMS moves data — it replicates rows from a source database to a target database with minimal downtime, including continuous change-data-capture replication. AWS SCT converts database objects (tables, views, stored procedures, functions) between different engines — for example, from Oracle PL/SQL to PostgreSQL PL/pgSQL. Homogeneous migrations (same engine on both sides) only need AWS DMS. Heterogeneous migrations (different engines) need both AWS DMS and AWS SCT.

5. Can I run a database on Amazon EC2 instead of using AWS database services?

Yes, any database engine can be self-installed on an EC2 instance. You then own all operational tasks: OS patching, engine upgrades, backups, failover automation, and high-availability design. CLF-C02 questions that stress "minimum operational overhead", "fully managed", or "no infrastructure to manage" favour AWS database services (Amazon RDS, Amazon Aurora, Amazon DynamoDB) over EC2-hosted databases. Choose EC2-hosted only when the scenario explicitly mentions a custom or unsupported engine, specific OS-level control, or licensing that forbids managed services.

6. Which AWS database service should I pick for IoT sensor data?

Amazon Timestream is the purpose-built time-series database for IoT telemetry, DevOps metrics, and industrial sensor streams. It offers tiered storage (in-memory hot tier + magnetic cold tier) and built-in time-series analytic functions. On CLF-C02, any scenario that mentions time-stamped sensor data, monitoring events, or rolling-window aggregations over time should map to Amazon Timestream.

7. Do AWS database services automatically encrypt data?

Most AWS database services support encryption at rest via AWS KMS and encryption in transit via SSL/TLS or HTTPS. For Amazon RDS and Amazon Aurora, you enable encryption at rest at database creation time using an AWS KMS key (AWS-managed or customer-managed). Amazon DynamoDB encrypts all new tables at rest by default using an AWS-owned key, with the option to upgrade to AWS-managed or customer-managed KMS keys. Under the AWS shared responsibility model, AWS provides the encryption capability — you as the customer decide to turn it on and pick the key.

Further Reading

Official sources