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.
A known key-based access pattern means the request already carries the identifier needed to find an item, such as userId=42 for one shopping cart. That shape may fit DynamoDB. If the application instead needs SQL to join related records, enforce relationships, and support less predictable queries, RDS or Aurora fits. Aurora remains a relational choice: it becomes interesting when MySQL/PostgreSQL compatibility must be combined with AWS-managed cluster storage, reader instances, and failover behavior.
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: before storing data, the team can name the exact reads and writes the product performs. Shopping carts, sessions, user profiles, device state, and serverless API metadata often work this way. DynamoDB exists to serve those deliberately modeled key and index lookups without a customer-managed database server.
Other applications depend on relationships between records. An order may have to join to its customer and invoice, while constraints prevent references to records that do not exist. RDS exists to preserve familiar relational engines and SQL behavior while AWS manages much of the surrounding infrastructure.
Some relational workloads need MySQL/PostgreSQL compatibility but also benefit from a cluster in which database instances are separated from shared, distributed storage. Aurora exists for that operating model. It can add readers and provide managed failover targets, but it does not turn a relational schema into DynamoDB or make every write multi-writer.
3. The Naive Approach And Where It Breaks
The naive approach is to choose the most managed or newest service before writing down the application's actual queries.
That breaks because management level is not the data model. A checkout service that must join orders, payments, and invoices does not stop needing relational behavior because DynamoDB is serverless; a cart fetched only by customer ID does not gain value merely because a relational engine can run joins.
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
A DynamoDB table stores items. The partition key is the field whose value helps route and distribute an item, such as USER#42; an optional sort key orders or groups related items under that value. Secondary indexes support additional planned lookups. Capacity modes, streams, point-in-time recovery (PITR), and global tables address throughput, change capture, historical recovery, and multi-Region access as separate concerns.
RDS runs a selected relational engine in DB instances. In the common Multi-AZ DB instance pattern, the primary handles normal writes while a synchronously replicated standby exists for managed failover and is not a read-scaling target. A read replica is a separate, asynchronously updated copy that the application may query; because copying takes time, it can lag behind the primary. Automated backups, snapshots, and storage choices solve recovery and persistence concerns rather than read scaling.
An Aurora cluster normally has one writer instance and can have reader instances. They connect to one shared, distributed cluster-storage layer instead of each owning an independent full copy of the database. The writer endpoint directs normal write connections; the reader endpoint balances read connections across available Aurora Replicas. Readers can be failover candidates, but normal writes still belong to the writer.
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 enforced through AWS Identity and Access Management (IAM) at the service API layer. Fine-grained permissions can narrow which actions or items a caller may access. Encryption, recovery permissions, and VPC endpoints are separate controls; network-private access does not itself authorize a request.
RDS and Aurora have two important authorization layers: IAM controls management actions such as creating or snapshotting a database, while database users and roles control SQL access inside the engine. Network placement, security groups, TLS, secrets, and AWS Key Management Service (KMS) encryption add reachability, transport, credential, and at-rest protection; none replaces the others.
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 that stores data redundantly across multiple Availability Zones. PITR and on-demand backups preserve recoverable history; streams expose item changes; global tables replicate across Regions for multi-Region access. These are different jobs, and global replication can copy an unwanted write just as readily as a wanted one.
In the common RDS Multi-AZ DB instance pattern, a primary failure triggers promotion of an already-maintained standby, then the application reconnects through the database endpoint. That shortens infrastructure recovery because the replacement already exists. Read replicas instead serve additional reads and may lag, while backups and snapshots create historical recovery points.
Aurora keeps cluster storage distributed across Availability Zones and can promote an existing reader after writer failure. The application must still reconnect and the promoted instance must have enough capacity for the workload. Continuous backups support point-in-time restore, while Aurora Global Database addresses cross-Region designs; neither makes every failure invisible.
Replication is not backup. DynamoDB global tables, RDS read replicas, and Aurora replicas can all propagate bad writes. Point-in-time restore creates a recovered table, DB instance, or cluster rather than rewinding the live resource in place, so recovery also needs a tested reconnection or data-restoration plan.
9. Performance And Scaling
DynamoDB scales very well for known access patterns with good key distribution. A hot partition appears when too much traffic concentrates on the same partition-key values, so a nominally scalable table can still throttle while other capacity sits idle.
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: