Learning AWS Day by Day — Day 42 — Amazon ElastiCache

Saloni Singh - Apr 21 - - Dev Community

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.

**
Image description**
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)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player