🗄️
Databases - RDS, DynamoDB, Aurora
RDS, Aurora, DynamoDB & ElastiCache
⏱️ Estimated reading time: 25 minutes
Amazon RDS - Relational Database Service
RDS is a managed relational database service that makes it easy to set up, operate, and scale databases in the cloud.
Supported Engines:
- Amazon Aurora: MySQL and PostgreSQL compatible (AWS proprietary)
- MySQL: Versions 5.7, 8.0
- PostgreSQL: Versions 11-15
- MariaDB: MySQL compatible
- Oracle: Standard and Enterprise editions
- SQL Server: Express, Web, Standard, Enterprise
Advantages over self-managed database:
- Automated provisioning, OS patching
- Continuous backups with point-in-time restore
- Monitoring dashboards
- Read Replicas for read scaling
- Multi-AZ for disaster recovery
- Maintenance windows for upgrades
- Vertical and horizontal scaling
Supported Engines:
- Amazon Aurora: MySQL and PostgreSQL compatible (AWS proprietary)
- MySQL: Versions 5.7, 8.0
- PostgreSQL: Versions 11-15
- MariaDB: MySQL compatible
- Oracle: Standard and Enterprise editions
- SQL Server: Express, Web, Standard, Enterprise
Advantages over self-managed database:
- Automated provisioning, OS patching
- Continuous backups with point-in-time restore
- Monitoring dashboards
- Read Replicas for read scaling
- Multi-AZ for disaster recovery
- Maintenance windows for upgrades
- Vertical and horizontal scaling
🎯 Key Points
- ✓ Cannot SSH to RDS instances (fully managed)
- ✓ Storage backed by EBS (gp2, gp3, io1)
- ✓ Automated backups enabled by default (1-35 days retention)
- ✓ Manual snapshots don't expire automatically
- ✓ Read Replicas can be same-AZ, cross-AZ, or cross-region
RDS Multi-AZ and Read Replicas
RDS offers two main mechanisms for high availability and scaling:
Multi-AZ (Disaster Recovery):
- Automatic synchronous replica in another AZ
- Single DNS name, automatic failover to standby
- Standby cannot be used for reads (only failover)
- No downtime to enable Multi-AZ (from snapshot)
- Protects against AZ loss, network loss, storage failure
Read Replicas (Read Scaling):
- Asynchronous replica (up to 15 read replicas per master)
- Applications must update connection string to use replicas
- Can be cross-AZ or cross-region
- Can be promoted to standalone database
- Use: Analytics, reporting without impacting production
Key Differences:
- Multi-AZ = Disaster Recovery (automatic failover)
- Read Replica = Performance/Scaling (manual application changes)
Multi-AZ (Disaster Recovery):
- Automatic synchronous replica in another AZ
- Single DNS name, automatic failover to standby
- Standby cannot be used for reads (only failover)
- No downtime to enable Multi-AZ (from snapshot)
- Protects against AZ loss, network loss, storage failure
Read Replicas (Read Scaling):
- Asynchronous replica (up to 15 read replicas per master)
- Applications must update connection string to use replicas
- Can be cross-AZ or cross-region
- Can be promoted to standalone database
- Use: Analytics, reporting without impacting production
Key Differences:
- Multi-AZ = Disaster Recovery (automatic failover)
- Read Replica = Performance/Scaling (manual application changes)
🎯 Key Points
- ✓ Multi-AZ is synchronous, Read Replica is asynchronous
- ✓ Multi-AZ has no intra-AZ data transfer charge
- ✓ Cross-region Read Replicas have transfer charge
- ✓ You can have Multi-AZ + Read Replicas simultaneously
- ✓ Multi-AZ failover takes ~60-120 seconds
Amazon Aurora
Aurora is an AWS proprietary relational database compatible with MySQL and PostgreSQL, optimized for the cloud.
Advantages over RDS MySQL/PostgreSQL:
- 5x better performance than MySQL, 3x than PostgreSQL
- Auto-scaling storage: grows automatically in 10GB increments (up to 128TB)
- Up to 15 read replicas (vs 5 in RDS)
- Instant failover (<30 seconds)
- Cost ~20% more than RDS, but more efficient
Architecture:
- 6 copies of data across 3 AZ (4/6 for writes, 3/6 for reads)
- Auto-healing with peer-to-peer replication
- Storage striped across hundreds of volumes
- One master for writes
- Up to 15 read replicas with auto-scaling
Special Features:
- Aurora Serverless: Auto-scaling capacity, pay per second
- Aurora Global Database: Cross-region, <1 second replication lag
- Aurora Multi-Master: Multiple write instances
- Backtrack: Restore data at any point without backups
Advantages over RDS MySQL/PostgreSQL:
- 5x better performance than MySQL, 3x than PostgreSQL
- Auto-scaling storage: grows automatically in 10GB increments (up to 128TB)
- Up to 15 read replicas (vs 5 in RDS)
- Instant failover (<30 seconds)
- Cost ~20% more than RDS, but more efficient
Architecture:
- 6 copies of data across 3 AZ (4/6 for writes, 3/6 for reads)
- Auto-healing with peer-to-peer replication
- Storage striped across hundreds of volumes
- One master for writes
- Up to 15 read replicas with auto-scaling
Special Features:
- Aurora Serverless: Auto-scaling capacity, pay per second
- Aurora Global Database: Cross-region, <1 second replication lag
- Aurora Multi-Master: Multiple write instances
- Backtrack: Restore data at any point without backups
🎯 Key Points
- ✓ Aurora is cloud-native, not MySQL/PostgreSQL with improvements
- ✓ Separation of compute and storage
- ✓ Backups, failover, and recovery are faster
- ✓ Aurora Serverless ideal for unpredictable/intermittent loads
- ✓ Global Database for DR and low global latency
Amazon DynamoDB
DynamoDB is a fully managed NoSQL database, key-value and document, with single-digit millisecond latency at any scale.
Features:
- Fully managed: No servers to provision
- Performance: Consistent <10ms latency
- Scaling: Millions requests/second, trillions of rows, 100TB data
- High availability: Multi-AZ replication by default
- Security: IAM integration, encryption at rest and in transit
Key Concepts:
- Primary Key: Partition Key (hash) or Partition Key + Sort Key (range)
- Partition Key: Determines physical partition (must have high cardinality)
- Sort Key: Enables ranged queries, ordered data
- Attributes: Additional data (flexible schema)
- Item: Row (max 400KB)
Capacity:
- Provisioned: Specify RCU (Read) and WCU (Write), cheaper if predictable
- On-Demand: Pay per request, auto-scaling, ideal for unpredictable traffic
Features:
- Fully managed: No servers to provision
- Performance: Consistent <10ms latency
- Scaling: Millions requests/second, trillions of rows, 100TB data
- High availability: Multi-AZ replication by default
- Security: IAM integration, encryption at rest and in transit
Key Concepts:
- Primary Key: Partition Key (hash) or Partition Key + Sort Key (range)
- Partition Key: Determines physical partition (must have high cardinality)
- Sort Key: Enables ranged queries, ordered data
- Attributes: Additional data (flexible schema)
- Item: Row (max 400KB)
Capacity:
- Provisioned: Specify RCU (Read) and WCU (Write), cheaper if predictable
- On-Demand: Pay per request, auto-scaling, ideal for unpredictable traffic
🎯 Key Points
- ✓ NoSQL = no joins, no complex aggregations (use SQL databases for that)
- ✓ Partition Key must distribute data uniformly
- ✓ Global Secondary Index (GSI): new partition/sort key
- ✓ Local Secondary Index (LSI): same partition key, different sort key
- ✓ DynamoDB Streams captures changes (integrates with Lambda)
💻 Basic DynamoDB operations
# Create table
aws dynamodb create-table \n --table-name Users \n --attribute-definitions \n AttributeName=UserId,AttributeType=S \n AttributeName=Email,AttributeType=S \n --key-schema \n AttributeName=UserId,KeyType=HASH \n AttributeName=Email,KeyType=RANGE \n --billing-mode PAY_PER_REQUEST
# Insert item
aws dynamodb put-item \n --table-name Users \n --item '{
"UserId": {"S": "user123"},
"Email": {"S": "user@example.com"},
"Name": {"S": "John Doe"}
}'Amazon ElastiCache
ElastiCache is a fully managed in-memory caching service supporting Redis and Memcached.
Redis vs Memcached:
Redis:
- Advanced data structures (sets, sorted sets, lists)
- Data persistence (snapshots, AOF)
- Multi-AZ replication with automatic failover
- Read Replicas for read scaling
- Backup and restore
- Pub/Sub, Geospatial data, Lua scripting
Memcached:
- Simple key-value architecture
- Multi-threaded (better for simple caching)
- No persistence
- No replication
- Automatic sharding
Usage Patterns:
- Cache-Aside: App reads from cache, if miss reads from DB and writes to cache
- Write-Through: App writes to cache and cache writes to DB
- Session Store: Store user sessions (Redis with persistence)
Redis vs Memcached:
Redis:
- Advanced data structures (sets, sorted sets, lists)
- Data persistence (snapshots, AOF)
- Multi-AZ replication with automatic failover
- Read Replicas for read scaling
- Backup and restore
- Pub/Sub, Geospatial data, Lua scripting
Memcached:
- Simple key-value architecture
- Multi-threaded (better for simple caching)
- No persistence
- No replication
- Automatic sharding
Usage Patterns:
- Cache-Aside: App reads from cache, if miss reads from DB and writes to cache
- Write-Through: App writes to cache and cache writes to DB
- Session Store: Store user sessions (Redis with persistence)
🎯 Key Points
- ✓ Redis for advanced features and high availability
- ✓ Memcached for simple caching and multi-core
- ✓ ElastiCache reduces latency and database load
- ✓ Lazy Loading vs Write Through strategies
- ✓ Redis Cluster mode for horizontal sharding