Aurora

Aurora DSQL – Serverless Distributed SQL Database

~ Last updated on : ~ Kiro Agent

Amazon Aurora DSQL

  • Amazon Aurora DSQL is a serverless, distributed relational database service optimized for transactional (OLTP) workloads.
  • Aurora DSQL was previewed at AWS re:Invent 2024 and became generally available on May 27, 2025.
  • It offers virtually unlimited scale, the highest availability, and zero infrastructure management.
  • Aurora DSQL is PostgreSQL-compatible (currently PostgreSQL 16), enabling developers to use familiar drivers, ORMs, tools, and SQL features.
  • It is designed for 99.99% availability in single-Region configuration and 99.999% availability in multi-Region configuration.
  • Aurora DSQL uses Optimistic Concurrency Control (OCC) instead of traditional pessimistic locking, eliminating deadlocks and lock contention.
  • It supports active-active multi-Region deployments with strongly consistent reads and writes from any Region.
  • Aurora DSQL scales to zero when idle — no compute charges when no queries are running.
  • It eliminates all operational burden including patching, upgrades, maintenance downtime, capacity planning, and database sharding.

Aurora DSQL Architecture

  • Aurora DSQL uses a disaggregated architecture where the database is separated into four independent, multi-tenant components that scale independently:
    • Query Processors (Firecracker MicroVMs) – Stateless compute units that handle SQL parsing, query planning, and execution. They run in AWS Firecracker MicroVMs (same technology as AWS Lambda), enabling true scale-to-zero behavior.
    • Adjudicators – The conflict detection layer that validates write transactions at commit time using Optimistic Concurrency Control. If conflicts are detected, the transaction is rejected with SQLSTATE 40001.
    • Journal (Paxos-Based Log) – A distributed write-ahead log using Paxos consensus that provides cross-AZ durability. Every committed transaction is written to the Journal before being acknowledged.
    • MVCC Storage Replicas – Multi-Version Concurrency Control storage that maintains table data across three Availability Zones in each active Region.
  • A control plane coordinates all components, providing redundancy across three AZs with automatic scaling and self-healing.
  • Each component scales independently — query processing, commit, and storage layers adapt to workloads of any shape including different read/write ratios, data sizes, and query complexities.

Single-Region Clusters

  • Active-active across three Availability Zones, minimizing replication lag and eliminating traditional failover operations.
  • All write transactions are committed to a distributed transaction log and synchronously replicated to storage replicas in three AZs.
  • Designed for 99.99% availability.
  • When a component or AZ becomes impaired, requests are automatically redirected to healthy infrastructure without manual intervention.

Multi-Region Clusters

  • Provides 99.999% availability with active-active multi-Region deployment.
  • Two Regional endpoints present a single logical database, both available for concurrent read and write operations with strong data consistency.
  • Aurora DSQL synchronously replicates writes across Regions, enabling strongly consistent reads and writes from any linked cluster.
  • A third Region acts as a witness Region — stores only encrypted transaction logs for Paxos quorum, not full data copies.
  • Multi-Region clusters must be created within the same Region set (same continent):
    • US Regions: US East (N. Virginia), US East (Ohio), US West (Oregon)
    • Asia Pacific: Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Tokyo)
    • Europe: Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris)
  • Cross-continent multi-Region clusters are not currently supported.

Aurora DSQL Key Features

  • Serverless & Zero Infrastructure Management
    • No servers to provision, patch, upgrade, or manage.
    • No maintenance downtime — eliminates traditional database failover.
    • Automatically manages storage optimization, statistics collection, and performance tuning.
    • Scales to zero when idle with no compute charges.
  • Active-Active Multi-Region
    • Both Regions accept concurrent reads and writes.
    • Single logical database across Regions with strong consistency.
    • No eventual consistency or missing data during failovers.
  • Strongly Consistent Reads
    • Provides strong read-after-write consistency.
    • Readers always see the same data regardless of which Region they connect to.
    • Zero data loss for both single and multi-Region clusters due to synchronous replication.
  • Optimistic Concurrency Control (OCC)
    • Transactions execute without acquiring locks.
    • Conflicts are detected at commit time, not during execution.
    • Eliminates deadlocks and prevents slow transactions from blocking others.
    • If conflicts occur, the later transaction receives SQLSTATE 40001 and must be retried by the application.
    • Read-only transactions are conflict-free and never fail due to OCC.
  • Auto-Scaling
    • Scales compute, I/O, and storage automatically based on workload.
    • No database sharding or instance upgrades required.
    • Query processing, commit, and storage layers scale independently.
  • 99.999% Multi-Region Availability
    • Active-active architecture with automatic failure recovery.
    • No manual failover or switchover operations.
    • Multi-AZ and multi-Region availability built-in.
  • PostgreSQL Compatibility
    • Compatible with PostgreSQL 16 wire protocol.
    • Supports standard drivers: psycopg2, asyncpg, node-postgres, JDBC.
    • Supports ACID transactions, SQL queries, secondary indexes, joins, CTEs, window functions, aggregations.
    • IAM-based token authentication (no password-based authentication).
  • ACID Transactions
    • Full ACID properties even across multiple Regions.
    • Strong snapshot isolation (equivalent to PostgreSQL REPEATABLE READ).
    • Cross-AZ and cross-Region durability.
  • Change Data Capture (CDC)
    • Supports streaming changes to Amazon Kinesis Data Streams.
    • Billed as StreamDPU — scales with volume of changes captured.
  • Security
    • Full integration with AWS IAM and AWS CloudTrail.
    • Token-based authentication using IAM (blocks standard password-based auth).
    • Encrypted transaction logs in witness Region.

Aurora DSQL Pricing

  • Aurora DSQL uses a pay-per-use pricing model with no upfront costs.
  • Billing is based on two primary components:
    • Database Activity (DPUs) – Distributed Processing Units measure all work done by the system including compute, I/O reads, I/O writes, and CDC streaming.
    • Storage (GB-month) – Based on total data stored, replicated across 3 AZs (you pay for one logical copy per Region).
  • DPU Rate: $8.00 per million DPUs (in US East regions).
  • Storage Rate: $0.33 per GB-month.
  • Free Tier (permanent, no 12-month expiry):
    • 100,000 DPUs per month (~700,000 TPC-C transactions)
    • 1 GB of storage per month
  • Multi-Region Write Replication: Incurs extra DPU charges equal to the cost of originating writes (approximately 50% premium on write DPUs). No separate data transfer charges.
  • Scale to Zero: When the cluster is idle, DPU usage scales to zero — $0.00 compute charges. Only storage is billed continuously.
  • DPU Sub-components (visible in CloudWatch, all billed at same rate):
    • ComputeDPU – SQL query execution (joins, functions, aggregations)
    • ReadDPU – Data read from storage
    • WriteDPU – Data written to storage
    • MultiRegionWriteDPU – Replication to peered clusters
    • StreamDPU – Change data capture streaming
  • Aurora DSQL usage may be eligible for Database Savings Plans.
  • Inter-AZ replication within a Region is included at no additional charge.

Aurora DSQL vs Aurora Serverless v2 vs Aurora Global Database vs DynamoDB Global Tables

