AWS Database Services Compared: RDS, Aurora, DynamoDB, Redshift, and ElastiCache

AWS offers purpose-built database services rather than one database for everything: Amazon Relational Database Service (RDS) and Amazon Aurora for relational workloads, Amazon DynamoDB for key-value NoSQL at any scale, Amazon Redshift for data warehousing and analytics, and Amazon ElastiCache for in-memory speed. The CLF-C02 exam rarely asks how to administer these services; it asks which one fits a described workload. Learning each service’s one-sentence identity is most of the battle.

Managed relational: Amazon RDS

RDS runs traditional relational database engines as a managed service: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and IBM Db2. AWS handles provisioning, patching, backups, and point-in-time recovery, while you keep standard SQL access and your existing schemas. Two features matter most for the exam:

• Multi-AZ deployments keep a synchronized standby copy in a different Availability Zone and fail over automatically if the primary fails. Multi-AZ is for availability, not extra read capacity.
• Read replicas are asynchronous copies that serve read traffic to offload the primary, and they can live in the same Region or a different one. Read replicas are for read scaling, not automatic failover.

That distinction (Multi-AZ equals availability, read replicas equal read scaling) is one of the most reliably tested facts in the AWS database space.

Choose RDS when a workload needs SQL, joins, transactions, or an existing relational application is migrating to AWS with minimal change. Running your own database on an EC2 instance remains an option when you need full operating system control, but you give up the managed benefits; the trade-off mirrors the responsibility split in the AWS shared responsibility model.

Cloud-native relational: Amazon Aurora

Aurora is AWS’s own relational engine, compatible with MySQL and PostgreSQL, built on a distributed storage layer that replicates data six ways across three Availability Zones. It delivers substantially higher throughput than the standard engines on RDS, storage that grows automatically, and fast failover. Aurora Serverless goes further by scaling database capacity up and down automatically, suited to intermittent or unpredictable workloads. On the exam, “MySQL-compatible or PostgreSQL-compatible”, “cloud-native”, and “up to several times the performance” are Aurora signals. Aurora is managed through the RDS console but is its own answer choice.

Key-value NoSQL: Amazon DynamoDB

DynamoDB is a fully managed, serverless key-value and document database. There are no servers to size, no maintenance windows, and it delivers consistent single-digit millisecond latency at practically any request volume. Capacity is either provisioned or on-demand, and global tables replicate data across Regions for multi-Region applications. DynamoDB does not speak SQL and does not do relational joins; it shines when the access pattern is simple lookups and writes by key at massive scale: shopping carts, session state, gaming leaderboards, IoT (Internet of Things) telemetry. When a question stresses “serverless database”, “millisecond performance at any scale”, or “no schema migrations”, DynamoDB is the answer. DynamoDB Accelerator (DAX) is its dedicated in-memory cache when even lower read latency is needed.

Data warehouse: Amazon Redshift

Redshift is a petabyte-scale data warehouse for online analytical processing (OLAP): running complex SQL queries and aggregations across enormous historical datasets to power business intelligence dashboards and reporting. It stores data in a columnar format and parallelizes queries across nodes. The critical discrimination is OLAP versus OLTP (online transaction processing): Redshift analyzes millions of rows at once; it is the wrong place for an application’s day-to-day inserts and updates, which belong in RDS, Aurora, or DynamoDB. “Analyze years of sales data”, “business intelligence”, and “data warehouse” all point to Redshift.

In-memory cache: Amazon ElastiCache

ElastiCache runs managed in-memory data stores using Redis-compatible engines (including Valkey) and Memcached. It is not usually the system of record; it sits in front of a database and serves hot data from memory in microseconds, cutting both latency and load on the primary database. Typical uses: caching query results, session storage, real-time leaderboards. When a scenario says an application’s database reads are slow because the same data is fetched repeatedly, adding ElastiCache is the fix.

Side-by-side comparison

Service	Data model	Workload type	Signature scenario
RDS	Relational (six engines)	OLTP	Lift existing SQL app to a managed service
Aurora	Relational (MySQL/PostgreSQL compatible)	OLTP	Cloud-native performance and availability
DynamoDB	Key-value / document	OLTP at scale	Serverless, millisecond latency, any volume
Redshift	Columnar relational	OLAP / analytics	Data warehouse for BI over historical data
ElastiCache	In-memory key-value	Caching	Speed up repeated reads, offload the database

The purpose-built family beyond the big five

CLF-C02 expects name-level recognition of a few more: Amazon DocumentDB (MongoDB-compatible document database), Amazon Neptune (graph database for highly connected data like social networks and fraud rings), Amazon Keyspaces (Apache Cassandra-compatible), Amazon Timestream (time series), Amazon QLDB (immutable ledger), and Amazon MemoryDB (Redis-compatible in-memory database durable enough to be a primary store). You only need to match each name to its data model. Note also that databases are distinct from storage services: a database engine you run yourself lives on block storage, a comparison unpacked in EBS vs EFS vs S3.

How the CLF-C02 exam tests this

• The lift-and-shift pattern. A company migrates an existing MySQL or SQL Server application and wants AWS to handle patching and backups with minimal application change. The answer is RDS; EC2-hosted databases are the distractor that keeps the operational burden.
• The availability-versus-read-scaling pattern. One question flavor asks how to survive an Availability Zone failure (answer: Multi-AZ); the sibling flavor asks how to serve growing read traffic (answer: read replicas). Swapping these two is the intended trap.
• The serverless-scale pattern. A new application needs single-digit millisecond reads at unpredictable, potentially massive scale with no server management. The answer is DynamoDB, not Aurora, whenever the question avoids any mention of SQL or joins.
• The analytics pattern. Leadership wants dashboards analyzing several years of transaction history without slowing the production database. The answer is Redshift, with the production OLTP database left in place.
• The repeated-reads pattern. An application repeatedly fetches the same rows and the database is under load. The answer is ElastiCache in front of the database, not a bigger database instance.

Quick reference

• RDS: managed relational engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2); AWS patches and backs up, you keep SQL.
• Multi-AZ is synchronous standby for failover; read replicas are asynchronous copies for read scaling.
• Aurora: AWS-built, MySQL and PostgreSQL compatible, six-way storage replication across three AZs; Serverless variant auto-scales capacity.
• DynamoDB: serverless key-value NoSQL, single-digit millisecond latency at any scale; DAX adds an in-memory cache; global tables for multi-Region.
• Redshift: petabyte-scale OLAP data warehouse for BI and historical analysis, not transactional workloads.
• ElastiCache: managed Redis-compatible and Memcached in-memory caching to cut latency and database load.
• Purpose-built extras: DocumentDB (document), Neptune (graph), Keyspaces (Cassandra), Timestream (time series), QLDB (ledger), MemoryDB (durable in-memory).