Amazon ElastiCache: Redis and Memcached In-Memory Caching

You just spent $10,000 on a database cluster upgrade, but your API still responds in 200ms. The bottleneck isn't compute—it's the disk I/O every time you fetch the same user profile. Meanwhile, your competitor serves the same data in 5ms using a cache they set up in an afternoon. That's the difference ElastiCache makes.

Amazon ElastiCache is a managed in-memory caching service that sits between your application and database, storing frequently accessed data in RAM. It supports two engines: Redis (feature-rich, persistent, supports complex data structures) and Memcached (simpler, multithreaded, no persistence). The choice matters: Redis is for when you need durability, atomic operations, or pub/sub; Memcached is for pure caching with minimal overhead.

In production, ElastiCache can reduce database load by 80% or more, but misconfiguration—like ignoring eviction policies or failing to monitor cache hit ratios—can turn it into a costly paperweight. This guide covers what you need to know to deploy ElastiCache without the gotchas.

Why In-Memory Caching Matters in Production

In production, database latency is the silent killer of application performance. Every millisecond spent querying a relational database adds up, especially under load. In-memory caching reduces that latency by storing frequently accessed data in RAM, cutting read times from single-digit milliseconds to microseconds. Amazon ElastiCache offers two engines: Redis and Memcached. Redis is a feature-rich data structure server with persistence, replication, and atomic operations. Memcached is a simpler, multithreaded key-value store optimized for raw throughput. Choosing the wrong one leads to operational pain—like data loss during failover or wasted memory due to fragmentation. This article walks through production patterns, pitfalls, and code you can deploy today.

Redis vs Memcached: The Decision Matrix

Redis supports strings, hashes, lists, sets, sorted sets, bitmaps, and streams. It offers persistence (RDB snapshots, AOF logs), replication, and clustering. Memcached is a pure key-value store with a multithreaded architecture and slab-based memory allocation. Use Redis when you need data structures, atomic operations, pub/sub, or persistence. Use Memcached when you need simple caching with minimal overhead and can tolerate data loss. In production, Redis dominates because its feature set reduces complexity—you can replace a queue, session store, and rate limiter with one service. Memcached's advantage is raw throughput for large values, but its lack of replication means a node failure empties the cache entirely.

import redis
import bmemcached
import time

# Redis
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
start = time.time()
for i in range(10000):
    r.set(f'key:{i}', 'x' * 1000)
elapsed_redis = time.time() - start

# Memcached
mc = bmemcached.Client(['localhost:11211'])
start = time.time()
for i in range(10000):
    mc.set(f'key:{i}', 'x' * 1000)
elapsed_memcached = time.time() - start

print(f'Redis: {elapsed_redis:.3f}s')
print(f'Memcached: {elapsed_memcached:.3f}s')

Setting Up ElastiCache for Redis: Production Checklist

When provisioning ElastiCache for Redis, start with the right node type. Use memory-optimized (r6g) for caching, compute-optimized (c6g) for CPU-heavy workloads. Enable Multi-AZ with automatic failover for high availability. Set the reserved-memory parameter to leave headroom for Redis background saves. Use encryption in transit (TLS) and at rest. Enable automatic backups with a retention period of at least 7 days. For large datasets, enable cluster mode with shards. Each shard is a master-replica pair. Use redis-cli with --cluster commands to manage slots. Monitor Evictions, CacheHits, and CurrConnections in CloudWatch. Set alarms for Evictions > 0—that means your cache is too small.

#!/bin/bash
aws elasticache create-cache-cluster \
    --cache-cluster-id prod-redis \
    --cache-node-type cache.r6g.large \
    --engine redis \
    --engine-version 7.0 \
    --num-cache-nodes 2 \
    --az-mode cross-az \
    --automatic-failover-enabled \
    --snapshot-retention-limit 7 \
    --snapshot-window 05:00-06:00 \
    --transit-encryption-enabled \
    --at-rest-encryption-enabled \
    --tags Key=Environment,Value=production

Caching Strategies: Cache-Aside, Write-Through, and Write-Behind

Cache-aside (lazy loading) is the most common pattern: on a cache miss, the application loads data from the database and writes it to the cache. This is simple but can cause a thundering herd on a cold start. Write-through updates the cache synchronously when writing to the database, ensuring consistency but adding write latency. Write-behind (write-back) updates the cache immediately and asynchronously writes to the database, improving write throughput but risking data loss on cache failure. In production, cache-aside with a short TTL is the safest default. For read-heavy workloads, pre-warm the cache on deployment. For write-heavy, consider write-through with a distributed lock to prevent duplicate writes.

import redis
import psycopg2

