Amazon ElastiCache Cache Design - Choosing Among Valkey, Redis OSS, and Memcached with Caching Strategies
Explore the criteria for choosing among Valkey, Redis OSS, and Memcached, caching strategies like Lazy Loading and Write-Through, and how to leverage Serverless mode.
Selection Criteria for Valkey, Redis OSS, and Memcached
ElastiCache offers 3 engines, Valkey, Redis OSS, and Memcached, delivering microsecond latency and handling millions of requests per second. Valkey is an open-source compatible engine born as a fork of Redis, and it is offered as the default engine of ElastiCache. Valkey and Redis OSS operate on a single-threaded event loop model and provide rich data structures including Strings, Hashes, Lists, Sets, Sorted Sets, Streams, and HyperLogLog. They support data persistence through AOF (Append Only File) and RDB snapshots, read replicas, automatic failover, and Pub/Sub messaging, so they can serve not only as a cache but also as session stores, leaderboards, real-time rankings, and message brokers. Memcached features a multi-threaded architecture specialized for simple key-value caching, with easy horizontal scaling through node additions. It suits cases where data persistence and replication are unnecessary and you simply want to cache database query results. In engine selection, what matters is that Valkey uses the same command set and client libraries as Redis OSS while being priced lower than Redis OSS on all three counts: the hourly node rate, the Serverless ECPU rate, and the Serverless minimum billed storage. The practical split is therefore to start new builds with Valkey, to use Redis OSS when extending the life of an existing cluster or when you depend on a specific version, and to use Memcached for a simple cache layer that needs neither replication nor persistence.
| Aspect | Valkey (default engine) | Redis OSS | Memcached |
|---|---|---|---|
| Execution model | Single-threaded event loop | Single-threaded event loop | Multi-threaded |
| Data structures | Strings, hashes, lists, sets, Sorted Sets, Streams, HyperLogLog | Same as Valkey (Valkey is Redis OSS compatible) | Plain key-value only |
| Persistence and replication | AOF and RDB snapshots, read replicas, automatic failover | AOF and RDB snapshots, read replicas, automatic failover | Neither is available |
| How it scales | Sharding and read replicas | Sharding and read replicas | Easy horizontal scaling by adding nodes |
| Uses beyond caching | Session store, leaderboards, real-time rankings, a Pub/Sub message broker | Session store, leaderboards, real-time rankings, a Pub/Sub message broker | Essentially caching only |
| Serverless support | Supported. Minimum billed storage is 100 MB per cache | Supported. Minimum billed storage is 1 GB per cache | Supported. Minimum billed storage is 1 GB per cache |
| Cost level | Cheapest of the 3 engines (hourly node rate, ECPU rate, and Serverless storage rate alike) | Higher than Valkey | Hourly node rate on par with Redis OSS |
| Where it fits | The default for new builds. The cheapest way to start while staying Redis OSS compatible | When you want to keep using existing Redis OSS assets as they are | When you only want to cache database query results |
Designing Caching Strategies
Lazy Loading (Cache-Aside) is a strategy that fetches data from the database on a cache miss and writes it to the cache. Since only actually requested data is stored in the cache, memory efficiency is high, but cache misses occur on first access. Write-Through is a strategy that updates the cache simultaneously with database writes. Cache data is always kept up to date, but write latency increases and data that is never read also gets cached. In practice, combining both approaches is effective: use Write-Through to update the cache on writes while setting TTL to automatically expire stale data. TTL values should be determined based on data freshness requirements - short (seconds to minutes) for data requiring real-time accuracy, and long (hours to days) for master data. Continuously monitoring cache hit rates with CloudWatch metrics and periodically reviewing TTL and node sizing is key to effective operations.
| Aspect | Lazy loading (cache-aside) | Write-through |
|---|---|---|
| What triggers a cache write | A cache miss; you store the value while fetching it from the database | A database write; the cache is updated at the same moment |
| What ends up in the cache | Only the data that was actually requested | Everything that was written, including data nobody reads |
| Memory efficiency | High | Tends to be lower |
| Freshness | The cache can go stale | Always up to date |
| Weak point | The first access always misses | Write latency increases |
| Where practice lands | Combine the two: update on write with write-through, and let a TTL expire stale entries. Use seconds to minutes for data that must feel real time, and hours to days for master data | |
Cluster Mode and Sharding
Enabling cluster mode on Valkey or Redis OSS distributes data across 16,384 hash slots, allowing horizontal scaling across multiple shards. Each shard has a primary and up to 5 read replicas to distribute read load. The default cluster limit is set by the number of nodes rather than shards: up to 90 nodes per cluster, counting primaries and replicas together (up to 90 shards in a configuration without replicas). With Valkey 7.2 or later (Redis OSS 5.0.6 or later), a limit increase request can raise this to up to 500 nodes per cluster (official documentation value, as of August 2026). Clients send requests to the correct shard based on the hash slot mapping, and if a slot has moved, a MOVED redirect automatically connects to the new location. For node type selection, memory-optimized r-series instances (cache.r7g series) are well suited for cache workloads, and you adjust the number of shards and replicas according to data volume and throughput requirements. With Multi-AZ deployment and automatic failover enabled, a primary failure automatically promotes the replica with the smallest replication lag, and the official documentation states that writes can usually resume within a few seconds. However, because replication is asynchronous, writes can be lost to the extent that the promoted replica was slightly behind. Data you cannot afford to lose is assumed to be written to a durable store such as DynamoDB or RDS as well.
Migrating to Valkey and Global Datastore
Valkey lets you use existing Redis client libraries and command sets as they are, giving you a Redis-compatible environment without licensing concerns. A running Redis OSS cluster can move to Valkey through an engine upgrade operation, and the discount on reserved nodes you have already purchased carries over. Global Datastore replicates data asynchronously across regions, delivering disaster recovery (DR) and improved global read latency. When the primary region fails, you can promote a secondary region, and per the AWS official FAQ values (as of August 2026), RPO is typically under 1 second and RTO is also typically under 1 minute (after failover starts, it typically takes within 1 minute until the secondary can handle both reads and writes). Data sent out by cross-region replication incurs data transfer charges, so for clusters with heavy write volume these charges belong in the cost estimate.
ElastiCache Serverless and Operations
ElastiCache Serverless is a mode introduced in 2023 that removes the need to design node types or cluster sizes in advance. It supports all 3 engines, Valkey, Redis OSS, and Memcached, and you can create a cache simply by choosing an engine. Capacity scales automatically with the workload, starting from a minimal configuration and adapting to traffic increases. Pricing is pay-per-use based on the amount of data storage (GB-hours) and the usage of ElastiCache Processing Units (ECPU). The baseline for ECPU is 1 ECPU per 1 KB of data transferred in reads and writes, and with Valkey and Redis OSS, commands that use a lot of vCPU time are counted by whichever is larger, the data transferred or the vCPU time. There is also a minimum billed storage per cache: 100 MB for Valkey and 1 GB for Redis OSS and Memcached (official pricing page values, as of August 2026). You can set upper and lower limits on data storage and request rate, using the upper limit to contain unexpected costs and the lower limit to secure baseline performance. It is particularly well suited for new applications with unpredictable traffic patterns and for development and test environments. On the other hand, for production environments with stable traffic patterns, a provisioned configuration with reserved nodes is sometimes more cost-efficient.
ElastiCache Pricing
(As of August 2026, US East (N. Virginia) us-east-1 and Tokyo ap-northeast-1) ElastiCache charges on 4 axes: node-hour charges for node-based clusters, data storage and ECPU for Serverless, storage for backups (snapshots), and cross-region data transfer for Global Datastore. For node-hour charges, a Valkey cache.r7g.large costs 0.1752 USD per hour in N. Virginia and 0.2104 USD per hour in Tokyo. For the same node type, Redis OSS and Memcached cost 0.219 USD per hour in N. Virginia, so Valkey is priced roughly one fifth lower. Serverless data storage is billed in GB-hours (GB-Hours): Valkey costs 0.084 USD per GB-hour in N. Virginia and 0.101 USD per GB-hour in Tokyo, while Redis OSS and Memcached cost 0.125 USD per GB-hour in N. Virginia. ECPU is priced per 1 million ECPU: Valkey costs 0.0023 USD in N. Virginia and 0.0027 USD in Tokyo, while Redis OSS and Memcached cost 0.0034 USD in N. Virginia. Backups cost 0.085 USD per GB-month (GB-months) in both regions for storage beyond the free allocation. Data sent out by Global Datastore cross-region replication costs 0.02 USD/GB from N. Virginia and 0.09 USD/GB from Tokyo. There are 3 points on minimum charges and exceptions. Serverless has a minimum billed storage per cache (Valkey 100 MB / Redis OSS and Memcached 1 GB), which is charged even while idle. Nodes with the Valkey durability option (synchronous writes) enabled get a charge item separate from the node price, which for cache.r7g.large is 0.0315 USD per hour in N. Virginia and 0.0379 USD per hour in Tokyo. If you keep using an engine version whose standard support has ended, an extended support charge item is added, which for cache.r7g.large in N. Virginia is 0.175 USD per hour in year 1 and year 2 and 0.35 USD per hour in year 3. The free tier differs by sign-up date: if you signed up for the AWS Free Tier before July 15, 2025, 750 hours per month of cache.t3.micro node usage is free for up to 12 months (Serverless is not included), while sign-ups on or after that date choose between the Free Plan / Paid Plan and use credits. Serverless is cheaper for workloads with intermittent traffic, while provisioned nodes are more advantageous for workloads with consistently high throughput. In a provisioned configuration, reserved nodes can cut costs substantially: a 3-year all upfront Valkey cache.r7g.large costs 2,071.92 USD in N. Virginia and 2,488.19 USD in Tokyo. Divided over 3 years (26,280 hours), the hourly cost is about 45% of on-demand, which amounts to roughly a 55% discount in effect.
Summary
ElastiCache is a caching service that directly reduces database load and improves application response times. For new builds, start from Valkey, the default engine, and design your caching strategy with a combination of Lazy Loading and Write-Through. Cluster mode sharding and read replicas secure scalability, and Global Datastore can also cover global deployment and disaster recovery. A sound approach is to start easily with Serverless mode, then consider moving to a provisioned configuration with reserved nodes after your workload stabilizes.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon ElastiCache official page
- Amazon DynamoDB official page
- Amazon RDS official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.