3.5 Database Services - RDS, Aurora, DynamoDB, and More

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

3.5 Database Services - RDS, Aurora, DynamoDB, and More

Key Takeaways Explain This Topic AI

RDS manages six engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2) with automated backups, point-in-time recovery up to 35 days, and Multi-AZ failover.

Aurora is AWS-built, MySQL/PostgreSQL-compatible, replicates 6 copies across 3 AZs, scales storage up to 256 TiB on current engine versions (128 TiB on earlier versions), supports up to 15 low-lag read replicas, and fails over in under 30 seconds.

DynamoDB is serverless NoSQL with single-digit-millisecond latency, on-demand or provisioned capacity, Global Tables for active-active multi-Region, and DAX for microsecond reads.

ElastiCache for Redis adds replication, persistence, and Multi-AZ failover; Memcached is simple, multi-threaded, no persistence or failover.

Match the data model: relational HA -> Aurora/RDS Multi-AZ; key-value at scale -> DynamoDB; caching -> ElastiCache; analytics/OLAP -> Redshift; graph -> Neptune.

Last updated: October 2026

Quick Answer: Relational SQL -> RDS or Aurora (Aurora for higher performance/HA). Key-value/document at any scale -> DynamoDB. Caching -> ElastiCache (Redis for features, Memcached for simple multi-threaded). Analytics/OLAP -> Redshift. Graph -> Neptune. MongoDB-compatible -> DocumentDB. Pick the purpose-built database for the data model.

Amazon RDS

RDS is managed relational database hosting for six engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2). AWS handles provisioning, patching, backups, and failover; you keep schema and query control. Automated backups enable point-in-time recovery up to 35 days .

Read Replicas vs Multi-AZ (a constant exam trap)

• Feature Read Replicas Multi-AZ DB instance
• Purpose Scale reads High availability
• Replication Asynchronous Synchronous to standby
• Readable? Yes, serve read traffic No, standby is passive
• Cross-Region Yes No (same Region)
• Failover Manual promotion Automatic (typically 60-120s)

They solve different problems and are often combined: read replicas for read scaling and Multi-AZ for failover. "Scale read-heavy reporting" -> read replicas; "automatic failover for HA" -> Multi-AZ.

Amazon Aurora

Aurora is an AWS-engineered relational engine compatible with MySQL and PostgreSQL, delivering up to 5x MySQL and 3x PostgreSQL throughput.

Feature Detail

Storage 6 copies across 3 AZs, auto-grows up to 256 TiB on current engine versions (128 TiB on earlier versions)

• Durability Survives loss of 2 copies for writes, 3 for reads
• Read replicas Up to 15, typically <10 ms lag, shared storage
• Failover Promotes a replica in under 30 seconds
• Backtrack Rewind in place to a prior second without a restore
• Cloning Copy-on-write clone, instant, no initial storage cost

Aurora Serverless v2 scales compute in increments as small as 0.5 ACU, between a minimum as low as 0 ACUs (on versions that support automatic pause) and a maximum of 256 ACUs for Aurora MySQL or 384 ACUs (Aurora Capacity Units) for Aurora PostgreSQL, following demand - ideal for spiky or multi-tenant workloads where you do not want to size a fixed instance.

Amazon DynamoDB

DynamoDB is a serverless NoSQL key-value and document database with single-digit-millisecond latency at any scale and no servers to manage.

• Feature Detail
• Capacity modes On-Demand (pay-per-request) or Provisioned (RCU/WCU + auto-scaling)
• Global Tables Active-active, multi-Region replication
• DAX In-memory accelerator delivering microsecond reads
• Streams Item-level change feed (trigger Lambda, replicate)
• TTL Auto-expire items at no cost
• PITR Continuous backups, restore up to 35 days

Use On-Demand for spiky or new workloads with no capacity planning; use Provisioned with auto-scaling for predictable traffic to lower cost. Add DAX when read-heavy traffic repeatedly reads the same hot items and needs microsecond latency.

Amazon ElastiCache

• Feature Redis Memcached
• Data structures Strings, hashes, lists, sets, sorted sets, streams Simple key-value
• Persistence Yes (snapshots + AOF) No
• Replication / failover Multi-AZ with automatic failover None
• Pub/Sub, backup Yes No
• Threading Single-threaded per shard Multi-threaded

Choose Redis when you need replication, persistence, failover, or rich data types (leaderboards, sessions, real-time analytics). Choose Memcached for a simple, horizontally scalable, multi-threaded cache where losing the cache is acceptable.

Other Purpose-Built Databases

• Service Type Use case
• Redshift Columnar warehouse (OLAP) BI/analytics on terabytes-petabytes
• Neptune Graph Social graphs, fraud detection, knowledge graphs
• DocumentDB MongoDB-compatible document Catalogs, content management, profiles
• Keyspaces Cassandra-compatible wide-column Time-series, high-write IoT
• Timestream Time-series IoT and DevOps metrics
• QLDB Immutable ledger Audit trails, financial records
• MemoryDB Durable Redis-compatible Primary database with in-memory speed

On the Exam: "Generate complex BI reports over huge historical data" -> Redshift (OLAP), NOT RDS/Aurora (OLTP). "Single-digit-ms key lookups at unpredictable scale" -> DynamoDB. "Detect fraud via relationship traversal" -> Neptune.

Worked Scenario: Combining HA and Read Scaling

A production PostgreSQL workload on RDS suffers two problems: read-heavy reporting queries slow the primary, and a recent AZ event caused downtime. The correct design addresses each with a different feature rather than one tool. Deploy Multi-AZ to get a synchronous standby with automatic failover (typically 60-120 seconds) for high availability, and separately add read replicas to offload reporting traffic from the primary. These are complementary, not alternatives - a frequent exam trap is to assume Multi-AZ also serves read traffic, but a Multi-AZ DB instance's standby is passive and unreadable (only the Multi-AZ DB cluster option has standbys that serve reads).

If the same workload later needs higher performance and up to 15 fast replicas, migrating to Aurora (MySQL/PostgreSQL-compatible) is the natural next step.

Common Traps to Avoid

Multi-AZ is not read scaling. A Multi-AZ DB instance's standby cannot serve reads (a Multi-AZ DB cluster's standbys can); use read replicas for read scaling and Multi-AZ for failover. Combine them when you need both.

Redshift for OLTP. Redshift is a columnar OLAP warehouse for analytics; never pick it for high-volume transactional reads/writes - that is RDS, Aurora, or DynamoDB.

DynamoDB for relational joins. If the question requires complex joins, transactions across many tables, or ad-hoc SQL, that is relational (RDS/Aurora), not DynamoDB.

Memcached when persistence or failover is required. Memcached has no replication, failover, or persistence; ElastiCache for Redis provides all three.

Aurora Serverless v2 minimum. On versions that support automatic pause, the minimum capacity can be 0 ACUs, so an idle cluster scales to zero; with a nonzero minimum such as 0.5 ACU, an idle workload still incurs a small floor charge - factor that into very spiky or dev/test cost estimates.