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.

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

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

Availability and Disaster Recovery

Security Features

Decision Flowchart: Selecting Your Database

Common Use Case Mapping

Key Tradeoffs to Consider

AWS Certification Exam Tips

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

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

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

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

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

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

• Amazon RDS
• Amazon Aurora
• Amazon DynamoDB
• Differences between Aurora and RDS
• Aurora Serverless v2
• Aurora PostgreSQL Limitless Database
• Aurora DSQL – Generally Available
• DynamoDB 2024 Year in Review

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

Scaling

Vertical Scaling

Horizontal Scaling

Pricing

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

Availability & Durability

Backup & Disaster Recovery

Security

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

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

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

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

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

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

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

• Amazon RDS Documentation
• Amazon Aurora Documentation
• Amazon DynamoDB Documentation
• AWS: Differences between Aurora and RDS
• Amazon Aurora DSQL
• DynamoDB Global Tables