r = redis.Redis(host='localhost', port=6379, decode_responses=True)
conn = psycopg2.connect('dbname=prod user=app')

def get_user(user_id):
    cache_key = f'user:{user_id}'
    user = r.get(cache_key)
    if user:
        return user
    # Cache miss - load from DB
    cur = conn.cursor()
    cur.execute('SELECT data FROM users WHERE id = %s', (user_id,))
    row = cur.fetchone()
    if row:
        user = row[0]
        r.setex(cache_key, 3600, user)  # TTL 1 hour
    return user

Handling Cache Invalidation and Stale Data

Cache invalidation is hard. The simplest approach is TTL-based expiration. Set TTLs based on how stale data can be—user profiles can be 1 hour, product inventory 5 minutes. For active invalidation, delete or update the cache entry when the underlying data changes. Use Redis pub/sub to broadcast invalidation events across services. Avoid caching data that changes frequently (e.g., stock prices). Use a version key to invalidate entire cache groups. For example, user:123:v2. When you update the schema, increment the version. This avoids stale data without scanning all keys. In production, prefer TTLs over explicit invalidation—it's simpler and less error-prone.

import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

def update_user(user_id, new_data):
    # Update database
    db.update_user(user_id, new_data)
    # Invalidate cache
    cache_key = f'user:{user_id}'
    r.delete(cache_key)
    # Publish invalidation event
    r.publish('cache:invalidate', cache_key)

# Subscriber
pubsub = r.pubsub()
pubsub.subscribe('cache:invalidate')
for message in pubsub.listen():
    if message['type'] == 'message':
        r.delete(message['data'])

Connection Management and Pooling

Opening a new Redis connection per request is expensive. Use connection pooling to reuse connections. In Python, redis-py's ConnectionPool manages this. Set max_connections to a reasonable limit (e.g., 50 per application instance). Monitor CurrConnections in CloudWatch. If it hits the max, requests queue up or fail. Use socket_timeout and socket_connect_timeout to avoid hanging connections. For high-throughput apps, use pipelining to batch commands. In Redis cluster mode, use a client that supports cluster-aware routing (e.g., redis-py-cluster). Avoid creating a new client per request—it's a common anti-pattern that exhausts file descriptors.

import redis

pool = redis.ConnectionPool(
    host='prod-redis.xxxxx.ng.0001.use1.cache.amazonaws.com',
    port=6379,
    max_connections=50,
    socket_timeout=5,
    socket_connect_timeout=2,
    decode_responses=True
)
r = redis.Redis(connection_pool=pool)

# Use r normally - connections are reused
r.set('key', 'value')
print(r.get('key'))

Monitoring and Alerting for ElastiCache

Monitor these CloudWatch metrics: CacheHits, CacheMisses, Evictions, CurrConnections, CPUUtilization, FreeableMemory, NetworkBytesIn/Out. Calculate hit rate: CacheHits / (CacheHits + CacheMisses). A hit rate below 80% indicates poor cache utilization. Set alarms on Evictions > 0—this means the cache is full and data is being evicted, which increases miss rate. Monitor CPUUtilization—Redis is single-threaded, so high CPU means you need a larger node or more shards. Use CurrConnections to detect connection leaks. Enable Redis slow log (SLOWLOG GET 100) to find expensive commands. For cluster mode, monitor per-shard metrics.

#!/bin/bash
# Get cache hit rate from CloudWatch
aws cloudwatch get-metric-statistics \
    --namespace AWS/ElastiCache \
    --metric-name CacheHits \
    --dimensions Name=CacheClusterId,Value=prod-redis \
    --start-time $(date -u -d '-5 minutes' +%Y-%m-%dT%H:%M:%SZ) \
    --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
    --period 300 \
    --statistics Sum

# Get slow log
redis-cli -h prod-redis.xxxxx.ng.0001.use1.cache.amazonaws.com SLOWLOG GET 10

Scaling ElastiCache: Vertical vs Horizontal

Vertical scaling (changing node type) is simple but requires downtime. Use the AWS console or CLI to modify the cache cluster. For Redis, you can scale vertically with minimal downtime if you have replicas—failover to a replica, scale the old master, then fail back. Horizontal scaling (adding shards) is for Redis cluster mode. Add shards gradually to avoid rebalancing storms. Use aws elasticache increase-replica-count for read scaling. For write scaling, add shards. Monitor KeyUsage per shard—if any shard has more than 10 million keys, consider splitting. Memcached scales horizontally by adding nodes to the cluster, but you must update your client's server list.

#!/bin/bash
# Scale vertically: modify node type
aws elasticache modify-cache-cluster \
    --cache-cluster-id prod-redis \
    --cache-node-type cache.r6g.xlarge \
    --apply-immediately

