RDS, Aurora & ElastiCache
RDS
Aurora
Security
Engines
PostgreSQL
MySQL
MariaDB
Oracle
MicrosoftSQL Server
Aurora - Proprietary
Engines
PostgreSQL
MySQL
HA and Scaling
Features
Security
6 copies of your data across 3 AZ
One Aurora Instance takes writes (master)
Automated failover for master in less than
30 seconds
Master + up to 15 Aurora Read Replicas
serve reads
Support for Cross Region Replication
encryption at Rest using KMS
backups, snapshots and replicas are also encrypted
Encryption in flight using SSL
You are responsible for protecting the instance with security groups
Possibility to authenticate using IAM token
You cannot SSH
Custom Endpoints
Subset of Aurora instances as Custom Endpoint
Aurora Serverless
Automated db instantiation and auto scaling
Elasticache
Global Aurora
Cross Region Read Replicas
Aurora Global Database
Security
Patterns
Lazy Loading: all read data is cached, data can become stale
Write Through: adds or updates data in cache when written to a DB
Session Store: store temporary session data in cache (using TTL)
Advantages vs EC2 DB
Automated provisioning, OS patching
Backups
Scaling
Storage
Read
Multi Master
Automatic fail-over
Backup and Recovery
Push-button scaling
Isolation and security
Automated Patching with Zero Downtime
Advanced Monitoring
Routine Maintenance
Backtrack: restore data without using backups
Continuous backups and restore to specific timestamp (Point in Time Restore)!
Monitoring dashboards
Read replicas for improved read performance
Multi AZ setup for DR (Disaster Recovery)
Maintenance windows for upgrades
Scaling capability (vertical and horizontal)
Storage backed by EBS (gp2 or io1)
Enabled by RDS
Automated backups
Daily full backup
TX logs backup up by RDS every 5 minutes
Can restore to any point in time
7 to 35 days retention
DB snapshots (triggered by user)
Disaster Recovery Multi AZ
When running out of free DB storage, auto scales
Must set Maximum Storage Threshold
Useful for apps with unpredictable workloads
Supports all RDS DB engines
Up to 5 Read Replicas
Within AZ, Cross AZ and Cross Region
Replication is ASYNC, reads are eventually consistent
Replicas can be promoted to own DB
Apps must update connection string to use read replicas
Network cost is 0 for Read Replicas in same region
SYNC replication
One DNS name - auto app failover to standby
Increases availability
Failover in case of AZ loss, network loss, instance or storage failure
Not used for scaling
Multi AZ is free
Read Replicas can be set as Multi AZ for DR
Encryption
At rest
In-flight
Can encrypt master and read replicas with AWS KMS
Encryption can be defined at launch time
If master not encrypted replicas cannot be encrypted
TDE for Oracle and SQL server
SSL cert to encrypt data to RDS in flight
Provide SSL opts with trust certificate when connecting to DB
Network Security
Access Management
RDS db usually in private subnet
RDS works by leveraging security groups
IAM policies controls who can manage AWS RDS
Traditional username and pass can be used for login
IAM based authN can be used for RDS MySQL and PostgreSQL
Run analytical queries on specific replicas
Reader Endpoint generally is not used after defining Custom Endpoints
Good for infreq, intermittent or unpredictable workloads
No capacity planning needed
Pay per second
Aurora multi master: immediate failover
Useful for disaster recovery
Simple to put in place
1 primary region
Up to 5 secondary readonly regions
Up to 16 Read replicas per secondary region
Promoting to other region, RTO < 1 minute
Overview
Managed Redis or Memcached
Makes app stateless
AWS takes care of: maintenance / patching, optimizations, setup, config, monitoring, failure recovery and backups
⚠ Elasticache involves heavy app code chages
❌ No IAM Auth
IAM policies only used for AWS API level security
Redis Auth: pass/token besides security groups
Redis Auth: Supports SSL flight encryption
Memcached: supports SASL auth