Feature Aurora DSQL Aurora Serverless v2 Aurora Global Database DynamoDB Global Tables
Architecture Disaggregated, distributed, OCC Standard Aurora engine, ACU-based scaling Provisioned/Serverless instances with cross-Region replication Fully managed NoSQL, partitioned
Data Model Relational (SQL) Relational (SQL) Relational (SQL) Key-Value / Document (NoSQL)
Multi-Region Writes Active-Active (built-in) Not supported (single-Region only) Active-Passive (single writer, read replicas in other Regions) Active-Active (all Regions accept writes)
Consistency Strong consistency (reads and writes) Strong consistency (single-Region) Eventual consistency for cross-Region reads; strong in primary Eventual consistency (cross-Region); strong consistency for single-Region reads
Availability SLA 99.99% (single-Region), 99.999% (multi-Region) 99.99% 99.99% with <1 min RTO for cross-Region failover 99.999%
Scaling Serverless, scales to zero, virtually unlimited Serverless, 0.5-128 ACUs, scales to zero Provisioned instances or Serverless v2; manual scaling On-demand or provisioned; auto-scaling
PostgreSQL Compatibility Subset (no FK, triggers, sequences, stored procs, views) Full Aurora PostgreSQL/MySQL Full Aurora PostgreSQL/MySQL Not applicable (NoSQL)
Concurrency Control Optimistic (OCC) — no locks, retry on conflict Pessimistic locking (traditional) Pessimistic locking (traditional) Last-writer-wins or conditional writes
Infrastructure Management Zero (fully serverless) Minimal (serverless but cluster management needed) Moderate (instance sizing, replica management, failover config) Zero (fully serverless)
Pricing Model Per DPU ($8/million) + storage ($0.33/GB-month) Per ACU-hour ($0.12/hr) + storage + I/O Instance hours + storage + I/O + data transfer Per WRU/RRU (on-demand) or provisioned WCU/RCU + storage
Free Tier 100K DPUs + 1 GB/month (permanent) None (beyond general AWS Free Tier) None 25 GB storage + 25 WCU/RCU (provisioned, 12-month)
Transaction Limits 3,000 rows per transaction Standard PostgreSQL limits Standard PostgreSQL limits 25 items / 4 MB per transaction
Best For Global OLTP, low-contention writes, serverless backends, new apps Variable workloads, existing PostgreSQL apps, single-Region Disaster recovery, read scaling, cross-Region with single writer High-throughput key-value access, global apps not needing SQL

Aurora DSQL Limitations

  • PostgreSQL Feature Gaps:
    • No foreign keys (referential integrity must be enforced in application code)
    • No triggers
    • No views or materialized views
    • No sequences or SERIAL/IDENTITY columns (use UUIDs via gen_random_uuid())
    • No stored procedures (PL/pgSQL not supported; SQL functions are supported)
    • No PostgreSQL extensions (PostGIS, pgvector, etc.)
    • No explicit locking (SELECT FOR UPDATE not supported)
    • No temporary tables (use CTEs or regular tables with unique naming)
  • Transaction Constraints:
    • Maximum of 3,000 rows modified per transaction (INSERT, UPDATE, DELETE)
    • DDL and DML operations require separate transactions
    • Only 1 DDL statement per transaction
    • Fixed isolation level: REPEATABLE READ only (no SERIALIZABLE, no READ COMMITTED)
  • Operational Constraints:
    • Single database per cluster (named postgres) — use schemas for logical separation
    • Database connections time out after 1 hour
    • UTF-8 encoding only with C collation only
    • UTC system timezone
    • No password-based authentication (IAM token-based only)
  • Multi-Region Constraints:
    • Cross-continent multi-Region clusters not supported
    • Multi-Region clusters must be within the same Region set
    • Multi-Region writes incur additional DPU charges (~50% premium)
  • OCC Requirements:
    • Applications must implement retry logic for write transactions (handle SQLSTATE 40001)
    • Not suitable for high write-contention workloads (inventory counters, hot-row updates)
    • Each retry attempt consumes additional DPUs

Aurora DSQL Use Cases

Financial Transactions

  • Global-scale financial transaction processing across multiple AWS Regions.
  • Core banking systems requiring strong consistency without choosing between consistency and low latency.
  • Spend management systems and digital currency infrastructure.
  • Payment processing with ACID guarantees across Regions.
  • The low-contention nature of financial transactions (each transaction typically touches unique records) makes OCC highly effective.

Global Applications

  • Multi-Region SaaS applications requiring active-active writes with strong consistency.
  • Global scheduling and booking systems (e.g., Frontdoor home services marketplace).
  • Collaborative tools where users in different Regions need consistent data views.
  • Multi-Region authentication and session management services.
  • Microservices and event-driven architectures with serverless backends (Lambda + API Gateway + DSQL).

Gaming

  • Global game state — maintaining consistent world state across geographically distributed players.
  • Player inventory — managing in-game items and purchases with ACID guarantees preventing duplication exploits.
  • In-game purchases — transactional integrity for virtual currency and item transactions.
  • Live events — consistent event state across all Regions simultaneously.
  • Real-time player interactions — ensuring consistent data for trades, gifts, and cooperative actions.
  • Note: For high-contention leaderboard updates (many players updating the same row), DynamoDB or Aurora with pessimistic locking may be more appropriate. DSQL works well for leaderboards designed with per-player rows.

Other Use Cases

  • Order management systems and e-commerce transaction processing.
  • User profile and account management (low-contention per-user updates).
  • Appointment and resource scheduling systems.
  • Event logging and audit trail systems (append-only patterns).
  • Development and testing environments (leveraging permanent free tier).

Aurora DSQL Region Availability

  • GA Regions (May 2025 launch): US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Osaka), Asia Pacific (Tokyo), Europe (Ireland), Europe (London), Europe (Paris)
  • Added July 2025: Asia Pacific (Seoul)
  • Added October 2025: Europe (Frankfurt)
  • Added February 2026: Additional Regions
  • Added May 2026: Asia Pacific (Hong Kong), Asia Pacific (Mumbai), Asia Pacific (Singapore), Europe (Stockholm), South America (São Paulo)
  • Region expansion continues through 2026.

AWS Certification Exam Relevance

  • AWS Solutions Architect Associate (SAA-C03)
    • Understanding when to choose Aurora DSQL vs Aurora Serverless v2 vs DynamoDB Global Tables for multi-Region architectures.
    • Knowing the availability SLAs (99.99% single-Region, 99.999% multi-Region).
    • Understanding serverless database options and their trade-offs.
  • AWS Solutions Architect Professional (SAP-C02)
    • Designing global, active-active architectures with strong consistency.
    • Understanding OCC implications for application design.
    • Comparing multi-Region database strategies: Aurora DSQL vs Aurora Global Database vs DynamoDB Global Tables.
    • Cost optimization for global database architectures.
  • AWS Database Specialty (DBS-C01)
    • Deep understanding of Aurora DSQL architecture (disaggregated components, Paxos journal, Adjudicators).
    • PostgreSQL compatibility limitations and migration considerations.
    • OCC conflict resolution and retry patterns.
    • DPU pricing model and cost estimation.
    • When to use DSQL vs other Aurora variants vs DynamoDB.

Amazon Aurora DSQL Practice Questions

Question 1:

A company is building a global financial application that requires active-active writes in multiple AWS Regions with strong consistency for all reads. The application uses a relational data model with SQL queries and ACID transactions. Which database service is MOST appropriate?

  1. Amazon Aurora Global Database
  2. Amazon DynamoDB Global Tables
  3. Amazon Aurora DSQL multi-Region cluster
  4. Amazon Aurora Serverless v2 with cross-Region read replicas
Show Answer

Answer: C –

  • Aurora DSQL multi-Region clusters provide active-active writes with strong consistency across Regions using a relational/SQL data model — exactly what this scenario requires.
  • Aurora Global Database (Option A) supports only active-passive (single writer Region with read replicas in other Regions).
  • DynamoDB Global Tables (Option B) provides active-active but with eventual consistency and a NoSQL data model, not relational SQL.
  • Aurora Serverless v2 (Option D) is single-Region only and does not support cross-Region writes.

Question 2:

A development team is migrating an existing PostgreSQL application to Aurora DSQL. The application heavily uses foreign keys, database triggers for audit logging, and stored procedures for business logic. What should the team do?

  1. Migrate directly — Aurora DSQL supports all PostgreSQL features
  2. Refactor the application to enforce referential integrity in application code, move trigger logic to EventBridge/application layer, and move stored procedure logic to the application or Lambda functions
  3. Use Aurora DSQL with PostgreSQL extensions to enable missing features
  4. Use Aurora Serverless v2 instead, which provides full PostgreSQL compatibility without requiring application changes
Show Answer