# Scale horizontally: add shard (cluster mode)
aws elasticache increase-replica-count \
    --replication-group-id prod-redis-cluster \
    --new-replica-count 2 \
    --apply-immediately

Backup and Restore Strategies

ElastiCache for Redis supports automatic snapshots (RDB) and manual backups. Enable automatic backups with a retention period of 1-35 days. Snapshots are stored in S3. For cross-region disaster recovery, copy snapshots to another region using AWS CLI. Restore a snapshot to a new cluster. For point-in-time recovery, use AOF (Append-Only File) if you need durability, but it impacts performance. In production, use RDB snapshots every 6 hours and AOF for critical data. Test restores regularly—snapshots can be corrupted. For Memcached, there is no persistence—treat it as a pure cache. Always have a plan to repopulate the cache from the database.

#!/bin/bash
# Create manual snapshot
aws elasticache create-snapshot \
    --cache-cluster-id prod-redis \
    --snapshot-name prod-redis-backup-$(date +%Y%m%d-%H%M)

# Copy snapshot to another region
aws elasticache copy-snapshot \
    --source-snapshot-name prod-redis-backup-20230101-1200 \
    --target-snapshot-name prod-redis-backup-dr \
    --target-bucket my-bucket \
    --region eu-west-1

# Restore snapshot to new cluster
aws elasticache create-cache-cluster \
    --cache-cluster-id prod-redis-restored \
    --snapshot-name prod-redis-backup-20230101-1200 \
    --cache-node-type cache.r6g.large \
    --engine redis

Security Best Practices for ElastiCache

ElastiCache runs in a VPC. Never expose it to the internet. Use security groups to restrict access to only application servers. Enable encryption in transit (TLS) and at rest. Use IAM authentication for Redis (Redis AUTH) with strong passwords stored in AWS Secrets Manager. Rotate passwords regularly. For Redis 6+, use ACLs to restrict user permissions. Disable the FLUSHALL and CONFIG commands for production users. Use VPC Flow Logs to monitor traffic. Enable CloudTrail for API calls. For compliance, enable audit logs (Redis 7.0+). Never use default ports—change them if possible.

#!/bin/bash
# Create security group with restricted access
aws ec2 create-security-group \
    --group-name redis-sg \
    --description "Security group for Redis"

aws ec2 authorize-security-group-ingress \
    --group-id sg-12345678 \
    --protocol tcp \
    --port 6379 \
    --source-group sg-application

# Enable encryption in transit (already done at creation)
# Set AUTH token
aws elasticache modify-cache-cluster \
    --cache-cluster-id prod-redis \
    --auth-token MySecretToken123! \
    --apply-immediately

Common Pitfalls and How to Avoid Them

Pitfall 1: Caching everything. Cache only data that is expensive to compute and read frequently. Pitfall 2: No TTLs. Without TTLs, stale data lives forever. Always set a TTL. Pitfall 3: Large values. Redis works best with values under 10KB. Large values increase memory fragmentation and network latency. Pitfall 4: Ignoring evictions. Evictions mean your cache is too small—scale up or reduce TTLs. Pitfall 5: Using KEYS in production. It blocks Redis for seconds. Use SCAN instead. Pitfall 6: Not handling cache failures gracefully. Your application should degrade gracefully when Redis is down—fall back to the database. Pitfall 7: Overusing transactions. Redis transactions (MULTI/EXEC) are optimistic and can cause retries. Use Lua scripts for atomicity.

import redis
import logging

r = redis.Redis(host='localhost', port=6379, decode_responses=True, socket_timeout=1)

def get_user_safe(user_id):
    try:
        user = r.get(f'user:{user_id}')
        if user:
            return user
    except redis.RedisError as e:
        logging.warning(f'Redis error: {e}')
    # Fallback to database
    return db.get_user(user_id)

Production Deployment Checklist

Before going live, verify: 1) Multi-AZ enabled with automatic failover. 2) Encryption in transit and at rest. 3) Automatic backups with 7-day retention. 4) Security group allows only application servers. 5) AUTH token set and rotated. 6) reserved-memory configured (25% of maxmemory). 7) Slow log threshold set to 10ms. 8) CloudWatch alarms for evictions, CPU, and connections. 9) Connection pooling in application code. 10) Graceful degradation on cache failure. 11) Cache-aside pattern with TTLs. 12) Pre-warming script for deployments. 13) Load testing with realistic traffic patterns. 14) Documentation of cache keys and TTLs. 15) Runbook for common failure scenarios (node failure, full cache, slow commands).