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