AWS Database Services — RDS, DynamoDB, ElastiCache

Key Takeaways

• RDS Multi-AZ = high availability failover (synchronous standby in same region). Read Replica = read scaling (asynchronous copy, can be cross-region).
• DynamoDB partition key: choose for maximum cardinality and uniform access distribution to avoid hot partitions.
• DAX = in-memory cache for DynamoDB, microsecond reads — ideal for read-heavy, non-relational workloads.
• ElastiCache Redis supports persistence, pub/sub, sorted sets. Memcached = simpler, multi-threaded, no persistence by default.

Amazon RDS (Relational Database Service)

Managed Database Service: Simplifies setup, operation, and scaling of relational databases. Supports MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora.

Key Features:

• Multi-AZ deployments for high availability and automatic failover
• Read replicas for read performance and scalability
• Automated daily backups, snapshots, and point-in-time recovery
• VPC isolation, encryption at rest/in transit, IAM-based access control
• CloudWatch monitoring and Performance Insights for detailed analysis

Interview Angle

Multi-AZ vs Read Replica:
Multi-AZ = high availability (automatic failover, same region, synchronous writes to standby). Read Replica = read scalability (asynchronous replication, can be cross-region, manual promotion if needed). Exam tests this distinction constantly—understand why you’d use each.

Common Gotcha

RDS Read Replicas are NOT automatic failover targets. Only Multi-AZ standby instances are. You can manually promote a replica to standalone, but it’s not automatic.

---

Amazon Aurora

High-performance, fully managed relational database compatible with MySQL and PostgreSQL. Automatically replicates across three Availability Zones with continuous backup to S3.

Key Features:

• 5x throughput of standard MySQL, 3x of PostgreSQL
• Automatic failover and continuous backup
• Serverless option scales automatically based on application needs
• Global Databases span multiple AWS regions

---

Amazon DynamoDB

Fully managed NoSQL key-value and document database. Tables store items with attributes. Single-digit millisecond response times at any scale.

Partition Key Design:
Choose partition keys with high cardinality and uniform access distribution. DynamoDB distributes items across partitions—uneven access causes hot partitions and throttling.

Interview Angle

Hot Partition Problem: If all writes target the same partition key (e.g., a timestamp), DynamoDB throttles. Fix: add a random suffix to the key (write sharding) or use a more distributed key. You’ll see this on the exam.

Global Secondary Indexes (GSI) & Local Secondary Indexes (LSI):
Enable flexible querying beyond the partition key. GSI can be created/deleted post-table creation; LSI is fixed at table creation with 10 GB size limit.

DynamoDB Streams:
Capture item-level changes (INSERT, MODIFY, REMOVE) in real-time. Often paired with Lambda for event-driven processing.

Interview Angle

DynamoDB Streams + Lambda: A change to any DynamoDB item triggers a Lambda function. Know the event format (INSERT, MODIFY, REMOVE) and that Streams retain records for 24 hours. This is a standard event-driven architecture pattern on the exam.

DAX (DynamoDB Accelerator):
In-memory cache layer providing microsecond latencies for read-heavy workloads. Sits between application and DynamoDB table.

Common Gotcha

DynamoDB does NOT support joins. It’s key-value/document store, not relational. Plan your data model accordingly—denormalize or use application-level joins.

---

Amazon ElastiCache

Fully managed in-memory data store using Redis or Memcached. Sub-millisecond response times ideal for caching, session management, and real-time analytics.

Redis vs Memcached:

Feature	Redis	Memcached
Persistence	Yes (RDB, AOF)	No (in-memory only)
Pub/Sub	Yes	No
Sorted Sets	Yes	No
Replication	Multi-AZ automatic failover	Simple replication
Multi-threading	Single-threaded	Multi-threaded
Use Case	Complex operations, durability	Simple caching, ultra-high throughput

Interview Angle

Lazy Loading vs Write-Through:
Lazy loading caches only on cache miss (cheap writes, stale data risk). Write-through updates cache on every write (fresh data, higher latency). Exam scenarios test when each pattern fits—know the tradeoffs.

High Availability:
Redis supports Multi-AZ with automatic failover. Memcached requires manual setup. Choose Redis for HA needs.

Common Gotcha

ElastiCache is NOT durable by default (Memcached especially). Redis with persistence (RDB or AOF) adds durability but trades some latency for data safety. Understand your durability requirements.

---

Amazon MemoryDB for Redis

Fully managed Redis-compatible database designed for high throughput and low latency with built-in durability.

Key Features:

• Data replicated across multiple nodes and backed up to disk
• Multi-AZ replication with automatic failover
• Encryption at rest/in transit, VPC isolation, IAM integration
• Scales read/write capacity independently

---

Best Practices Summary

High Availability: Multi-AZ deployments for synchronous standby failover. Read replicas for read scalability (asynchronous).

Scalability: DynamoDB on-demand mode for instant scaling. Aurora Serverless auto-scales compute. ElastiCache sharding for horizontal scaling.

Backup & Recovery: Automate backups and snapshots. Test point-in-time recovery regularly.

Security: Encrypt data at rest/in transit. Use IAM roles, VPC isolation. Rotate credentials.

Monitoring: CloudWatch metrics, RDS Performance Insights, DynamoDB throttle alarms.

Cost Management: Right-size instances, use Reserved Instances for long-term, monitor over-provisioning.

---

Aurora Serverless v1 Cold Start

Aurora Serverless v1 has cold start latency when scaling from zero—not suitable for latency-sensitive apps. Serverless v2 mitigates this with better scaling speed.