Learning AWS Day by Day — Day 42 — Amazon ElastiCache

Exploring AWS !!

Day 42:

Amazon ElastiCache

Overview:

• same way as RDS is used to get managed Relational Database, ElastiCache is to get managed Redis or Memcached.
• Cache are in-memory database with really high performance low latency.
• Helps reduce load off of database for read intensive workloads.
• helps make your application stateless.
• AWS takes care of OS maintenance/patching, optimization. setup, configuration, monitoring, failure recovery and backups.
• Using ElastiCache involves heavy application code changes.

ElastiCache Solution Architecture — Database Cluster:

• Application queries ElastiCache, if not available get from RDS and store in ElastiCache.
• Helps relieve load in RDS.
• Cache must’ve an invalidation strategy to make sure only most current data is used there.

ElastiCache Solution Architecture — User Session Store:

• User logs into any of the application.
• The application writes session data into ElastiCache
• The user hits another instance of our application.
• The instance retrieves the data and user already logged in

Redis v/s Memcached:
Redis:
Multi-AZ with auto failover
Read replicas to scale reads and have high availability.
Data durability using AOF persistence.
Backup and restore.
Memcached:
Multi node for partitioning of data (sharding)
No high availability
Non persistent
No backups and restore
Multi-threaded architecture

ElastiCache for Solutions Architect — Cache Security
All caches in ElastiCache:

• Does not support IAM Authentication
• IAM Policies on ElastiCache are only used for AWS API level security Redis AUTH:
• You can set password/token where you created Redis cluster
• This is extra level section for cache Memcached:
• Supports SAS2-based authentication (advanced)

Patterns for ElastiCache:

• Lazy loading: all read data is cached, data can become stale in cache
• Write Through: add or update data in cache when written to database (no stale data)
• Session store: store temporary session data in cache (using TTL feature)
• Quote: there are only 2 hard things in computer science. Cache invalidation and naming things.

Redis Use Case:
Gaming leaderboards are computationally complex.
Redis sorted guarantee both uniqueness and element ordering.
Each time a new element is added, it is ranked in real time, then added in correct order.

**
**
FTP: 21
SSH: 22
SFTP: 22
HTTP: 80
HTTPS: 443

PostgreSQL: 5432
MySQL: 3306
Oracle RDS: 1521
MSSQL Server: 1433
MariaDB: 3306
Aurora: (5432 if PostgreSQL compatible, 3306 if MySQL compatible)