This chapter covers Amazon ElastiCache, a fully managed in-memory caching service that accelerates application performance by offloading read-heavy workloads from databases. For the CLF-C02 exam, this falls under Domain 3: Cloud Technology Services, Objective 3.3 which carries about 8-10% of the exam weight. Understanding ElastiCache is crucial because it's a common solution for improving latency and throughput in web applications, and the exam tests your ability to recognize when to use caching versus other database services.
Jump to a section
Imagine a large public library where patrons can check out books. The main library stacks (your primary database) hold every book, but finding and retrieving a book takes time—a librarian must walk to the stacks, locate the book, and bring it back. To speed things up for popular titles, the library sets up an "Express Shelf" near the front desk. This shelf stores copies of the most frequently requested books. When a patron asks for a popular title, the librarian can grab it from the Express Shelf in seconds instead of minutes. However, the Express Shelf has limited space, so only the most popular books are kept there. If a book on the shelf isn't borrowed for a while, it's returned to the main stacks to make room for a more popular book. Also, if a new edition of a book is published, the library updates both the main stacks and the Express Shelf copy. This is exactly how Amazon ElastiCache works: it stores frequently accessed data in a fast, in-memory cache (the Express Shelf) so applications can retrieve it much faster than reading from the primary database (the main stacks). The cache automatically evicts less-used data and keeps itself synchronized with the database as needed, just like the library manages its Express Shelf.
What is Amazon ElastiCache and What Problem Does It Solve?
Amazon ElastiCache is a fully managed, in-memory caching service provided by AWS. It is designed to improve the performance of web applications by allowing you to retrieve data from a fast, managed, in-memory cache instead of relying entirely on slower disk-based databases. The primary problem ElastiCache solves is high latency and database overload caused by repetitive read requests for the same data. For example, an e-commerce site might display product details thousands of times per second; without a cache, each request would query the database, causing increased response times and potential database throttling. ElastiCache reduces this load by storing frequently accessed data in memory, enabling microsecond response times.
How It Works: The Mechanism
ElastiCache works by deploying a cluster of one or more nodes, each running either the Redis or Memcached engine. The cluster is placed in a Virtual Private Cloud (VPC) and is accessible to application servers (e.g., EC2 instances or Lambda functions) via a DNS endpoint. When an application needs data, it first checks the cache by querying the ElastiCache endpoint. If the requested key exists (a cache hit), the data is returned immediately from memory. If not (a cache miss), the application retrieves the data from the primary database, stores a copy in the cache with an optional Time-to-Live (TTL), and then returns the data. The TTL ensures that stale data is eventually evicted. ElastiCache supports multiple eviction policies, such as Least Recently Used (LRU) for Memcached and various policies for Redis (e.g., allkeys-lru, volatile-lru). The service handles node provisioning, patching, failure detection, and recovery automatically. For high availability, Redis supports replication with a primary node and up to five replica nodes, plus automatic failover. Memcached supports multi-node sharding but no replication.
Key Tiers, Configurations, and Pricing Models
ElastiCache offers two engine choices: Redis (recommended for most use cases due to its rich feature set) and Memcached (simpler, multi-threaded, but without persistence or replication). Nodes are available in different instance families: general purpose (e.g., cache.m6g.large), memory optimized (e.g., cache.r6g.large), and burstable (e.g., cache.t3.medium). Pricing is based on node hours, data transfer, and snapshot storage (Redis only). You can choose On-Demand or Reserved instances to save costs. Key configurations include: - Cluster Mode: For Redis, you can enable cluster mode to shard data across multiple nodes, supporting up to 500 shards and 90 nodes per cluster. - Replication: Redis allows Multi-AZ replication with automatic failover for high availability. - Snapshots: Redis supports automatic and manual snapshots for backup and restore. - Security: ElastiCache supports encryption at rest (using KMS) and in transit (TLS), IAM authentication for Redis, and VPC security groups. - Global Datastore: For Redis, you can create a cross-Region replication group for disaster recovery.
Comparison to On-Premises or Competing Approaches
Traditionally, organizations would deploy their own caching servers (e.g., running Redis on EC2 or on-premises servers). This required manual setup, patching, monitoring, and scaling. ElastiCache eliminates these operational burdens by automating node provisioning, software updates, failure detection, and scaling. Compared to using a CDN (like CloudFront) for caching, ElastiCache caches application-level data (e.g., session state, API responses) rather than static web content. Compared to Amazon DynamoDB Accelerator (DAX), which is a fully managed cache for DynamoDB, ElastiCache is more general-purpose and supports both Redis and Memcached protocols. Compared to using Amazon RDS with read replicas, ElastiCache provides lower latency (microseconds vs milliseconds) but is not a persistent data store—data is lost on node failure unless Redis persistence or replication is configured.
When to Use ElastiCache vs Alternatives
Use ElastiCache when:
Your application has read-heavy workloads with repetitive queries (e.g., product catalog, user sessions).
You need sub-millisecond response times.
You want to offload read traffic from your primary database to reduce costs and improve performance.
You need a distributed caching layer that can scale horizontally.
You require advanced data structures (Redis) like sorted sets, geospatial indexes, or pub/sub messaging.
Do NOT use ElastiCache when:
Your data changes very frequently and you need strong consistency (caches are eventually consistent).
You need to store data that must survive a node failure without replication or persistence (use a database instead).
Your application requires complex SQL queries (use RDS or Aurora).
You only need to cache static web content (use CloudFront).
Create an ElastiCache Cluster
Log into the AWS Management Console, navigate to ElastiCache, and choose 'Create' for either Redis or Memcached. You'll select a cluster name, node type (e.g., cache.m6g.large), number of replicas (if Redis), and VPC settings. AWS then provisions the nodes, configures the cluster endpoint, and applies any security groups. Default limits: up to 500 nodes per cluster (Redis with cluster mode), 20 clusters per region (soft limit).
Configure Security and Network
Within the VPC, create a security group that allows inbound traffic on port 6379 (Redis) or 11211 (Memcached) from your application servers (e.g., EC2 security group). ElastiCache nodes must be in the same VPC as your application. For Redis, you can enable encryption in transit and at rest, and use IAM authentication for access control. Behind the scenes, AWS manages network ACLs and routing.
Connect Application to Cache
Your application code uses a Redis or Memcached client library (e.g., redis-py for Python, Jedis for Java) to connect to the cluster endpoint. The endpoint is a DNS name that resolves to the primary node for writes and replicas for reads (if configured). Implement logic to check cache first, fall back to database on miss, and set cache with TTL. For example, in Python: ```python import redis r = redis.Redis(host='mycluster.xxxxxx.ng.0001.use1.cache.amazonaws.com', port=6379) value = r.get('key') if value is None: value = db.query("SELECT ...") r.setex('key', 3600, value) ```
Monitor and Scale
Use Amazon CloudWatch metrics like CacheHits, CacheMisses, CPUUtilization, and Evictions to monitor performance. If cache miss rate increases, you may need to scale up (larger node type) or scale out (add shards in cluster mode). ElastiCache supports online scaling for Redis cluster mode (adding shards without downtime) and vertical scaling for both engines (requires downtime). Set CloudWatch alarms to trigger scaling actions or notifications.
Implement Backup and Restore (Redis)
For Redis, you can enable automatic snapshots (daily) with retention up to 35 days. Manual snapshots can be taken anytime and stored in S3. To restore, create a new cluster from the snapshot. Note that snapshots only backup data in memory, not the entire OS. For disaster recovery, use Global Datastore to replicate across regions. Memcached does not support persistence or snapshots.
E-Commerce Product Catalog: An online retailer uses ElastiCache (Redis) to cache product details, pricing, and inventory status. The application receives millions of page views per day. By caching product data with a TTL of 5 minutes, they reduce database load by 80% and cut page load times from 200ms to under 10ms. They use a Redis cluster with three shards and one replica per shard for high availability. A misconfiguration (no TTL) led to stale inventory causing overselling, so they learned to set appropriate TTLs. Cost: ~$500/month for a cache.r6g.large cluster with 3 shards.
Gaming Leaderboard: A gaming company uses ElastiCache (Redis) to store real-time leaderboards using sorted sets. Players' scores are updated frequently, and the top 100 leaderboard is read thousands of times per second. Redis's sorted set operations (ZADD, ZRANGE) provide O(log N) performance. They use a single Redis node with replication for failover. Initially, they used Memcached but switched to Redis because of the need for sorted sets. Misunderstanding: they thought Memcached could handle sorted sets, but it only supports simple key-value pairs. Cost: ~$200/month for a cache.m6g.large node with one replica.
Session Store: A SaaS platform uses ElastiCache (Redis) to store user sessions across multiple web servers. This ensures that if a user's request goes to any server, the session data is available. They use Redis with persistence enabled (AOF) to avoid losing sessions on node failure. A common mistake is not enabling encryption in transit, exposing session tokens to potential interception. They now enforce TLS and IAM authentication. Cost: ~$100/month for a cache.t3.medium node.
The CLF-C02 exam tests your understanding of Amazon ElastiCache under Domain 3: Cloud Technology Services, specifically objective 3.3 which covers "Identify the appropriate AWS service for a given use case." You will likely see scenario-based questions where you must choose between ElastiCache, DynamoDB DAX, CloudFront, or RDS Read Replicas. The most common wrong answers are:
Choosing CloudFront for caching application data: Candidates often pick CloudFront because they know it's a caching service. However, CloudFront caches static and dynamic web content at the edge, not application-level data like database query results. The exam expects you to know that ElastiCache is for in-memory caching of application data.
Choosing DynamoDB DAX when the database is RDS: DAX only works with DynamoDB. If the scenario mentions an RDS database, ElastiCache is the correct caching service. Candidates confuse DAX as a generic cache.
Choosing Memcached when the use case requires persistence or advanced data structures: Memcached is simpler and does not support persistence, replication, or data structures like sorted sets. If the scenario mentions session persistence or leaderboards, Redis is the correct choice.
Thinking ElastiCache can replace a database: ElastiCache is a cache, not a primary data store. If the scenario requires durable storage, choose a database (RDS, DynamoDB).
Key terms to remember: Redis supports persistence, replication, Multi-AZ, snapshots, and data structures; Memcached is multi-threaded but simpler; TTL (Time-to-Live) is used to expire cache entries; Eviction policies (LRU, etc.); Cache hit vs cache miss; Cluster mode for horizontal scaling.
Decision rule: If the question asks about improving database read performance with sub-millisecond latency, and the data is not static web content, choose ElastiCache. If the database is DynamoDB, consider DAX first. If the content is static (images, CSS), choose CloudFront.
Amazon ElastiCache is a fully managed in-memory caching service supporting Redis and Memcached engines.
ElastiCache improves application performance by reducing latency and database load for read-heavy workloads.
Redis supports persistence, replication, Multi-AZ, snapshots, and advanced data structures; Memcached does not.
ElastiCache must be deployed within a VPC; it is not publicly accessible.
Cache hit vs cache miss: a cache hit returns data from cache; a cache miss requires fetching from the database.
Use TTL (Time-to-Live) to expire stale data; default eviction policy is LRU for Memcached and allkeys-lru for Redis.
ElastiCache is not a database; it is a complementary caching layer that should not be used as the primary data store.
For the CLF-C02 exam, distinguish between ElastiCache (application caching), CloudFront (CDN), and DAX (DynamoDB cache).
Scaling ElastiCache requires manual intervention or custom auto-scaling; there is no automatic scaling.
Pricing is based on node hours; reserved instances offer discounts for 1-3 year commitments.
These come up on the exam all the time. Here's how to tell them apart.
Amazon ElastiCache (Redis)
General-purpose in-memory cache for any database.
Supports Redis data structures (sorted sets, lists, etc.).
Requires manual cache invalidation or TTL.
Can be used with RDS, DynamoDB, or other data stores.
Pricing based on node hours and data transfer.
Amazon DynamoDB Accelerator (DAX)
Fully managed cache specifically for DynamoDB.
Only supports simple key-value operations.
Automatic cache invalidation when DynamoDB data changes.
Only works with DynamoDB as the backend.
Pricing based on node hours (no data transfer costs within same region).
Amazon ElastiCache (Memcached)
Multi-threaded, simple key-value store.
No persistence, replication, or snapshots.
Supports auto-discovery of nodes.
Best for simple caching with large objects.
No support for advanced data structures.
Amazon ElastiCache (Redis)
Single-threaded but rich feature set.
Supports persistence, replication, snapshots, and Multi-AZ.
Supports advanced data structures (sorted sets, hyperloglogs).
Best for complex caching needs like leaderboards, sessions.
Supports transactions and pub/sub messaging.
Mistake
ElastiCache is a database that can replace Amazon RDS.
Correct
ElastiCache is an in-memory cache, not a persistent database. Data is stored in memory and can be lost on node failure unless Redis persistence or replication is configured. It is used to offload read traffic from a database, not to replace it.
Mistake
Memcached supports data persistence and replication.
Correct
Memcached is a purely in-memory key-value store without persistence, replication, or snapshots. If you need data durability or high availability, use Redis.
Mistake
ElastiCache can be accessed from the internet without a VPC.
Correct
ElastiCache clusters are deployed within a VPC and cannot have public IP addresses. Access is only possible from within the same VPC or via VPN/Direct Connect. To access from the internet, you must use a proxy or a bastion host.
Mistake
All ElastiCache nodes are Multi-AZ by default.
Correct
Multi-AZ replication is only available for Redis, and even then, you must explicitly enable it. Memcached does not support Multi-AZ. For Redis, you can configure a replication group with replicas in different Availability Zones.
Mistake
ElastiCache automatically scales based on traffic.
Correct
ElastiCache does not auto-scale. You must manually modify the cluster to add or remove nodes, or use AWS Auto Scaling with custom metrics (e.g., based on CPU or memory usage). Scaling may require downtime for non-cluster-mode Redis.
ElastiCache is an in-memory cache for application data (e.g., database query results, session state) and is accessed from within your application code. CloudFront is a Content Delivery Network (CDN) that caches static and dynamic web content at edge locations around the world, reducing latency for end users. Use ElastiCache to speed up your backend; use CloudFront to speed up content delivery to users.
No, ElastiCache is not designed to be a primary database. It is a cache that stores data temporarily in memory. If the node fails, data can be lost unless Redis persistence (RDB/AOF) or replication is configured. Even with persistence, it is not as durable as a database like RDS or DynamoDB. Always use a proper database for your primary data store.
Ensure both the EC2 instance and the ElastiCache cluster are in the same VPC. Configure the security group for the ElastiCache cluster to allow inbound traffic on the appropriate port (6379 for Redis, 11211 for Memcached) from the EC2 instance's security group. Then, use the cluster endpoint (DNS name) in your application code to connect.
For Memcached, the default eviction policy is LRU (Least Recently Used). For Redis, the default depends on the configuration; if you enable cluster mode, the default is allkeys-lru (evict any key using LRU). You can change the policy using the 'maxmemory-policy' parameter. Common policies include volatile-lru (evict keys with TTL set) and noeviction (return errors when memory is full).
Yes, ElastiCache for Redis supports encryption at rest (using AWS KMS) and encryption in transit (TLS). Memcached does not support encryption. For Redis, you can also enable IAM authentication to control access. Encryption at rest is enabled at the cluster level and encrypts data on disk (if persistence is used) and backups. Encryption in transit requires clients to use TLS.
For Redis, you can enable automatic snapshots (daily backups) with configurable retention (1-35 days). You can also take manual snapshots at any time. Snapshots are stored in Amazon S3 and can be used to restore a new cluster. Memcached does not support snapshots. To backup Memcached, you must rely on application-level caching strategies or use Redis instead.
For Redis (cluster mode enabled), you can have up to 500 nodes (across all shards) per cluster. For Redis (cluster mode disabled), the limit is 1 primary and up to 5 replicas (total 6 nodes). For Memcached, you can have up to 20 nodes per cluster (soft limit, can be increased). These limits are per region and can be raised via a support ticket.
You've just covered Amazon ElastiCache — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?