RDS & Elasticache Flashcards
rds encryption
- at rest
- can use AWS KMS - AES 256 encryption
- defined at launch time
- if master is not encrypted, read replicas cannot be encrypted
- transparent data encryption TDE availabe for oracle and sql server
- in flight encryption
- ssl cert
- provide ssl options with trust cert when connecting
- then manually enforce ssl on DB- rds.force_ssl = 1
- encryption operations
- encrypting backups - unencrypted db = unencrypted snapshots
- can copy a snapshot into an encrypted one
- to encrypt an un-encrypted RDS DB
- create snapshot, copy and enable encryption, restore from encrypted DB
- migrate apps from old db to new encrypted one
RDS auth
traditional username and password to login or can use IAM based auth for RDS mysql and postgresql
- RDS IAM auth
- just need an auth token obtained using IAM and RDS API calls
- 15 lifetime
RDS db engines
- postgres
- mysql
- oracle
- aurora
- microsoft sql server
- mariadb
why use RDS? it’s managed!
- auto provisioning and OS patching
- continuous backups and point in time restore
- automatic daily full backups during maintenance window
- transaction logs are backed up every 5 minutes
- restore to any point in time from oldest backup up to 5 mins ago
- 7 days to 35 days
- snapshots - backups that are manually triggered by user
- monitoring
RDS read replicas
- read scalability
- up to 5 read replicas
- within AZ, cross AZ, or cross Region
- replication is ASYNC so reads are eventually consistent
- can promote to its own DB
- network cost
- normally in AWS there’s a cost when data goes from one AZ to another. Exceptions are for managed services like RDS
- same region, different AZ - no fee for RDS
- cross region replica - costs $
- normally in AWS there’s a cost when data goes from one AZ to another. Exceptions are for managed services like RDS
- use case: reporting and analytics on top of existing DB
RDS multi-az
- (disaster recovery)
- sync replication
- one DNS name - automatic app failover
- can setup Read Replicas as multi-az if you wanted to.
- converting from single-az to multi-az
- zero downtown
- click modify for DB, create standby DB with sync replication
- I/O activity is no longer suspended on your primary during your preferred backup window, since backups are taken from the standby.
- ## multi-az standby cannot serve requests
can you ssh into RDS instances?
nah
RDS storage auto scaling
- helps increase storage dynamically
- set max storage threshold
- automatically modify storage if:
- free storage is less than 10% of allocated storage
- low storage lasts at least 5 minutes
- 6 hrs have passed since last modification
- useful for unpredictable workloads with support for all db engines
Amazon Aurora
- not open source
- compatible with Postgres and MySQL
- cloud optimized claims 5x performance improvement over mysql on rds and 3x performance of postgres on RDS
- up to 15 replicas (mysql has 5), faster replication process
- 20% more $ than RDS
Aurora availability and read scaling
- 6 copies across 3 AZs automatically
- 4 copies out of 6 needed for writes
- 3 copies out of 6 needed for reads
- self healing peer to peer replication
- storage is striped across 100s of volumes
- storage automatically grows in increments of 10GB, up to 128TB
- one master writer instance
- any read replica can become master
- 30 second automatic failover
- support for cross region replication
Aurora load balancing
- writer endpoint - points to master
- reader endpoint - connection load balancing
- load balancing happens at connection level not statement level
Elasticache
- managed Redis or Memcache
- in-mem dbs with really high performance
- helps reduce load off dbs for read intensive workloads
- helps make app stateless
- involves heavy application code changes
- cache must have invalidation strategy to make sure only the most current data is used
Redis vs Memcached
- redis
- multi az with auto failover
- read replicas to scale reads and high availability
- data durability, persistence, backup and restore features
- all nodes must reside in the same region
- Memcached
- multi-node for partitioning of data (sharding)
- no high availability (replication)
- non persistent, no backup and restore
- multi threaded
Lazy Loading / Cach-Aside / Lazy Population
(good for READ performance)
- try cache, on miss, request from db and then write to cache
- pros
- only requested data is cached
- node faulres not fatal (just increased latency)
- cons
- cache miss penalty (read penalty) = 3 network calls (noticeable delay)
- stale data - if data is updated in RDS, then it needs to be updated in the cache
Write through
(Write performance)
- write to cache when db is written to
- pros
- data in cache is never stale, reads are quick
- write penalty - each write requires 2 calls
- cons
- missing data until it is updated in the DB. mitigation is to combine lazy loading strategy as well.
- cache churn - a lot of the data will never be read (bad if cache is small)
- TTL is not a great idea with vanilla writethrough
