AWS Solutions Architect Exam  >  AWS Solutions Architect Notes  >  : Associate Level  >  Cheat Sheet: ElastiCache — Redis vs Memcached

Cheat Sheet: ElastiCache — Redis vs Memcached

1. ElastiCache Overview

1.1 Service Definition

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.1 Core Differences

2.2 Architecture Differences

2.2 Architecture Differences

2.3 Performance Characteristics

2.3 Performance Characteristics

3. Redis-Specific Features

3.1 Data Persistence

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.3 Redis Replication and Failover

3.4 Redis Data Structures Use Cases

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.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.1 Network Security

5.2 Encryption and Authentication

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.1 CloudWatch Metrics

6.2 Backup and Restore (Redis Only)

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

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

8.2 Right-Sizing

9. Limitations and Quotas

9.1 Service Limits

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.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.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
The document Cheat Sheet: ElastiCache — Redis vs Memcached is a part of the AWS Solutions Architect Course AWS Solutions Architect: Associate Level.
All you need of AWS Solutions Architect at this link: AWS Solutions Architect
Explore Courses for AWS Solutions Architect exam
Get EduRev Notes directly in your Google search
Related Searches
Cheat Sheet: ElastiCache — Redis vs Memcached, Important questions, Summary, study material, ppt, Free, Objective type Questions, Cheat Sheet: ElastiCache — Redis vs Memcached, Previous Year Questions with Solutions, Semester Notes, practice quizzes, video lectures, Exam, past year papers, shortcuts and tricks, Sample Paper, Cheat Sheet: ElastiCache — Redis vs Memcached, pdf , MCQs, mock tests for examination, Viva Questions, Extra Questions;