6.73 ELASTICACHE security strategy

To close this section, here is a recap of the ElastiCache security strategy. ElastiCache supports SSL encryption but does not support IAM authentication for the cache engine itself — a common trick question. IAM policies on ElastiCache only protect the AWS API; they cannot gate commands issued by an application talking to Redis or Memcached. Redis adds its own layer: AUTH authentication based on a password defined at cluster creation. Memcached supports SASL-based authentication, an advanced mechanism not covered in this course.

In practice you place ElastiCache behind a security group; applications connect with SSL in transit and, for Redis, authenticate using the user/password pair set at cluster creation. This layered model — security group, TLS, AUTH — gives you a defence-in-depth posture for the cache layer.

Caching strategies

  • Lazy loading: cache is filled on demand. The app reads from the cache; on a miss, it queries the database, writes the result to the cache and returns it. Risk: stale entries if the source changes and nothing invalidates the cache.
  • Write-through: every write to the database is also propagated to the cache, so the cache stays in sync with the source. No stale data, at the cost of write overhead.
  • Session store (TTL-based): session data is cached temporarily and purged when the TTL expires. Useful for distributing session state across multiple app instances.

As a famous quip in computer science puts it: there are only two hard things — cache invalidation and naming things. In this course we focus on lazy loading. Concretely: the user hits the app, the app queries ElastiCache. On a hit, the response comes from the cache and RDS is never touched. On a miss, the app queries RDS, writes the result back into ElastiCache, and the next user requesting the same data will be served directly from the cache. This pattern reduces load on RDS and improves latency, which closes section 6.

Summary

This lesson covers ElastiCache security strategy, including SSL/TLS encryption, Redis AUTH password-based authentication, and security groups for network access control. It explains how IAM policies function at the AWS control plane level only, while cluster-level authentication requires Redis AUTH or SASL. Three primary caching patterns are introduced: Lazy Loading (passive), Write-Through (synchronous), and Session Store, with Lazy Loading demonstrated as the main use case showing how cache misses trigger database queries and populate the cache.

Key points

  • ElastiCache supports SSL/TLS encryption in transit and Redis AUTH password authentication defined at cluster creation; SASL is available for advanced authentication scenarios
  • IAM policies control AWS management-level access (who can provision clusters) but do not provide cluster-level authentication; Redis AUTH must be used separately for application access
  • Security Groups regulate inbound network traffic to ElastiCache instances as an additional security layer
  • Lazy Loading (passive caching) writes data to cache only on database queries, risking stale data if the database is updated without cache invalidation
  • Write-Through caching synchronously updates the cache whenever the database is written, eliminating stale data at the cost of additional write operations
  • Session Store pattern uses ElastiCache with TTL expiration to store temporary session data that auto-purges when the session lifetime expires

FAQ

Why is Redis AUTH needed if IAM policies control access to ElastiCache?

IAM policies secure AWS account-level operations (cluster creation, deletion, modification). Redis AUTH provides separate cluster-level authentication for applications connecting to the cache. Both are required: IAM for infrastructure access, Redis AUTH for database access.

What is the main risk of Lazy Loading caching?

Lazy Loading risks serving stale data when the source database is updated but the corresponding cache entry is not refreshed. Data persists in cache until explicitly invalidated or the TTL expires, potentially causing inconsistency between cache and database.

When should you choose Write-Through over Lazy Loading?

Use Write-Through when data consistency is critical and database updates are frequent and predictable. Use Lazy Loading for read-heavy workloads where occasional stale data is acceptable, cache consistency is easier to manage, and you want to avoid unnecessary cache writes.