• ElastiCache is managed Redis or Memcached
• Key-value store
• Caches are in-memory databases with really high performance, sub-millisecond latency
• Leads to faster reads & stateless applications
• Must provision an EC2 instance type e.g. cache.t2.micro & number of read replicas.
• Scaling
  • Write Scaling using sharding
• Availability
  • Multi AZ with Failover Capability
• An alternative is DynamoDb with DAX.
• Monitoring through CloudWatch
• Backup / snapshot / point in time restore features
• Caching patterns
  • Application queries ElastiCache, if not available, get from RDS and store in ElastiCache
    • Cache hit: Get data directly from ElastiCache
    • Cache miss: Data is not in the DB, application reads from DB and writes to the cache
  • Cache must have an invalidation strategy to make sure only the most current data is used in there.
    • Cache invalidation: whether or not the cache is out of date.
  • Patterns for ElastiCache
    • Lazy Loading: all the read data is cached, data can become stale in cache
    • Write Through: Adds or update data in the cache when written to a DB (no stale data)
    • Session Store: store temporary session data in a cache (using TTL features)
• ❗ None of the caches support IAM authentication
  • IAM policies are only used for AWS API-level security, such as create a cache, delete a cache etc.
• Managed and Scheduled maintenance with SNS notifications
  • Subnet group allows you to specify set of subnets in your VPC for your instances.
• 💡 Use case: Key/Value store, Frequent reads, less writes, cache results for DB queries (writethrough pattern), store session data for websites, cannot use SQL.

Memcached

• In-memory object store
• ❗ Cache doesn’t survive reboots
• Memcached support SASL authentication
• Use cases
  • Quick retrieval of objects from memory
  • Cache often accessed objects

Redis

• Most popular in-memory key-value store
• Super low latency (sub ms)
• Read Scaling using Read Replicas
  • Redis Clustering = Collection of one or more cache nodes
  • One of the nodes is a read/write primary node.
  • All other nodes in the shard are read-only replicas.
• Cache survive reboots by default (persistent)
• 💡 Use-cases: User sessions, Leaderboard (for gaming) with Redis Sorted Sets, Distributed states, Relieve pressure on databases (such as RDS), messages with Redis Pub/Sub, recommendation data with Redis Hashes
• Availability: Multi-AZ with Auto-Failover and enhanced robustness
• Cluster mode -> more persistence and robustness with specified number of read replicas.
  • Sharding through clustering
• Security
  • Network: Deploy into subnet, set preferred availability zone(s), security group
  • Encryption at rest (KMS) and in-transit (using SSL)
  • Redis support Redis AUTH (username / password with --auth-token parameter)
• Import data to cluster through seeding RDB file from S3
• Automatic back-up
• Persistence by snapshotting your Redis data using the Backup and Restore feature

Redis vs Memcached

	Memcached	Redis
Persistence	Not supported	Supported through snapshots
Authentication	SASL	Redis Auth
Sub-millisecond latency	Yes	Yes
Clustering	Each node => Different partition	1 master and read replicas of it
Unique features	Multi-threading	Snapshots, replication, transactions, pub/sub, lua scripting, geospatial support

---

---