DynamoDB vs RDS vs Aurora

Concepts Covered

• NoSQL versus relational databases
• DynamoDB access pattern design
• RDS managed relational engines
• Aurora cluster storage model
• SQL and joins
• Key-value scale
• Transactions
• Multi-AZ and global patterns
• Operational overhead
• SAA-C03 database traps

1. Plain-English Mental Model

DynamoDB, RDS, and Aurora are not three versions of the same database.

DynamoDB = managed NoSQL for known key-based access patterns
RDS = managed familiar relational database engines
Aurora = AWS-native MySQL/PostgreSQL-compatible relational database clusters

The cleanest decision starts with the data model.

If the application knows exactly how it will read and write items by key, DynamoDB may fit. If the application needs SQL, joins, constraints, transactions, and existing engine compatibility, RDS or Aurora fits. If it needs relational compatibility plus stronger AWS-native read scaling, failover, and cluster storage behavior, Aurora may fit better than standard RDS.

2. Why This Service Exists

AWS offers multiple database models because one database shape cannot serve every application well.

Some applications are access-pattern driven: shopping carts, sessions, user profiles, device state, leaderboards, and serverless API metadata. They need fast predictable key-value access more than joins. DynamoDB exists for that.

Some applications depend on relational behavior: SQL queries, joins, constraints, normalized schemas, mature engines, reporting compatibility, and existing application code. RDS exists to run familiar relational engines with less infrastructure work.

Some relational workloads need cloud-native storage, fast failover, multiple readers, global database options, or MySQL/PostgreSQL compatibility with AWS-managed cluster behavior. Aurora exists for that.

3. The Naive Approach And Where It Breaks

The naive approach is to choose the most managed or newest service.

That breaks because management level is not the data model.

DynamoDB is fully managed and serverless, but it does not give you arbitrary SQL joins and ad hoc relational queries. If the product requires complex relational reporting inside the application path, DynamoDB can force painful modeling work.

RDS is familiar, but it can become expensive or hard to scale for massive high-throughput key-value access where the application only needs lookups by ID.

Aurora is powerful, but it can be overkill for small predictable relational workloads where standard RDS is enough.

4. Core Primitives

DynamoDB primitives are tables, items, partition keys, sort keys, global secondary indexes, capacity modes, streams, point-in-time recovery, and global tables.

RDS primitives are DB instances, engines, subnet groups, parameter groups, Multi-AZ deployments, read replicas, automated backups, manual snapshots, and storage choices.

Aurora primitives are clusters, writer instances, reader instances, shared distributed storage, cluster endpoints, reader endpoints, backups, Aurora Replicas, Serverless capacity, and Global Database.

The primitives reveal the difference. DynamoDB asks you to model access patterns. RDS asks you to choose and operate a relational engine with managed infrastructure. Aurora asks you to think in relational clusters and shared storage.

5. Architecture Use Cases

Use DynamoDB for serverless APIs, shopping carts, session-like state, user preferences, high-scale metadata, IoT device state, and access patterns that can be expressed through keys and indexes.

Use RDS for existing MySQL, PostgreSQL, MariaDB, Oracle, or SQL Server applications that need SQL compatibility and managed operations.

Use Aurora for production MySQL/PostgreSQL-compatible workloads that need strong managed availability, read scaling, faster failover, global database patterns, or serverless relational capacity options.

A common decision:

API Gateway -> Lambda -> DynamoDB

for key-based serverless access.

ALB -> app service -> RDS or Aurora

for relational applications.

7. Security Model

DynamoDB access is mostly IAM-based at the service API layer. Fine-grained access controls, encryption, PITR, and VPC endpoints can matter.

RDS and Aurora security includes network placement, security groups, database users, IAM management permissions, KMS encryption, TLS, subnet groups, secrets, and engine-level privileges.

For RDS and Aurora, do not expose database endpoints publicly unless the requirement is explicit and tightly controlled.

For all three, backup and restore permissions are sensitive. A principal that can export, snapshot, restore, or scan data may effectively have access to the dataset.

KMS key policy matters when encrypted backups, snapshots, tables, or clusters cross accounts or Regions.

8. Reliability And Resilience

DynamoDB is a regional managed service replicated across multiple Availability Zones, with PITR, backups, streams, and global tables for multi-Region active-active patterns.

RDS uses Multi-AZ for high availability, read replicas for read scaling and some recovery patterns, and backups or snapshots for historical recovery.

Aurora uses shared distributed storage across AZs, reader instances as failover targets, continuous backups, and Aurora Global Database for cross-Region designs.

Replication is not backup. DynamoDB global tables, RDS read replicas, and Aurora replicas can all propagate bad writes. Keep recovery points for accidental data loss.

9. Performance And Scaling

DynamoDB scales very well for known access patterns with good key distribution. Bad partition keys can still create hot partitions.

RDS scales mostly through instance sizing, storage performance, read replicas, query tuning, indexes, and connection management. Writes still go to the primary.

Aurora improves relational read scaling with reader endpoints and cluster behavior, but normal Aurora clusters still have a writer. Query design remains essential.

If the question says "single-digit millisecond key-value access at any scale," DynamoDB is usually the stronger signal.

If the question says "complex SQL joins and transactions," RDS or Aurora is usually the stronger signal.

10. Cost Model

DynamoDB cost depends on read/write mode, requests, storage, indexes, streams, backups, and global tables.

RDS cost depends on instance hours, storage, I/O, backups, Multi-AZ, read replicas, licensing, and data transfer.

Aurora cost includes instances or capacity units, storage, I/O, backups, replicas, Global Database, and data transfer.

The wrong data model is expensive even if the service looks cheap. A relational workload forced into DynamoDB can cost engineering time. A simple key-value workload forced into RDS can cost database capacity and operations.

12. SAA-C03 Exam Signals

"Fully managed NoSQL key-value database" points to DynamoDB.

"Known access patterns and predictable low-latency reads by key" points to DynamoDB.

"SQL, joins, constraints, existing MySQL/PostgreSQL/Oracle/SQL Server" points to RDS.

"MySQL/PostgreSQL compatible with high performance and faster failover" points to Aurora.

"Multi-Region active-active NoSQL" points to DynamoDB global tables.

"Read scaling for relational workload" points to read replicas or Aurora readers.

"Application needs ad hoc relational queries" points away from DynamoDB.

13. Common Exam Traps

Do not choose DynamoDB just because it is serverless if the app requires relational joins.

Do not choose RDS just because the data has fields. DynamoDB items also have attributes.

Do not choose Aurora for every relational workload when standard RDS meets the requirement.

Do not confuse read scaling with write scaling.

Do not forget backup/PITR for accidental delete recovery.

Do not ignore access pattern modeling for DynamoDB.

15. Related Topics

Review Amazon DynamoDB, Amazon RDS, Amazon Aurora, RDS Multi-AZ vs Read Replicas, and RDS And Aurora Recovery Choices.

Official AWS references:

• What is Amazon DynamoDB?
• Amazon RDS read replicas
• What is Amazon Aurora?