Cheat Sheet: ElastiCache — Redis vs Memcached

1. ElastiCache Overview

1.1 Service Definition

1.2 Key Benefits

• Sub-millisecond latency for read/write operations
• Automatic failure detection and recovery
• Scales horizontally (add read replicas) and vertically (change node type)
• Integration with CloudWatch for monitoring
• Supports encryption at rest and in transit

2. Redis vs Memcached Comparison

2.1 Core Differences

2.2 Architecture Differences

2.3 Performance Characteristics

3. Redis-Specific Features

3.1 Data Persistence

3.2 Redis Cluster Modes

3.2.1 Cluster Mode Disabled

• Single shard (node group) with 1 primary and up to 5 read replicas
• All data stored on single primary node
• Read replicas for read scaling and high availability
• Multi-AZ automatic failover available
• Suitable for smaller datasets that fit on single node

3.2.2 Cluster Mode Enabled

• Data partitioned across multiple shards (1-500 shards)
• Each shard has 1 primary and up to 5 read replicas
• Supports up to 500 nodes total
• Horizontal scaling by adding/removing shards
• Online resharding to change shard configuration
• 16,384 hash slots distributed across shards

3.3 Redis Replication and Failover

3.4 Redis Data Structures Use Cases

3.5 Redis Pub/Sub

• Publish messages to channels; multiple subscribers receive messages
• Real-time messaging and notifications
• Fire-and-forget model; messages not persisted
• Pattern-based subscriptions (wildcards supported)

3.6 Redis Transactions

• MULTI command starts transaction block
• EXEC command executes all queued commands atomically
• DISCARD command cancels transaction
• All commands execute sequentially without interruption
• No rollback mechanism; errors don't stop execution

4. Memcached-Specific Features

4.1 Architecture

• Multi-threaded: utilizes multiple CPU cores on single node
• Horizontal partitioning: client-side consistent hashing distributes keys
• No replication or persistence: simplest caching model
• Up to 20 nodes per cluster
• Auto Discovery: automatic node discovery for client configuration

4.2 Scaling

4.3 Auto Discovery

• Configuration endpoint provides list of all cache nodes
• Client libraries automatically discover and connect to nodes
• Handles node additions and removals automatically
• Reduces application code complexity for node management

5. Security Features

5.1 Network Security

5.2 Encryption and Authentication

5.3 Redis RBAC (Role-Based Access Control)

• Available in Redis 6.x and later
• Define users with specific permissions
• Control access to commands and keys
• User groups for managing multiple users
• Default user can be disabled for enhanced security

6. Monitoring and Maintenance

6.1 CloudWatch Metrics

6.2 Backup and Restore (Redis Only)

6.3 Maintenance Windows

• Specify weekly maintenance window for patches and updates
• Minimum 60-minute window required
• Multi-AZ: updates performed on replicas first, then primary
• Service updates applied automatically or deferred

7. Use Case Selection Guide

7.1 Choose Redis When:

• Advanced data structures needed (lists, sets, sorted sets, hashes)
• Persistence required (survive restarts)
• High availability and automatic failover required
• Read replicas needed for scaling reads
• Backup and restore functionality required
• Pub/Sub messaging needed
• Transactions or Lua scripting required
• Geospatial data queries needed
• Leaderboards or ranking systems (sorted sets)
• Complex data types beyond simple key-value
• Multi-AZ replication required
• Encryption at rest and in transit required

7.2 Choose Memcached When:

• Simple key-value caching needed
• Multi-threaded performance important (utilize multi-core CPUs)
• Horizontal scaling with partitioning preferred
• No persistence required (ephemeral cache)
• No replication or high availability needed
• Simplest caching model desired
• Large nodes with multiple cores (maximizes multi-threading)
• Object caching (e.g., database query results, session data)

7.3 Common Use Cases by Feature

8. Cost Optimization

8.1 Node Types and Pricing Factors

• Node type determines hourly cost (larger instances = higher cost)
• On-Demand vs Reserved Nodes (1-year or 3-year commitments for savings)
• Data transfer costs for cross-AZ replication (Redis Multi-AZ)
• Snapshot storage costs (Redis only)
• Reserved nodes: up to 55% savings compared to On-Demand

8.2 Right-Sizing

9. Limitations and Quotas

9.1 Service Limits

9.2 Configuration Constraints

• Redis Cluster mode cannot be enabled/disabled after creation
• Encryption at rest and in transit cannot be enabled after creation
• Node type changes require brief downtime for non-clustered Redis
• Memcached does not support snapshot operations
• Cannot change engine type (Redis to Memcached or vice versa)

10. Best Practices

10.1 Design Patterns

• Lazy Loading: Load data into cache on cache miss; reduces unnecessary caching
• Write-Through: Write to cache and database simultaneously; ensures consistency
• Adding TTL: Set expiration on keys to prevent stale data; balances freshness and cache hits
• Redis Cluster: Use for datasets >170 GB or when needing >5 read replicas
• Multi-AZ: Enable for production workloads requiring high availability

10.2 Performance Optimization

10.3 Availability and Durability

• Use Multi-AZ for automatic failover in production (Redis)
• Enable AOF persistence for maximum durability (Redis)
• Deploy read replicas across multiple AZs
• Test failover procedures during maintenance windows
• Use primary endpoint for writes; reader endpoint for read scaling
• For Memcached: design application to tolerate node failures

10.4 Security Hardening

• Enable encryption in transit for sensitive data (Redis)
• Enable encryption at rest using KMS (Redis)
• Use security groups to restrict access to known sources
• Disable default user and create specific users with RBAC (Redis 6.x)
• Rotate AUTH tokens regularly (Redis)
• Never expose cache nodes to public internet

11. Integration Patterns

11.1 Application Integration

11.2 Multi-Region Strategies

• Global Datastore (Redis): Replicate across regions for disaster recovery
• Cross-region snapshot copy: Manual backup to another region (Redis)
• Application-level replication: Write to multiple regional caches
• Read local, write global: Reads from local cache; writes propagate globally