AWS Database Services: RDS, DynamoDB & Aurora

Database selection is often the most impactful architectural decision. Interviewers assess your ability to match database characteristics to workload requirements.

Database Selection Framework

Decision Matrix

Factor	Relational (RDS/Aurora)	NoSQL (DynamoDB)	In-Memory (ElastiCache)
Data Model	Structured, normalized	Key-value, document	Key-value, sets, lists
Query Patterns	Complex joins, aggregations	Single-table, predictable	Simple lookups, counters
Scalability	Vertical (read replicas)	Horizontal (partitioning)	Horizontal (sharding)
Consistency	Strong (ACID)	Eventually consistent (configurable)	Eventually consistent
Use Case	Transactions, reporting	High-scale web/mobile	Caching, sessions

RDS: Managed Relational Databases

Engine Comparison

Engine	Strengths	Considerations
PostgreSQL	Extensions, JSON support, compliance	Complex replication setup
MySQL	Wide adoption, tooling ecosystem	Limited JSON support
MariaDB	MySQL-compatible, open source	Smaller community
Oracle	Enterprise features, PL/SQL	Licensing costs
SQL Server	Windows ecosystem, BI tools	Licensing costs

Interview Question: RDS High Availability

Q: "Design a highly available MySQL database for a financial application requiring RPO < 1 minute and RTO < 5 minutes."

A: Multi-AZ with enhanced monitoring:

Primary Configuration:
  - db.r6g.xlarge (Graviton, cost-efficient)
  - Multi-AZ deployment (synchronous replication)
  - gp3 storage (16,000 IOPS provisioned)
  - Automated backups (35-day retention)

High Availability:
  - Multi-AZ: Automatic failover < 60 seconds
  - Read Replicas: 2x in same region for read scaling
  - Cross-Region Replica: DR in us-west-2

Monitoring:
  - Enhanced Monitoring (1-second granularity)
  - Performance Insights enabled
  - CloudWatch alarms on replication lag

RPO/RTO Achievement:

• Multi-AZ: RPO = 0 (synchronous), RTO < 2 minutes
• Cross-Region: RPO < 1 minute (async), RTO < 5 minutes (manual promotion)

Aurora: Cloud-Native Relational

Aurora Architecture

Aurora separates compute and storage:

• Compute: DB instances (writer + readers)
• Storage: Distributed, auto-scaling (up to 128TB)
• Replication: 6-way replication across 3 AZs

Aurora vs RDS Comparison

Feature	Aurora	RDS
Storage Scaling	Automatic (10GB increments)	Manual (requires downtime)
Replication Lag	< 20ms typically	Minutes possible
Failover Time	< 30 seconds	60-120 seconds
Read Replicas	Up to 15	Up to 5
Cost	~20% higher	Baseline
Global Database	Yes (< 1 second replication)	Cross-region read replica only

Interview Question: Aurora Serverless v2

Q: "When would you choose Aurora Serverless v2 over provisioned Aurora?"

A: Aurora Serverless v2 suits:

• Variable workloads: Dev/test with unpredictable usage
• Bursty traffic: Scales instantly (0.5 ACU increments)
• Cost optimization: Pay per ACU-hour
• Multi-tenant: Different tenants with varying load

Choose Provisioned when:

• Consistent, predictable workload
• Maximum performance required (no cold start)
• Cost certainty is priority
• Already sized for peak capacity

Hybrid Approach: Provisioned writer + Serverless v2 readers for optimal cost/performance.

DynamoDB: Serverless NoSQL

Capacity Modes

Mode	Best For	Pricing
On-Demand	Unknown/variable traffic	Pay per request
Provisioned	Predictable traffic	Reserved capacity, lower cost
Auto Scaling	Known patterns with peaks	Scales within limits

DynamoDB Patterns

Single-Table Design:

PK                  SK                 Attributes
USER#123            PROFILE            {name, email}
USER#123            ORDER#456          {total, status}
USER#123            ORDER#789          {total, status}
ORDER#456           ORDER#456          {userId, items}

Access Patterns:

• Get user profile: PK=USER#123, SK=PROFILE
• Get user orders: PK=USER#123, SK begins_with ORDER#
• Get order details: PK=ORDER#456, SK=ORDER#456

Interview Question: DynamoDB Hot Partition

Q: "Your DynamoDB table is experiencing throttling due to a hot partition. How do you resolve it?"

A: Hot partition mitigation strategies:

1. Identify the hot key: Enable CloudWatch Contributor Insights
2. Add randomness to partition key:

   # Instead of: PK = "STATUS#PENDING"
   # Use: PK = "STATUS#PENDING#" + random(1-10)
   

3. Use write sharding with scatter-gather reads
4. Implement caching layer: DAX for read-heavy, ElastiCache for write-buffering
5. Consider on-demand mode: No throttling (but higher cost)

DynamoDB Global Tables

Feature	Multi-Region Benefit
Active-Active	Write to any region
Replication Lag	< 1 second typically
Conflict Resolution	Last writer wins
Use Case	Global apps, DR

ElastiCache: In-Memory Caching

Redis vs Memcached

Feature	Redis	Memcached
Data Structures	Strings, lists, sets, hashes	Strings only
Persistence	Yes (RDB, AOF)	No
Replication	Yes (primary-replica)	No
Clustering	Yes (sharding)	Yes
Use Case	Complex caching, sessions	Simple caching

Interview Question: Caching Strategy

Q: "Design a caching strategy for an e-commerce product catalog with 1M products."

A: Multi-tier caching approach:

Layer 1: CloudFront (Edge)
  - Cache static product images
  - TTL: 24 hours

Layer 2: ElastiCache Redis (Application)
  - Cache product details JSON
  - TTL: 1 hour (configurable per category)
  - Cluster mode: 3 shards, 2 replicas each
  - Memory: r6g.large per node (13GB)

Layer 3: DynamoDB DAX (Database)
  - Cache hot items
  - TTL: 5 minutes
  - Reduces DynamoDB read costs

Invalidation:
  - Event-driven: SNS on product update
  - Pattern: Cache-aside with lazy loading

Database Decision Tree

Need ACID transactions?
  └── Yes → Relational
       ├── Cloud-native, auto-scaling? → Aurora
       └── Traditional, lower cost? → RDS
  └── No → NoSQL
       ├── Key-value, predictable access? → DynamoDB
       ├── Document store, flexible schema? → DocumentDB
       └── Graph relationships? → Neptune

Need caching?
  └── Simple key-value? → ElastiCache Memcached
  └── Complex structures, persistence? → ElastiCache Redis
  └── DynamoDB-specific? → DAX

Interview Tip: Always discuss backup strategy, encryption at rest/in transit, and monitoring when presenting database architecture.

This concludes the AWS Architecture module. Test your knowledge with the module quiz. :::