Cargando...
Cargando...
Choose the right managed database in 60 seconds — relational vs serverless NoSQL, when each wins, and every exam trap exposed
Managed relational (traditional) vs managed relational (cloud-native) vs serverless NoSQL — three very different tools for three very different jobs
| Feature | RDS Familiar SQL engines, fully managed | Aurora Cloud-native SQL, 5x MySQL speed | DynamoDB Serverless NoSQL, millisecond at any scale |
|---|---|---|---|
Database Type RDS supports 6 engines; Aurora supports only MySQL & PostgreSQL compatible. DynamoDB is the ONLY NoSQL option of the three. | Relational (SQL) — IBM Db2, MariaDB, MySQL, Oracle, PostgreSQL, SQL Server | Relational (SQL) — MySQL-compatible and PostgreSQL-compatible only | NoSQL — key-value and document store |
Management Model DynamoDB is the only truly serverless option. RDS and Aurora still require you to choose instance sizes. | Managed (you choose instance type, storage, AZ placement) | Managed with cloud-native automation (auto-scaling storage, self-healing) | Fully serverless — no instances, no clusters to manage |
Storage Architecture Aurora cluster volume max is 128 TiB (from live docs). Aurora storage is NOT tied to a single instance — it's shared across all cluster nodes. | EBS-backed per instance; gp2, gp3, io1, io2 — you provision and manage storage | Shared distributed cluster volume across 3 AZs, 6 copies of data; auto-grows up to 128 TiB | Fully managed, distributed, virtually unlimited — no storage provisioning |
Max Storage Aurora's 128 TiB limit is a documented hard limit. DynamoDB has no practical storage ceiling. | Depends on engine and storage type; up to 64 TiB for most engines (16 TiB for SQL Server) | 128 TiB per cluster volume (auto-grows, no manual provisioning required) | Virtually unlimited (tables scale automatically; customers with 200+ TB tables documented) |
High Availability & Replication Aurora Replicas serve BOTH HA failover AND read scaling. RDS read replicas do NOT provide automatic failover — only Multi-AZ standby does. | Multi-AZ with synchronous standby (1 standby); read replicas up to 5 (async); failover ~1-2 min | 6 copies of data across 3 AZs automatically; up to 15 Aurora Replicas; faster failover ~30 sec | Built-in multi-AZ replication within a region; Global Tables for multi-region active-active |
Read Replicas 15 Aurora Replicas vs 5 RDS read replicas — a classic exam comparison. Aurora replicas share the same storage volume (no replication lag for writes). | Up to 5 read replicas per source DB instance (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server) | Up to 15 Aurora Replicas within a cluster; can also create cross-region read replicas | Not applicable — reads scale automatically via on-demand or provisioned capacity; DAX for caching |
Global / Multi-Region DynamoDB Global Tables = active-active. Aurora Global Database = active-passive (one primary writer). Both are exam favorites. | Cross-region read replicas (async); no native active-active multi-region | Aurora Global Database — 1 primary region + up to 5 secondary regions; sub-second replication; RPO < 1 sec, RTO < 1 min | Global Tables — active-active multi-region replication; last-writer-wins conflict resolution |
Throughput / Performance DynamoDB is purpose-built for consistent performance at scale — the key phrase on exams is 'single-digit millisecond at any scale'. | Depends on instance type and storage IOPS; vertical scaling required for more throughput | Up to 5x throughput of MySQL, up to 3x throughput of PostgreSQL (per AWS docs) | Single-digit millisecond at ANY scale; handles trillions of API calls; 500K+ RPS peak documented |
Scaling Model DynamoDB On-Demand mode requires zero capacity planning. Aurora Serverless v2 auto-scales compute but still has an underlying cluster. | Vertical (instance resize, causes downtime) + horizontal read replicas; storage auto-scaling available | Vertical for writes (instance resize); horizontal read scaling via replicas; Aurora Serverless v2 for auto compute scaling | Horizontal auto-scaling in both dimensions; On-Demand mode scales instantly; Provisioned mode with Auto Scaling |
Backup & PITR All three support PITR. Aurora PITR is continuous (to any second). DynamoDB PITR must be explicitly enabled per table. | Automated backups (1–35 days retention); manual snapshots; PITR within retention window | Automated backups (1–35 days); continuous backup to S3; PITR to any second within retention window | On-demand backups (no retention limit); PITR up to 35 days; exports to S3 |
Pricing Model DynamoDB On-Demand eliminates capacity planning cost but can be more expensive at very high sustained loads. RDS/Aurora Reserved Instances offer significant discounts (up to ~60%) for 1- or 3-year commitments. | Pay for: instance hours (On-Demand or Reserved), storage (GB/month), I/O (for magnetic), data transfer, backups beyond free tier | Pay for: instance hours (On-Demand or Reserved), storage (GB/month auto-billed), I/O requests, backups, data transfer; Aurora Serverless billed per ACU-hour | Pay for: read/write capacity units (RCU/WCU) in Provisioned mode OR per-request in On-Demand mode; storage (GB/month); optional features (DAX, Streams, Global Tables) |
Free Tier Aurora has NO free tier — a common exam trap. DynamoDB's free tier is PERMANENT (not 12-month limited). RDS free tier is 12 months only. | 750 hours/month of db.t2.micro or db.t3.micro (Single-AZ), 20 GB storage, 20 GB backup — 12 months | No free tier (Aurora is NOT included in the standard 12-month free tier) | 25 GB storage, 25 WCU, 25 RCU permanently free (no 12-month limit); 2.5 million stream read requests/month |
Schema & Data Model DynamoDB does NOT support JOINs or complex SQL queries. If the scenario requires complex relational queries, choose RDS or Aurora. | Strict relational schema; tables, rows, columns, foreign keys, JOINs, ACID transactions | Strict relational schema; same as RDS but MySQL/PostgreSQL only; supports JOINs, ACID | Flexible schema; items can have different attributes; partition key (+ optional sort key); no JOINs |
ACID Transactions DynamoDB does support ACID transactions but with limits (100 items, 4 MB). For complex multi-table ACID requirements, RDS/Aurora is simpler. | Full ACID at table and cross-table level (native SQL transactions) | Full ACID at table and cross-table level (native SQL transactions) | ACID transactions supported via TransactWriteItems / TransactGetItems (up to 100 items or 4 MB per transaction) |
Encryption DynamoDB encryption at rest is ALWAYS ON — cannot be disabled. RDS/Aurora encryption must be enabled at instance creation; cannot be added to an existing unencrypted instance without snapshot restore. | Encryption at rest (AES-256 via KMS); encryption in transit (SSL/TLS); must be enabled at creation | Encryption at rest (AES-256 via KMS); encryption in transit (SSL/TLS); must be enabled at creation | Encryption at rest always enabled (AWS owned key, AWS managed key, or customer managed KMS key); encryption in transit via HTTPS |
VPC & Network Access DynamoDB is NOT deployed inside a VPC — it's a regional service. Use a VPC Gateway Endpoint for private access without internet routing. | Deployed inside a VPC; accessed via security groups; subnet groups required | Deployed inside a VPC; accessed via security groups; subnet groups required; cluster endpoint + reader endpoint | Regional service accessed via HTTPS endpoint; VPC access via VPC Gateway Endpoint (free); no VPC deployment |
Key Exam Use Cases | Lift-and-shift of existing relational workloads; Oracle/SQL Server licensing; complex SQL; ERP, CRM systems | New relational workloads needing high availability and performance; SaaS apps; OLTP at scale; MySQL/PostgreSQL migration with minimal code change | Serverless apps; gaming leaderboards; IoT; session management; shopping carts; any key-value or document workload needing massive scale |
Aurora-Specific Features Aurora Serverless v2 auto-scales in fine-grained increments (0.5 ACU steps). Aurora Limitless Database uses DB shard groups (max 5 per region per docs). | N/A | Aurora Serverless v2 (auto-scales compute); Aurora Global Database; Aurora Multi-Master (MySQL); Babelfish (SQL Server compatibility on PostgreSQL); RDS Data API; Aurora Limitless Database (DB shard groups — up to 5 per region) | N/A |
DynamoDB-Specific Features DynamoDB Streams + Lambda is a classic event-driven pattern on exams. DAX reduces read latency from milliseconds to microseconds — used when DynamoDB alone isn't fast enough. | N/A | N/A | DynamoDB Streams (CDC); DAX (in-memory cache, microsecond reads); TTL (auto-expire items); Global Tables; Kinesis Data Streams integration; PartiQL support; S3 Import/Export |
Max DB Instances per Region Both RDS and Aurora share the 40 DB instance quota per region (per live docs). Aurora also has a separate 40 DB cluster quota. | 40 DB instances (20 in ap-south-1); adjustable via Service Quotas | 40 DB clusters per region; 40 DB instances per region (20 in ap-south-1); adjustable | No instance concept — serverless; table limits apply instead |
Parameter Groups Aurora has TWO levels of parameter groups: cluster-level AND instance-level. Changes to cluster parameter groups affect all instances in the cluster. | DB parameter groups (instance-level) — up to 50 per region (adjustable) | DB cluster parameter groups (cluster-level) + DB parameter groups (instance-level) — up to 50 cluster parameter groups | Not applicable — no parameter groups |
Custom Endpoints Aurora custom endpoints (max 5 per cluster) allow routing different workloads to different replica subsets — e.g., analytical queries to larger instances. | Not applicable in the same way; uses instance endpoints | Up to 5 custom endpoints per Aurora DB cluster (per live docs); used to route traffic to specific replica subsets | Not applicable |
Maintenance & Patching DynamoDB has zero maintenance windows. Aurora can achieve near-zero downtime patching with replicas. RDS requires planned maintenance windows. | Managed patching during maintenance windows; minor version auto-upgrade optional; major version manual upgrade | Managed patching; zero-downtime patching for minor versions when replicas exist; Aurora handles OS patching automatically | Fully managed — AWS handles all patching invisibly; no maintenance windows required |
Summary
Choose RDS when you need a familiar relational engine (especially Oracle, SQL Server, or Db2) and want managed infrastructure without changing your application. Choose Aurora when you need MySQL or PostgreSQL compatibility with superior performance, availability (15 replicas, 6-copy storage), and cloud-native features like Global Database or Serverless v2. Choose DynamoDB when you need a serverless, infinitely scalable NoSQL store with single-digit millisecond latency — ideal for key-value, document, gaming, IoT, and any workload where schema flexibility and massive horizontal scale matter more than complex SQL.
🎯 Decision Tree
Need NoSQL / key-value / document store? → DynamoDB. Need SQL with Oracle, SQL Server, Db2, or MariaDB? → RDS. Need SQL with MySQL or PostgreSQL + maximum HA + cloud-native performance? → Aurora. Need active-active multi-region SQL? → Aurora Global Database (active-passive) or reconsider DynamoDB Global Tables (active-active). Need zero capacity planning? → DynamoDB On-Demand or Aurora Serverless v2. Need to lift-and-shift existing Oracle/SQL Server? → RDS (licensing considerations apply). Scenario mentions 'single-digit millisecond at any scale' or 'serverless database'? → DynamoDB.
Aurora Replicas (max 15) serve DUAL purposes: read scaling AND automatic HA failover. RDS Read Replicas (max 5) provide read scaling ONLY — they do NOT automatically become the primary on failover. Only RDS Multi-AZ standby provides automatic failover, and it cannot serve reads. This distinction is tested constantly across SAA-C03, DVA-C02, and SAP-C02.
DynamoDB is the answer whenever you see: 'serverless', 'NoSQL', 'key-value', 'single-digit millisecond at any scale', 'gaming leaderboard', 'session store', 'IoT data', or 'schema-less'. RDS/Aurora is the answer whenever you see: 'relational', 'SQL', 'JOINs', 'ACID transactions across tables', 'existing Oracle/SQL Server application', or 'complex queries'. Confusing these on scenario questions is the #1 database mistake on AWS exams.
Aurora has NO free tier. DynamoDB has a PERMANENT free tier (25 GB + 25 WCU + 25 RCU — forever, not 12 months). RDS has a 12-month free tier (750 hours db.t2/t3.micro). On cost-optimization questions, DynamoDB On-Demand with free tier is the cheapest starting point for low/unpredictable traffic. On CLF-C02 and SAA-C03 cost questions, never suggest Aurora for a free-tier scenario.
Aurora Global Database enables cross-region disaster recovery with RPO < 1 second and RTO < 1 minute. It is active-PASSIVE (one primary writer region). DynamoDB Global Tables enables active-ACTIVE multi-region replication with last-writer-wins conflict resolution. For 'multi-region active-active' scenarios, DynamoDB Global Tables is the answer. For 'cross-region DR with SQL' scenarios, Aurora Global Database is the answer.
You CANNOT add encryption to an existing unencrypted RDS or Aurora instance directly. The correct process is: take a snapshot → copy snapshot with encryption enabled → restore from encrypted snapshot. DynamoDB is always encrypted at rest and this cannot be disabled. On security exam questions about encrypting an existing unencrypted database, the snapshot-copy-restore pattern is the required answer.
DynamoDB Streams + AWS Lambda is the canonical event-driven database pattern on DVA-C02 and SAA-C03. When you see 'trigger processing on database changes' or 'real-time data processing on inserts/updates', the answer is DynamoDB Streams → Lambda. The equivalent for RDS/Aurora is using Amazon EventBridge Pipes or reading the binary log — much more complex.
Aurora Serverless v2 auto-scales compute capacity in fine-grained 0.5 ACU increments. It is billed per ACU-hour. Use it for unpredictable or intermittent relational workloads where you still need MySQL/PostgreSQL compatibility. It is NOT the same as DynamoDB serverless — Aurora Serverless v2 still has an underlying cluster and takes seconds to scale, not milliseconds.
DynamoDB VPC access requires a VPC Gateway Endpoint (free). RDS and Aurora are deployed inside your VPC and accessed via Security Groups and Subnet Groups. On architecture questions asking 'how do Lambda functions in a VPC access DynamoDB privately without internet?', the answer is VPC Gateway Endpoint for DynamoDB.
The #1 exam trap is choosing Aurora over RDS for Oracle or SQL Server workloads because 'Aurora is better/faster.' Aurora ONLY supports MySQL and PostgreSQL compatible engines — it does NOT support Oracle, SQL Server, Db2, or MariaDB. A close second trap: assuming RDS Multi-AZ standby serves read traffic (it does NOT — it's HA-only). And third: assuming DynamoDB has no free tier or that its free tier expires after 12 months (DynamoDB's 25 GB + 25 WCU + 25 RCU free tier is PERMANENT).
CertAI Tutor · SAA-C03, CLF-C02, DVA-C02, DEA-C01, DOP-C02, SCS-C02, SAP-C02 · 2026-02-22
Services
Comparisons