Answer: B (if DSQL is required) or D (if full PG compatibility is the priority) –

  • Aurora DSQL does not support foreign keys, triggers, or stored procedures (PL/pgSQL). These are architectural limitations of the distributed design.
  • Option B is correct if the team must use DSQL — all these features need application-level workarounds.
  • Option D is the simpler path if the requirement is just serverless PostgreSQL without application refactoring.
  • Option A is incorrect — DSQL is a PostgreSQL-compatible subset, not full PostgreSQL.
  • Option C is incorrect — Aurora DSQL does not support PostgreSQL extensions.

    • Question 3:

    An e-commerce company uses Aurora DSQL for its order processing system. During peak sales events, they notice increased transaction failures with SQLSTATE 40001 errors on their inventory update operations where multiple customers try to purchase the last few items simultaneously. What is the MOST likely cause and solution?

    1. The database is running out of capacity; increase the provisioned instances
    2. Aurora DSQL’s Optimistic Concurrency Control is detecting write conflicts on the same inventory rows; redesign to reduce contention or switch to Aurora Serverless v2 with pessimistic locking for the inventory service
    3. The database connection pool is exhausted; increase the connection limit
    4. The transaction isolation level needs to be changed to READ COMMITTED
    Show Answer

    Answer: B –

    • SQLSTATE 40001 is the serialization failure error returned by Aurora DSQL’s OCC when concurrent transactions conflict on the same data.
    • High-contention inventory updates (many writers to the same row) are a known poor fit for OCC — they generate high retry rates.
    • Solutions include redesigning the schema to reduce contention, or using Aurora Serverless v2 with traditional pessimistic locking for high-contention workloads.
    • Option A is incorrect — Aurora DSQL is serverless with no provisioned instances.
    • Option D is incorrect — Aurora DSQL only supports REPEATABLE READ isolation; it cannot be changed.

    Question 4:

    A startup wants to minimize database costs for their development environment while building a globally distributed application. They need a PostgreSQL-compatible database that costs nothing when idle and has a permanent free tier. Which option BEST meets these requirements?

    1. Amazon RDS PostgreSQL with a db.t3.micro instance (free tier)
    2. Amazon Aurora Serverless v2 (scales to zero)
    3. Amazon Aurora DSQL (scales to zero with permanent free tier)
    4. Amazon DynamoDB with on-demand capacity
    Show Answer

    Answer: C –

    • Aurora DSQL has a permanent free tier (100,000 DPUs + 1 GB storage/month with no 12-month expiry) and scales to zero when idle — $0 compute charges when not in use.
    • RDS free tier (Option A) expires after 12 months and the instance runs continuously (always has charges after free tier expires).
    • Aurora Serverless v2 (Option B) can scale to zero but does not have a permanent free tier for compute.
    • DynamoDB (Option D) has a free tier but is NoSQL, not PostgreSQL-compatible.

    Question 5:

    A solutions architect is designing a multi-Region active-active database architecture using Aurora DSQL. The application serves users in the US and Europe. What is a key constraint the architect must consider?

    1. Multi-Region clusters can span any two AWS Regions globally
    2. Multi-Region clusters must be within the same continent/Region set — cross-continent clusters are not supported
    3. Only one Region can accept writes at a time; the other Region is read-only
    4. Multi-Region clusters require manual failover configuration
    Show Answer

    Answer: B –

    • Aurora DSQL multi-Region clusters must be created within the same Region set (US Regions, Asia Pacific Regions, or European Regions). Cross-continent multi-Region clusters are not currently supported.
    • The architect cannot create a cluster spanning US East and Europe — they would need separate single-Region clusters or a different approach for cross-continent active-active.
    • Option A is incorrect — cross-continent is not supported.
    • Option C is incorrect — both Regions accept concurrent reads AND writes (active-active).
    • Option D is incorrect — Aurora DSQL provides automatic failure recovery with no manual failover.

    Frequently Asked Questions

    What is Amazon Aurora DSQL?

    Aurora DSQL is a serverless, distributed SQL database that provides PostgreSQL compatibility with active-active multi-Region replication, strong consistency, and 99.999% availability — all without managing infrastructure.

    How does Aurora DSQL differ from Aurora Global Database?

    Aurora Global Database uses a primary-secondary model with async replication (1-second lag). DSQL provides active-active multi-Region writes with strong consistency and optimistic concurrency control, meaning both Regions can accept writes simultaneously.

    Is Aurora DSQL compatible with PostgreSQL?

    Yes, DSQL is wire-compatible with PostgreSQL and supports standard SQL. However, it has some limitations — it doesn’t support stored procedures, triggers, sequences, or advisory locks due to its distributed architecture.

    Related Posts

    References

    RDS vs Aurora vs DynamoDB – Database Selection Guide

    ~ Last updated on : ~ Kiro Agent

    RDS vs Aurora vs DynamoDB – AWS Database Selection Guide

    Choosing the right AWS database service is one of the most impactful architectural decisions you’ll make. Amazon RDS, Amazon Aurora, and Amazon DynamoDB serve fundamentally different needs, and selecting the wrong one leads to performance bottlenecks, cost overruns, or painful migrations. This guide provides a structured decision framework — not just feature comparisons — to help you choose correctly the first time.

    This post is designed as a selection/decision guide with clear criteria, decision flowcharts, and tradeoff analysis for each service.

    🎯 Quick Decision Rule:

    • Need SQL, complex joins, existing relational schema? → RDS or Aurora
    • Need SQL + high availability + auto-scaling + performance? → Aurora
    • Need unlimited scale, single-digit ms latency, simple access patterns? → DynamoDB

    Decision Framework: When to Choose Each

    Choose Amazon RDS When:

    • You need a specific database engine not supported by Aurora (Oracle, SQL Server, MariaDB)
    • Your workload is predictable and steady with well-understood capacity needs
    • You want the lowest cost for a managed relational database with moderate performance needs
    • You’re doing a lift-and-shift migration from on-premises with minimal changes
    • Your application requires engine-specific features (e.g., Oracle RAC alternatives, SQL Server Always On)
    • Storage needs are under 64 TB and you want direct control over IOPS provisioning

    Choose Amazon Aurora When:

    • You need MySQL or PostgreSQL compatibility with significantly better performance
    • Your workload requires high availability with fast automated failover (<30 seconds)
    • You need auto-scaling storage up to 128 TB without manual provisioning
    • Your traffic is variable or unpredictable (Aurora Serverless v2 scales to zero)
    • You need cross-region disaster recovery with <1 second replication lag (Global Database)
    • You need horizontal write scaling for relational data (Aurora Limitless Database)
    • Performance requirements exceed what standard RDS can deliver (5x MySQL, 3x PostgreSQL throughput)

    Choose Amazon DynamoDB When:

    • Your access patterns are well-defined and predictable (key-value lookups, simple queries)
    • You need single-digit millisecond latency at any scale (or microseconds with DAX)
    • Your application must scale to millions of requests per second without capacity planning
    • You want zero infrastructure management — no instances, no patching, no maintenance windows
    • You need active-active multi-region writes with Global Tables
    • Your data model is denormalized or fits key-value/document patterns
    • You need event-driven architectures with DynamoDB Streams triggering Lambda

    Architecture Differences

    Amazon RDS – Traditional Managed Architecture

    • Compute + Storage coupled — EC2 instance with attached EBS volumes (gp3 or io2)
    • Storage limited to 64 TB (gp3) with manual IOPS provisioning
    • Multi-AZ: synchronous standby replica for failover (30-60 second failover)
    • Multi-AZ DB Clusters: 1 writer + 2 readable standbys, ~35 second failover
    • Read Replicas: asynchronous, up to 15 (MySQL/MariaDB) or 5 (PostgreSQL/Oracle/SQL Server)
    • Supports 6 engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2
    • RDS Custom: Full OS/database access for Oracle and SQL Server customization
    • RDS Proxy: Connection pooling for serverless/Lambda workloads

    Amazon Aurora – Cloud-Native Relational Architecture

    • Compute and storage decoupled — storage is a shared distributed volume across 3 AZs
    • 6 copies of data across 3 AZs; writes acknowledged with 4/6 quorum
    • Tolerates loss of 2 copies for writes, 3 copies for reads — without interruption
    • Storage auto-scales from 10 GB to 128 TB, no provisioning needed
    • Up to 15 read replicas sharing the same storage (near-zero replication lag)
    • Failover to replica in <30 seconds (no data copy required — shared storage)
    • Aurora Serverless v2: scales in ACUs, scales to zero, up to 30% better performance (2026 platform v4)
    • Aurora Global Database: cross-region with <1 second replication, RPO <1 second
    • Aurora Limitless Database (GA Oct 2024): automated horizontal write scaling via sharding, millions of writes/sec
    • Aurora DSQL (GA May 2025): distributed SQL, active-active multi-region, 99.999% availability
    • Supports: MySQL and PostgreSQL only

    Amazon DynamoDB – Serverless Distributed NoSQL

    • Fully serverless — no instances, no storage provisioning, no maintenance windows
    • Data automatically replicated across 3 AZs
    • Horizontally partitioned by partition key — unlimited scaling
    • Supports key-value and document data models
    • Global Tables: active-active multi-region with multi-region strong consistency (MRSC, 2025)
    • DynamoDB Streams: ordered change data capture for event-driven patterns
    • DAX: in-memory cache providing microsecond read latency
    • Zero-ETL with Redshift: real-time analytics without data movement
    • Standard and Standard-IA table classes for cost optimization

    Comprehensive Comparison Table

    Criteria Amazon RDS Amazon Aurora Amazon DynamoDB
    Database Type Relational (SQL) Relational (SQL) – cloud-native NoSQL (Key-Value / Document)
    Engines MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2 MySQL-compatible, PostgreSQL-compatible Proprietary (API + PartiQL)
    Max Storage 64 TB (gp3) 128 TB (auto-scaling) Unlimited (per table)
    Performance Standard engine performance; dependent on instance + EBS IOPS 5x MySQL, 3x PostgreSQL throughput; optimized I/O paths Single-digit ms latency; microseconds with DAX; consistent at any scale
    Scaling – Vertical Instance resize (downtime); up to 128 vCPUs Instance resize or Serverless v2 auto-scaling (0.5–256 ACUs) N/A – fully managed, scales automatically
    Scaling – Horizontal (Reads) Up to 15 read replicas (async) Up to 15 replicas (shared storage, near-zero lag) Automatic partitioning; unlimited read throughput
    Scaling – Horizontal (Writes) Single writer only (manual sharding needed) Single writer; Limitless Database for automated sharding (PG) Automatic partitioning; unlimited write throughput
    Availability SLA 99.95% (Multi-AZ) 99.99%; 99.999% (DSQL multi-region) 99.99% (standard); 99.999% (Global Tables)
    Failover Time 30-60 sec (Multi-AZ); ~35 sec (DB Clusters) <30 sec (replica promotion); instant (Serverless) N/A – multi-AZ by default, no failover concept
    Multi-Region Cross-region read replicas (manual promotion) Global Database (<1s lag); DSQL (active-active) Global Tables (active-active, MRSC for strong consistency)
    Serverless Option No (always provisioned instances) Yes – Serverless v2 (scales to zero) Yes – fully serverless by default
    Backup/Recovery Automated backups (35 days); manual snapshots; PITR Continuous backup to S3; PITR; Backtrack (MySQL, in-place rewind) Continuous backup; PITR (35 days); on-demand backup
    Encryption At-rest (KMS) + in-transit (SSL/TLS) At-rest (KMS) + in-transit (SSL/TLS) At-rest (KMS, default) + in-transit (TLS)
    Authentication DB native + IAM DB Auth + Kerberos/AD DB native + IAM DB Auth + Kerberos/AD IAM policies + fine-grained access control
    Pricing Model Instance hours + EBS storage + IOPS (if io2) + data transfer Instance/ACU hours + storage ($0.10/GB) + I/O or I/O-Optimized On-demand (per request) or Provisioned (WCU/RCU) + storage ($0.25/GB)
    Cost Optimization Reserved Instances (1yr/3yr) Reserved Instances; I/O-Optimized tier; Serverless Reserved Capacity; Standard-IA class; on-demand vs provisioned
    Maintenance Maintenance windows required for patching Maintenance windows (less frequent); zero-downtime patching available Zero maintenance — no windows, no patching, no downtime
    Best For Lift-and-shift; Oracle/SQL Server workloads; steady predictable loads High-performance MySQL/PostgreSQL; variable traffic; mission-critical apps Massive scale; gaming/IoT/mobile; simple access patterns; event-driven

    Scaling Approaches Compared

    RDS Scaling

    • Vertical: Change instance class (requires brief downtime for single-AZ; rolling for Multi-AZ DB Clusters)
    • Storage: Increase EBS volume size (online, but cannot decrease); up to 80,000 IOPS with gp3 (2026)
    • Read scale-out: Add read replicas (async replication means eventual consistency for reads)
    • Write scale-out: Not supported natively — requires application-level sharding
    • Limitation: Write throughput bound by single instance capacity

    Aurora Scaling

    • Vertical: Instance resize or Serverless v2 auto-scaling (0.5 to 256 ACUs, increments of 0.5)
    • Storage: Automatic — grows in 10 GB increments, up to 128 TB, never shrinks below high-water mark
    • Read scale-out: Up to 15 replicas with shared storage (no replication lag penalty)
    • Write scale-out: Aurora Limitless Database (PostgreSQL) — automated sharding across multiple writer instances, petabyte scale
    • Serverless: Scales to zero when idle; responds in milliseconds; ideal for dev/test and variable traffic
    • Advantage: Scaling doesn’t require data copying — shared storage architecture

    DynamoDB Scaling

    • Fully automatic: No instance sizing or storage provisioning — scales horizontally by adding partitions
    • On-demand mode: Instantly accommodates up to 2x previous peak; no throttling for gradual increases
    • Provisioned mode: Set WCU/RCU with auto-scaling policies (target utilization-based)
    • No practical limits: Handles millions of requests/second, unlimited storage per table
    • Consideration: Requires good partition key design — hot partitions can cause throttling
    • 2025 update: More frequent mode switches between provisioned and on-demand now allowed

    Pricing Comparison

    Amazon RDS Pricing

    • Instance hours: Pay per hour for chosen instance type (e.g., db.r6g.large ~$0.26/hr in us-east-1)
    • Storage: gp3 at $0.115/GB/month (includes 3,000 IOPS baseline); io2 for high-performance
    • Additional IOPS: gp3 provisioned IOPS $0.08/IOPS/month above baseline
    • Backup: Free up to 100% of DB size; additional at $0.095/GB/month
    • Data transfer: Standard AWS rates
    • Savings: Reserved Instances (up to 60% discount for 3-year all-upfront)
    • Lowest entry cost among the three for relational workloads

    Amazon Aurora Pricing

    • Instance hours: ~20% premium over equivalent RDS instances
    • Storage: $0.10/GB/month (auto-provisioned, slightly cheaper per-GB than RDS gp3)
    • I/O (Standard tier): $0.20 per million I/O requests — can be significant for write-heavy workloads
    • I/O-Optimized tier: 30-40% higher instance + storage cost, but zero I/O charges — breaks even at ~500K I/Os per instance hour
    • Serverless v2: $0.12 per ACU-hour (billed per second); scales to zero = $0 when idle
    • Savings: Reserved Instances; choose I/O-Optimized for high-throughput; Serverless for variable loads
    • Cost trap: I/O charges in Standard tier can double the bill for read-heavy/high-throughput workloads

    Amazon DynamoDB Pricing

    • On-demand: $1.25 per million write request units (WRU); $0.25 per million read request units (RRU)
    • Provisioned: $0.00065 per WCU/hour; $0.00013 per RCU/hour (~$0.47/WCU/month)
    • Storage: $0.25/GB/month (Standard); $0.10/GB/month (Standard-IA for infrequent access)
    • Global Tables: Replicated writes cost 1.5x (rWRU/rWCU) + cross-region transfer
    • Transactions: 2x cost (each transactional operation counts double)
    • Savings: Reserved Capacity (up to 77% for 3-year); provisioned mode for steady workloads
    • Cost insight: On-demand is ~7x more expensive than provisioned for sustained throughput — switch to provisioned once patterns stabilize
    💰 Cost Decision Matrix:

    • Lowest cost, steady relational workload: RDS with Reserved Instances
    • Variable traffic, pay-for-what-you-use: Aurora Serverless v2 or DynamoDB on-demand
    • High-throughput relational: Aurora I/O-Optimized with Reserved Instances
    • Massive scale NoSQL, steady traffic: DynamoDB Provisioned + Reserved Capacity
    • Unpredictable/spiky NoSQL: DynamoDB on-demand

    Availability and Disaster Recovery

    Feature RDS Aurora DynamoDB
    Data Replication Synchronous to 1 standby (Multi-AZ) 6 copies across 3 AZs (automatic) 3 copies across 3 AZs (automatic)
    RPO (Data Loss) 0 (Multi-AZ sync); seconds (read replicas) 0 (same region); <1 sec (Global Database) 0 (same region); 0 with MRSC (Global Tables)
    RTO (Recovery Time) 30-60 sec (Multi-AZ); minutes (replica promotion) <30 sec (replica); <1 min (Global failover) Instant (multi-AZ built-in); seconds (Global Tables failover)
    Cross-Region DR Cross-region read replicas (manual failover) Global Database (managed failover); DSQL (automatic) Global Tables (automatic active-active)
    Point-in-Time Recovery Yes (up to 35 days) Yes (up to 35 days) + Backtrack (MySQL, no new cluster) Yes (up to 35 days)
    Maintenance Downtime Required (maintenance windows) Minimal (zero-downtime patching for many updates) Zero (no maintenance windows ever)

    Security Features

    Security Feature RDS Aurora DynamoDB
    Network Isolation VPC, Security Groups, private subnets VPC, Security Groups, private subnets VPC Endpoints (Gateway); no VPC placement needed
    Encryption at Rest AES-256 via KMS (must enable at creation) AES-256 via KMS (must enable at creation) AES-256 via KMS (enabled by default)
    Encryption in Transit SSL/TLS (configurable, can enforce) SSL/TLS (configurable, can enforce) TLS (HTTPS endpoints, always encrypted)
    Authentication Database native; IAM DB Auth; Kerberos/AD; Secrets Manager rotation Database native; IAM DB Auth; Kerberos/AD; Secrets Manager rotation IAM policies only (no DB-level users)
    Fine-Grained Access Database GRANT/REVOKE (table/column level) Database GRANT/REVOKE (table/column level) IAM conditions on partition keys, attributes
    Audit Logging Engine-native audit logs + CloudTrail (API) Engine-native audit logs + CloudTrail (API) CloudTrail (API); no query-level audit natively
    Connection Management RDS Proxy for pooling RDS Proxy for pooling N/A — HTTP/HTTPS API (no persistent connections)

    Decision Flowchart: Selecting Your Database

    Step 1: What’s Your Data Model?

    • ✅ Relational (tables, joins, foreign keys, complex queries) → Go to Step 2
    • ✅ Key-value, document, or denormalized → Go to Step 5

    Step 2: Which Database Engine Do You Need?

    • ✅ Oracle, SQL Server, MariaDB, or Db2 → Choose RDS
    • ✅ MySQL or PostgreSQL → Go to Step 3

    Step 3: What Are Your Performance/Scale Requirements?

    • ✅ Standard performance is sufficient; cost is primary concern → Choose RDS
    • ✅ Need high throughput (5x MySQL/3x PG), auto-scaling storage, fast failover → Go to Step 4
    • ✅ Need horizontal write scaling (millions of writes/sec) → Choose Aurora Limitless Database
    • ✅ Need active-active multi-region SQL with 99.999% availability → Choose Aurora DSQL

    Step 4: What’s Your Traffic Pattern?

    • ✅ Steady, predictable traffic → Choose Aurora Provisioned
    • ✅ Variable/spiky traffic or dev/test environments → Choose Aurora Serverless v2
    • ✅ Infrequent use with cost sensitivity → Choose Aurora Serverless v2 (scales to zero)

    Step 5: DynamoDB Fit Assessment

    • ✅ Access patterns are known and can be modeled with partition/sort keys → Choose DynamoDB
    • ✅ Need ad-hoc queries, complex joins, or flexible querying → Go back to Step 2 (use relational)
    • ✅ Need <1ms reads with caching → Choose DynamoDB + DAX
    • ✅ Need active-active multi-region with zero RPO → Choose DynamoDB Global Tables (MRSC)

    Common Use Case Mapping

    Use Case Recommended Service Why
    E-commerce product catalog + orders Aurora (orders) + DynamoDB (catalog/cart) ACID for transactions; low-latency reads for catalog
    Gaming leaderboard / session store DynamoDB Unlimited scale, single-digit ms, simple access patterns
    SaaS multi-tenant application Aurora (Limitless for large scale) or DynamoDB SQL for complex queries; DynamoDB for per-tenant isolation
    Legacy Oracle migration to AWS RDS for Oracle or RDS Custom Full Oracle compatibility; minimal code changes
    IoT sensor data ingestion DynamoDB Massive write throughput; time-series via sort key; TTL for expiry
    Financial transaction processing Aurora or Aurora DSQL (global) Strong ACID; high throughput; cross-region consistency
    Content management system (WordPress-style) RDS MySQL/PostgreSQL Standard performance sufficient; lowest cost; proven compatibility
    Real-time mobile app backend DynamoDB + DynamoDB Streams Serverless; event-driven; scales with users
    Enterprise reporting with complex joins Aurora PostgreSQL Complex SQL; parallel query; high read throughput
    Globally distributed app (multi-region writes) DynamoDB Global Tables or Aurora DSQL Active-active; conflict resolution; low-latency global access

    Key Tradeoffs to Consider

    Tradeoff Winner Explanation
    Lowest cost (small relational workload) RDS ~20% cheaper instances than Aurora; no I/O charges with gp3
    Best price-performance (relational) Aurora 5x MySQL throughput offsets 20% cost premium; I/O-Optimized eliminates surprise bills
    Zero operational overhead DynamoDB No instances, no patching, no maintenance windows, no version upgrades
    Query flexibility RDS / Aurora Full SQL — ad-hoc queries, joins, aggregations; DynamoDB requires pre-planned access patterns
    Unlimited horizontal scale DynamoDB Automatic partitioning; no upper bound on throughput or storage
    Multi-region active-active (NoSQL) DynamoDB Global Tables with MRSC for zero-RPO multi-region strong consistency
    Multi-region active-active (SQL) Aurora DSQL Only AWS relational option with true active-active multi-region writes
    Engine diversity (Oracle, SQL Server) RDS Aurora only supports MySQL/PostgreSQL; RDS supports 6 engines

    AWS Certification Exam Tips

    📝 Key Exam Concepts:

    • If the question mentions “millisecond latency at any scale” or “millions of requests/second” → DynamoDB
    • If the question mentions “complex queries,” “joins,” or “ACID transactions” with high performance → Aurora
    • If the question mentions “Oracle,” “SQL Server,” or “lift-and-shift” → RDS
    • If the question mentions “serverless” + “relational” → Aurora Serverless v2
    • If the question mentions “globally distributed” + “active-active” → DynamoDB Global Tables or Aurora DSQL
    • If the question mentions “no maintenance windows” → DynamoDB
    • Aurora’s 6 copies across 3 AZs and shared storage architecture are frequent exam topics
    • DynamoDB partition key design and hot partition issues are common scenario questions

    Practice Questions

    Question 1:

    A company is building a new e-commerce platform that requires complex SQL queries for inventory management, order processing with ACID transactions, and must handle Black Friday traffic spikes that are 10x normal load. The team uses PostgreSQL. Which database solution provides the best combination of SQL support, performance, and automatic scaling?

    1. Amazon RDS for PostgreSQL with Multi-AZ
    2. Amazon Aurora PostgreSQL with Serverless v2
    3. Amazon DynamoDB with on-demand capacity
    4. Amazon RDS for PostgreSQL with read replicas
    Show Answer

    Answer: B –

    Explanation: Aurora PostgreSQL Serverless v2 provides full PostgreSQL SQL compatibility (complex queries, ACID transactions), delivers 3x PostgreSQL throughput, and automatically scales compute capacity to handle traffic spikes without manual intervention. It scales to zero during low-traffic periods and scales up instantly during Black Friday peaks. RDS would require manual instance resizing or over-provisioning. DynamoDB doesn’t support complex SQL queries or joins needed for inventory management.

    Question 2:

    A gaming company needs a database for their global leaderboard that must handle 5 million writes per second during peak hours, provide single-digit millisecond read latency, and be available in 4 AWS regions simultaneously with active-active writes. Which solution meets these requirements?

    1. Amazon Aurora Global Database with write forwarding
    2. Amazon DynamoDB with Global Tables
    3. Amazon RDS Multi-AZ with cross-region read replicas
    4. Amazon Aurora DSQL in multi-region configuration
    Show Answer

    Answer: B –

    Explanation: DynamoDB Global Tables provide active-active multi-region replication with single-digit millisecond latency and can handle millions of requests per second with automatic scaling. Gaming leaderboards are a classic DynamoDB use case — simple access patterns (get/put by player ID, query by score) with massive scale requirements. Aurora Global Database doesn’t support active-active writes (only forwarding). Aurora DSQL supports active-active but is optimized for OLTP transactions, not the extreme write throughput needed here. RDS doesn’t support active-active multi-region.

    Question 3:

    A financial services company is migrating their Oracle-based core banking application to AWS. The application uses PL/SQL stored procedures extensively, requires full ACID compliance, and the team wants minimal code changes. Which is the most appropriate migration path?

    1. Amazon Aurora PostgreSQL with Babelfish
    2. Amazon RDS for Oracle
    3. Amazon DynamoDB with transactions
    4. Amazon Aurora MySQL
    Show Answer

    Answer: B –

    Explanation: RDS for Oracle provides full Oracle engine compatibility including PL/SQL stored procedures, requiring minimal or zero code changes. The requirement explicitly states “minimal code changes” with heavy PL/SQL usage, which rules out Aurora (only MySQL/PostgreSQL compatible). DynamoDB doesn’t support SQL or stored procedures. Babelfish is for SQL Server T-SQL compatibility, not Oracle PL/SQL. For lift-and-shift of Oracle workloads, RDS for Oracle (or RDS Custom for Oracle with OS access) is the correct choice.

    Question 4:

    A startup is building an IoT platform that ingests sensor data from 100,000 devices. Each device sends readings every 5 seconds. The data must be stored for 30 days, after which it should be automatically deleted. The team needs to query recent data by device ID and time range. Which database solution is most cost-effective and operationally efficient?

    1. Amazon Aurora PostgreSQL with table partitioning
    2. Amazon RDS for MySQL with scheduled deletion jobs
    3. Amazon DynamoDB with TTL enabled
    4. Amazon Aurora Serverless v2 with scheduled scaling
    Show Answer

    Answer: C –

    Explanation: DynamoDB with TTL (Time to Live) is ideal for this scenario. The access pattern is simple (device_id as partition key, timestamp as sort key), enabling efficient range queries. TTL automatically deletes expired items at no cost — no scheduled jobs needed. The write volume (~20,000 writes/second from 100K devices at 5-sec intervals) is easily handled by DynamoDB’s automatic scaling. DynamoDB’s serverless model means zero operational overhead for the startup. Aurora or RDS would require instance management, manual partition pruning or deletion jobs, and would be more expensive for this write-heavy, simple-query workload.

    Question 5:

    A company runs a MySQL-based application on Amazon RDS. They are experiencing performance issues during peak hours and their DBA reports that read replica lag is causing stale data problems. They need to improve read performance with minimal replication lag while keeping MySQL compatibility. The budget allows for a 20% cost increase. What should they do?

    1. Upgrade to a larger RDS instance class
    2. Migrate to Amazon Aurora MySQL
    3. Add more RDS read replicas
    4. Migrate to Amazon DynamoDB
    Show Answer

    Answer: B –

    Explanation: Aurora MySQL provides 5x throughput improvement over standard MySQL, and its shared storage architecture means read replicas have near-zero replication lag (typically <10ms vs seconds/minutes for RDS async replicas). This directly addresses both problems: performance issues and stale read data. Aurora instances cost ~20% more than RDS (within budget). Adding more RDS replicas doesn’t fix the lag issue. A larger instance helps writes but doesn’t fix replica lag. DynamoDB would require a complete application rewrite and doesn’t maintain MySQL compatibility.

    Summary

    • Amazon RDS is the right choice for traditional relational workloads requiring specific engines (Oracle, SQL Server, MariaDB, Db2), lift-and-shift migrations, or when cost is the primary concern for steady, predictable workloads.
    • Amazon Aurora excels for MySQL/PostgreSQL workloads needing superior performance, high availability, automatic storage scaling, and modern features like Serverless v2, Limitless Database, and DSQL for distributed SQL.
    • Amazon DynamoDB is the answer for applications requiring unlimited scale, single-digit millisecond latency, zero operational overhead, and well-defined access patterns that fit a key-value or document model.
    • Many real-world architectures use multiple services together — e.g., Aurora for transactional data and DynamoDB for session stores or high-velocity data streams.
    • The selection decision should be driven by access patterns, scale requirements, and data model — not team familiarity or historical precedent.

    Frequently Asked Questions

    How do I choose between RDS, Aurora, and DynamoDB?

    Start with your data model: if you need key-value/document access patterns, choose DynamoDB. For relational data, choose Aurora for high performance and scaling needs, or standard RDS for simple workloads where cost is the priority.

    Is Aurora worth the extra cost over RDS?

    Aurora costs ~20% more than standard RDS but delivers up to 5x MySQL / 3x PostgreSQL throughput, 6-way storage replication, faster failover (30s vs 60-120s), and auto-scaling storage up to 128TB. Worth it for production workloads needing high availability.

    Can DynamoDB replace a relational database?

    DynamoDB can replace relational databases for access-pattern-driven workloads, but not for complex ad-hoc queries, multi-table joins, or analytics. It excels at single-digit millisecond key-value lookups at any scale but requires careful data modeling upfront.

    References

    Aurora vs RDS vs DynamoDB – Database Services Compared

    ~ Last updated on : ~ Kiro Agent

    AWS Aurora vs RDS vs DynamoDB – Database Services Compared

    AWS offers multiple database services, each designed for different workloads. Amazon Aurora, Amazon RDS, and Amazon DynamoDB are three of the most widely used options. Understanding their architecture, scaling capabilities, pricing models, and ideal use cases is critical for both real-world implementations and AWS certification exams.

    Overview

    • Amazon RDS – Managed relational database service supporting MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. Handles provisioning, patching, backup, and failover.
    • Amazon Aurora – Cloud-native relational database compatible with MySQL and PostgreSQL. Part of the RDS family but with a fundamentally redesigned storage architecture delivering up to 5x MySQL and 3x PostgreSQL throughput.
    • Amazon DynamoDB – Fully managed, serverless NoSQL key-value and document database delivering single-digit millisecond performance at any scale.

    Architecture

    Amazon RDS Architecture

    • Traditional database architecture with compute and storage tightly coupled on a single instance
    • Uses Amazon EBS (gp3 or io2) for storage, attached to a single DB instance
    • Multi-AZ deployment creates a synchronous standby replica in another AZ for failover
    • Multi-AZ DB Clusters (MySQL/PostgreSQL) provide one writer + two readable standbys across 3 AZs with faster failover (~35 seconds)
    • Read Replicas use asynchronous replication (up to 15 for MySQL/MariaDB, 5 for PostgreSQL/Oracle/SQL Server)
    • Supports ENA Express for improved Multi-AZ replication (2026)

    Amazon Aurora Architecture

    • Separation of compute and storage – fundamentally different from RDS
    • Shared distributed storage volume spanning 3 AZs with 6 copies of data
    • Writes acknowledged when 4 of 6 copies confirm (quorum-based)
    • Tolerates loss of 2 copies without write impact, 3 copies without read impact
    • Storage auto-scales from 10 GB up to 128 TB with no provisioning
    • Up to 15 low-latency read replicas sharing the same storage volume (replication lag typically <10ms)
    • Failover to read replica in <30 seconds (shared storage means no data copy needed)
    • Aurora Serverless – auto-scales compute capacity in ACU (Aurora Capacity Units); scales to zero; up to 30% better performance with enhanced scaling (2026)
    • Aurora Global Database – cross-region replication with <1 second lag, RPO <1 second
    • Aurora DSQL (GA May 2025) – distributed SQL with active-active multi-region writes, 99.999% availability, PostgreSQL-compatible

    Amazon DynamoDB Architecture

    • Fully serverless – no instances to provision or manage
    • Distributed across multiple AZs automatically (data replicated 3 times)
    • Partitioned by partition key for horizontal scalability
    • Supports key-value and document data models
    • Global Tables – active-active multi-region replication with multi-region strong consistency (MRSC, GA 2025) enabling zero RPO
    • Cross-account replication for Global Tables (2026)
    • DAX (DynamoDB Accelerator) provides microsecond read latency via in-memory caching

    Data Model

    Feature RDS Aurora DynamoDB
    Type Relational (SQL) Relational (SQL) NoSQL (Key-Value / Document)
    Schema Fixed schema, structured data Fixed schema, structured data Flexible schema, semi-structured
    Query Language SQL SQL (MySQL/PostgreSQL compatible) PartiQL, API-based access
    Transactions Full ACID Full ACID ACID (up to 100 items, 4 MB)
    Joins Yes (complex queries) Yes (complex queries) No native joins (denormalized design)
    Secondary Indexes Standard SQL indexes Standard SQL indexes GSI and LSI (max 20 GSI, 5 LSI)

    Scaling

    Vertical Scaling

    Aspect RDS Aurora DynamoDB
    Compute scaling Instance class change (requires downtime/failover) Instance class change OR Aurora Serverless (auto-scales ACUs in seconds) N/A – fully serverless, automatic
    Storage scaling Manual increase (up to 64 TB); auto-scaling with threshold Automatic (10 GB to 128 TB, no action needed) Unlimited – fully managed
    Max storage 64 TB (io2), 16 TB (gp3) 128 TB Virtually unlimited

    Horizontal Scaling

    Aspect RDS Aurora DynamoDB
    Read scaling Up to 5-15 Read Replicas (async) Up to 15 Read Replicas (shared storage, <10ms lag); Auto Scaling Automatic partitioning; DAX for caching
    Write scaling Single writer (vertical only) Single writer (Aurora DSQL supports multi-region active-active writes) Automatic horizontal partitioning; virtually unlimited write throughput
    Global distribution Cross-Region Read Replicas Aurora Global Database (<1s replication); Aurora DSQL (active-active) Global Tables (active-active, multi-region strong consistency)

    Pricing

    Component RDS Aurora DynamoDB
    Compute Per-hour instance pricing Per-hour (provisioned) or per-ACU-second (serverless) No compute charges (serverless)
    Storage EBS: ~$0.115/GB/month (gp3) $0.10/GB/month (includes replication) $0.25/GB/month (Standard); $0.10/GB (IA)
    I/O Included in EBS pricing (gp3: 3000 IOPS free) $0.20/million I/O requests (Standard); Aurora I/O-Optimized eliminates I/O charges for +30% compute cost On-demand: $1.25/million WRU, $0.25/million RRU; Provisioned: ~$0.00065/WCU/hour
    Savings options Reserved Instances (1yr/3yr) Reserved Instances (1yr/3yr) Reserved Capacity (up to 77% savings, 3yr); On-demand 50% price reduction (2024)
    Free Tier 750 hrs/month db.t2.micro or db.t3.micro (12 months) $100 credits at sign-up for Aurora Serverless 25 GB storage + 25 WCU + 25 RCU (always free)

    Cost Comparison Note: Aurora instances cost ~20% more per vCPU than equivalent RDS instances. However, Aurora’s shared storage and automatic replication often result in lower total cost for high-availability workloads. DynamoDB is most cost-effective for simple access patterns with predictable traffic (provisioned mode) or highly variable traffic (on-demand mode).

    Performance

    Metric RDS Aurora DynamoDB
    Throughput Standard MySQL/PostgreSQL performance Up to 5x MySQL, 3x PostgreSQL throughput Virtually unlimited (scales with partitions)
    Latency Low milliseconds Low milliseconds (optimized I/O path) Single-digit milliseconds; microseconds with DAX
    Read Replica lag Seconds to minutes (async) <10ms (shared storage) Eventually consistent reads return latest; strongly consistent available
    Connection model Connection-based (limited by instance) Connection-based; RDS Proxy for pooling HTTP API (connectionless, unlimited concurrent)

    Availability & Durability

    Feature RDS Aurora DynamoDB
    SLA 99.95% (Multi-AZ) 99.99% (Multi-AZ) 99.99% (single region); 99.999% (Global Tables)
    Failover time ~60 seconds (Multi-AZ instance); ~35 seconds (Multi-AZ cluster) <30 seconds (shared storage) Automatic, transparent (no failover concept)
    Data replication Synchronous to 1-2 standbys 6 copies across 3 AZs (quorum writes) 3 copies across multiple AZs
    Cross-region DR Cross-Region Read Replicas (manual promotion) Aurora Global Database (managed failover, RPO <1s) Global Tables (active-active, zero RPO with MRSC)

    Backup & Disaster Recovery

    Feature RDS Aurora DynamoDB
    Automated backups Daily snapshots + transaction logs; retention 0-35 days Continuous backup to S3; retention 1-35 days Continuous backups with PITR (35-day retention)
    Point-in-time recovery Yes (to any second within retention) Yes (to any second); Backtrack for in-place rewind (MySQL only) Yes (to any second within 35 days)
    Manual snapshots Yes (retained until deleted) Yes (retained until deleted) On-demand backups (retained until deleted)
    Cross-region backup Copy snapshots cross-region; AWS Backup (Multi-AZ clusters in 17 regions, 2026) Copy snapshots cross-region; AWS Backup AWS Backup cross-region/cross-account
    Restore method Creates new DB instance Creates new cluster (Backtrack restores in-place) Creates new table

    Security

    Feature RDS Aurora DynamoDB
    Network isolation VPC, Security Groups, Private Subnets VPC, Security Groups, Private Subnets VPC Endpoints (Gateway); no VPC placement needed
    Encryption at rest AES-256 with KMS (must enable at creation) AES-256 with KMS (must enable at creation) AES-256 with KMS (enabled by default)
    Encryption in transit SSL/TLS SSL/TLS (enforced by default) TLS (all API calls over HTTPS)
    Authentication DB user/password, IAM DB Auth, Kerberos/AD DB user/password, IAM DB Auth, Kerberos/AD IAM policies, fine-grained access control (condition keys)
    Access control IAM for management; DB-level GRANT for data IAM for management; DB-level GRANT for data IAM policies with item-level and attribute-level control

    When to Choose Each Service

    Choose Amazon RDS When:

    • You need a traditional relational database with minimal migration effort
    • You require Oracle, SQL Server, or MariaDB engine support
    • Budget is a primary concern and Aurora’s premium isn’t justified
    • Workload is moderate with predictable growth
    • You need OS-level access (RDS Custom for Oracle/SQL Server)
    • Simple Multi-AZ failover meets your HA requirements

    Choose Amazon Aurora When:

    • You need MySQL/PostgreSQL compatibility with significantly higher performance
    • High availability (99.99% SLA) and fast failover (<30s) are critical
    • You need 15 read replicas with minimal lag
    • Storage auto-scaling up to 128 TB is required
    • You need global distribution with Aurora Global Database
    • Variable workloads benefit from Aurora Serverless (scale to zero)
    • You want Backtrack for in-place point-in-time rewind (MySQL)
    • You need distributed SQL with active-active writes (Aurora DSQL)

    Choose Amazon DynamoDB When:

    • You need single-digit millisecond latency at any scale
    • Access patterns are well-defined (key-value lookups, simple queries)
    • You need virtually unlimited horizontal scaling for reads and writes
    • Serverless/zero-management operation is a priority
    • Global active-active replication is needed (Global Tables)
    • Event-driven architectures (DynamoDB Streams → Lambda)
    • Gaming leaderboards, session stores, IoT data, shopping carts
    • Traffic is highly variable or unpredictable (on-demand mode)

    Comprehensive Comparison Table

    Feature Amazon RDS Amazon Aurora Amazon DynamoDB
    Database Type Relational (SQL) Relational (SQL) NoSQL (Key-Value/Document)
    Engines MySQL, PostgreSQL, MariaDB, Oracle, SQL Server MySQL-compatible, PostgreSQL-compatible Proprietary NoSQL
    Management Managed (provisioned instances) Managed (provisioned) or Serverless Fully serverless
    Max Storage 64 TB 128 TB (auto-scaling) Unlimited
    Performance Standard engine performance 5x MySQL / 3x PostgreSQL Single-digit ms; microseconds with DAX
    Read Replicas Up to 5-15 (async) Up to 15 (shared storage, <10ms lag) N/A (automatic distribution)
    Write Scaling Vertical only Vertical (DSQL: horizontal) Automatic horizontal
    Availability SLA 99.95% 99.99% 99.99% / 99.999% (Global)
    Failover ~35-60 seconds <30 seconds Automatic (no downtime)
    Backup Automated + Manual snapshots Continuous + Backtrack + Snapshots PITR (35 days) + On-demand backups
    Global Replication Cross-Region Read Replicas Global Database (<1s lag) Global Tables (active-active, MRSC)
    Serverless Option No Aurora Serverless (scale to zero) Fully serverless (always)
    Transactions Full ACID Full ACID ACID (limited scope)
    Best For Traditional RDBMS workloads, multi-engine support High-performance relational, global apps High-scale key-value, serverless apps

    AWS Certification Practice Questions

    Question 1

    A company is designing a new e-commerce platform that requires sub-millisecond read latency for its product catalog, which contains millions of items accessed by product ID. The application has unpredictable traffic spikes during flash sales. Which database solution is MOST appropriate?

    1. Amazon RDS MySQL with Multi-AZ deployment
    2. Amazon Aurora PostgreSQL with Read Replicas
    3. Amazon DynamoDB with DAX
    4. Amazon RDS PostgreSQL with ElastiCache
    Show Answer

    Answer: C –

    Explanation: DynamoDB with DAX provides microsecond read latency for key-value lookups. Its on-demand mode handles unpredictable traffic spikes without pre-provisioning. The product catalog accessed by product ID is a perfect key-value pattern.

    Question 2

    A financial services company needs a relational database with 99.99% availability, automatic storage scaling, and the ability to perform point-in-time recovery by rewinding the database to a specific time without creating a new instance. Which service supports this requirement?

    1. Amazon RDS Multi-AZ with automated backups
    2. Amazon Aurora MySQL with Backtrack
    3. Amazon DynamoDB with PITR enabled
    4. Amazon RDS Multi-AZ DB Cluster with AWS Backup
    Show Answer

    Answer: B –

    Explanation: Aurora Backtrack (MySQL only) allows rewinding the database in-place to a specific point in time without creating a new cluster. Combined with Aurora’s 99.99% SLA and auto-scaling storage, it meets all requirements. RDS PITR creates a new instance, not an in-place rewind.

    Question 3

    A global gaming company needs a database that supports active-active writes across multiple AWS Regions with strong consistency and zero RPO for disaster recovery. The data model is simple player profiles accessed by player ID. Which solution meets these requirements?

    1. Amazon Aurora Global Database with managed failover
    2. Amazon RDS with Cross-Region Read Replicas
    3. Amazon DynamoDB Global Tables with multi-region strong consistency (MRSC)
    4. Amazon Aurora DSQL with multi-Region cluster
    Show Answer

    Answer: C –

    Explanation: DynamoDB Global Tables with MRSC (GA 2025) provides active-active multi-region writes with strong consistency and zero RPO. The simple key-value access pattern (player ID lookup) is ideal for DynamoDB. Aurora Global Database is single-writer with RPO <1s (not zero). Aurora DSQL also supports multi-region active-active writes but the simple data model makes DynamoDB the most appropriate choice.

    Question 4

    A startup is building a SaaS application with variable traffic. During business hours, the database handles 10,000 transactions/second, but at night traffic drops to near zero. They need MySQL compatibility and want to minimize costs. Which solution is MOST cost-effective?

    1. Amazon RDS MySQL with Reserved Instances
    2. Amazon Aurora MySQL Serverless
    3. Amazon DynamoDB with on-demand capacity
    4. Amazon Aurora MySQL provisioned with Auto Scaling replicas
    Show Answer

    Answer: B –

    Explanation: Aurora Serverless scales compute capacity automatically based on demand and can scale to zero during idle periods. This is the most cost-effective option for variable workloads requiring MySQL compatibility. RDS Reserved Instances charge for 24/7 capacity. DynamoDB doesn’t provide SQL/MySQL compatibility.

    Question 5

    A company is migrating a legacy Oracle database to AWS. The application uses complex SQL queries with multiple joins, stored procedures, and requires Oracle-specific features. They need Multi-AZ high availability. Which AWS database service should they use? (Select TWO)

    1. Amazon Aurora PostgreSQL (Oracle-compatible mode)
    2. Amazon RDS for Oracle with Multi-AZ
    3. Amazon DynamoDB with complex access patterns
    4. Amazon RDS Custom for Oracle with Multi-AZ
    5. Amazon Aurora MySQL with stored procedures
    Show Answer

    Answer: B, D

    Explanation: Amazon RDS for Oracle provides managed Oracle database with Multi-AZ HA. RDS Custom for Oracle allows OS and database customization for Oracle-specific features requiring elevated access. Aurora does not support Oracle. DynamoDB doesn’t support SQL joins or stored procedures. Note: RDS Custom for Oracle EOL is March 31, 2027 – plan migration to RDS for Oracle or alternative.

    Key Takeaways

    • RDS is the go-to managed relational database when you need specific engines (Oracle, SQL Server, MariaDB) or traditional RDBMS at moderate scale
    • Aurora is the premium relational choice for MySQL/PostgreSQL workloads needing higher performance, better availability, and advanced features like Serverless, Global Database, and Backtrack
    • DynamoDB is the choice for NoSQL key-value workloads requiring unlimited scale, serverless operation, single-digit millisecond latency, and global active-active replication
    • All three services integrate with AWS security features (KMS encryption, IAM, VPC/VPC Endpoints, CloudTrail)
    • Cost optimization: Use Reserved Instances (RDS/Aurora) or Provisioned + Reserved Capacity (DynamoDB) for steady workloads; use Aurora Serverless or DynamoDB On-Demand for variable workloads

    Frequently Asked Questions

    What is the difference between Aurora and RDS?

    Aurora is AWS’s cloud-native database with up to 5x MySQL and 3x PostgreSQL performance, 6-way storage replication, and up to 128TB auto-scaling storage. Standard RDS uses traditional database engines with simpler architecture and lower cost for small workloads.

    When should I use DynamoDB instead of Aurora?

    Use DynamoDB for key-value/document workloads needing single-digit millisecond latency at any scale, serverless applications, or when you need global multi-region active-active replication. Use Aurora for complex SQL queries, joins, and transactions.

    Is Aurora Serverless good for production?

    Aurora Serverless v2 is production-ready and scales instantly in fine-grained 0.5 ACU increments. It’s ideal for variable workloads, dev/test environments, and applications with unpredictable traffic patterns.

    See also: Aurora DSQL – Serverless Distributed SQL Database

    References