Busca en todas las páginas de la documentación
ElastiCache runs three engines: Redis OSS, Valkey, and Memcached. Redis and Valkey are effectively the same feature set - Valkey is a drop-in, lower-cost fork of Redis OSS - so the real decision is Redis/Valkey versus Memcached.
The short version: Redis/Valkey give you data structures, replication, automatic failover, and backups; Memcached gives you a simpler, multi-threaded key-value store and nothing else. This page makes the trade-off concrete and shows the different SDK call each engine needs.
Quick-reference recipe card - copy-paste ready.
# --- Python (boto3) ---
import boto3
ec = boto3.client("elasticache", region_name="us-east-1")
# Redis/Valkey: replication group -> structures, replicas, failover, backups.
ec.create_replication_group(
ReplicationGroupId="app-cache", ReplicationGroupDescription="Redis cache",
Engine="valkey", CacheNodeType="cache.t4g.micro", NumCacheClusters=2,
AutomaticFailoverEnabled=True,
)
# Memcached: cache cluster -> simple multi-threaded KV, no replication.
ec.create_cache_cluster(
CacheClusterId="kv-cache", Engine="memcached",
CacheNodeType="cache.t4g.micro", NumCacheNodes=3,
)// --- TypeScript (AWS SDK v3) ---
import {
ElastiCacheClient, CreateReplicationGroupCommand, CreateCacheClusterCommand,
} from "@aws-sdk/client-elasticache";
const ec = new ElastiCacheClient({ region: "us-east-1" });
// Redis/Valkey: replication group -> structures, replicas, failover, backups.
await ec.send(new CreateReplicationGroupCommand({
ReplicationGroupId: "app-cache", ReplicationGroupDescription: "Redis cache",
Engine: "valkey", CacheNodeType: "cache.t4g.micro", NumCacheClusters: 2,
AutomaticFailoverEnabled: true,
}));
// Memcached: cache cluster -> simple multi-threaded KV, no replication.
await ec.send(new CreateCacheClusterCommand({
CacheClusterId: "kv-cache", Engine: "memcached",
CacheNodeType: "cache.t4g.micro", NumCacheNodes: 3,
}));When to reach for this:
Provision a Memcached cluster and discover its per-node endpoints, then contrast with the Redis replication group's primary/reader endpoints. Memcached exposes each node individually plus a configuration endpoint used by auto discovery - there is no single primary, because there is no replication.
# --- Python (boto3) ---
import boto3
ec = boto3.client("elasticache", region_name="us-east-1")
# 1. Create a 3-node Memcached cluster (nodes are independent, sharded by the client).
ec.create_cache_cluster(
CacheClusterId="kv-cache", Engine="memcached", EngineVersion="1.6.22",
CacheNodeType="cache.t4g.micro", NumCacheNodes=3,
CacheSubnetGroupName="app-cache-subnets", SecurityGroupIds=["sg-0123456789abcdef0"],
)
ec.get_waiter("cache_cluster_available").wait(CacheClusterId="kv-cache")
# 2. Discover every node's endpoint plus the configuration endpoint for auto discovery.
c = ec.describe_cache_clusters(CacheClusterId="kv-cache", ShowCacheNodeInfo=True)["CacheClusters"][0]
print("config endpoint:", c["ConfigurationEndpoint"]["Address"])
for node in c["CacheNodes"]:
print("node:", node["Endpoint"]["Address"], node["Endpoint"]["Port"])// --- TypeScript (AWS SDK v3) ---
import {
ElastiCacheClient, CreateCacheClusterCommand,
waitUntilCacheClusterAvailable, DescribeCacheClustersCommand,
} from "@aws-sdk/client-elasticache";
const ec = new ElastiCacheClient({ region: "us-east-1" });
// 1. Create a 3-node Memcached cluster (nodes are independent, sharded by the client).
await ec.send(new CreateCacheClusterCommand({
CacheClusterId: "kv-cache", Engine: "memcached", EngineVersion: "1.6.22",
CacheNodeType: "cache.t4g.micro", NumCacheNodes: 3,
CacheSubnetGroupName: "app-cache-subnets", SecurityGroupIds: ["sg-0123456789abcdef0"],
}));
await waitUntilCacheClusterAvailable({ client: ec, maxWaitTime: 900 }, { CacheClusterId: "kv-cache" });
// 2. Discover every node's endpoint plus the configuration endpoint for auto discovery.
const out = await ec.send(new DescribeCacheClustersCommand({
CacheClusterId: "kv-cache", ShowCacheNodeInfo: true,
}));
const c = out.CacheClusters![0];
console.log("config endpoint:", c.ConfigurationEndpoint!.Address);
for (const node of c.CacheNodes ?? []) {
console.log("node:", node.Endpoint!.Address, node.Endpoint!.Port);
}What this demonstrates:
CreateCacheCluster with NumCacheNodes - there is no primary/replica concept.DescribeReplicationGroups returns primary and reader endpoints because replicas exist.Redis and Valkey are far more than a key-value store. They provide data structures - strings, hashes, lists, sets, sorted sets, bitmaps, and streams - so you can model a leaderboard as a sorted set, a rate limiter as a counter with expiry, or a job queue as a list, all server-side and atomic. They support replication (one primary, up to five read replicas), automatic failover (a replica is promoted when the primary dies), backups (snapshots to S3), pub/sub, Lua scripting, and transactions (MULTI/EXEC). On AWS they are single-threaded per node for command execution, so per-node throughput scales by adding shards, not cores.
Valkey is a fork of Redis OSS created after Redis changed its license, and AWS offers it as a drop-in engine at lower cost (lower per-hour pricing and a smaller serverless minimum). For new caches it is the sensible default; existing Redis code and clients work unchanged.
Memcached is deliberately minimal: it stores opaque key-value blobs with a TTL and nothing else. Its one structural advantage is being multi-threaded, so a single large node can use many vCPUs for raw key-value throughput - useful for very high-volume, simple caching on big instances. What it lacks is everything else: no data structures, no replication, no failover, no persistence, and no backups. Scaling is horizontal - add nodes and let the client shard keys across them via consistent hashing - and a lost node simply loses its slice of the data until it refills from the backing store.
Choose Memcached only when all three hold: you need a pure key-value cache with no structures, you want multi-threaded throughput on large nodes, and you can tolerate losing a node's cached data with no failover. Choose Redis/Valkey for everything else - which in practice is most caching work - because the moment you want a counter, a set, a queue, high availability, or a snapshot, Memcached cannot do it and Redis can. When in doubt, pick Valkey.
AutomaticFailoverEnabled when availability matters.CreateReplicationGroup for Memcached. Replication groups are Redis/Valkey only. Fix: provision Memcached with CreateCacheCluster and NumCacheNodes.| Alternative | Use When | Don't Use When |
|---|---|---|
| Redis/Valkey (replication group) | You need structures, HA, failover, or backups | A pure multi-threaded KV cache is all you need |
| Memcached (cache cluster) | Large, simple, multi-threaded KV cache; node loss tolerable | You need any structure, replication, or persistence |
| Serverless ElastiCache | Spiky/unknown traffic, no capacity planning wanted | Steady load where reserved nodes are cheaper |
| DynamoDB + DAX | You already store in DynamoDB and want a managed read cache | Data lives elsewhere or you need Redis structures |
| In-process cache (no ElastiCache) | Tiny, per-instance, non-shared data | Data must be shared across instances or survive restarts |
Redis/Valkey are rich in-memory stores with data structures, replication, failover, and backups. Memcached is a minimal, multi-threaded key-value cache with none of those - just keys, values, and TTLs. The extra capability is why Redis/Valkey fit most workloads.
Valkey is a drop-in fork of Redis OSS that AWS offers at lower cost. It behaves like Redis and works with the same clients, so it is the sensible default for new Redis-style caches unless you need a specific Redis-only version.
CreateReplicationGroup for Redis/Valkey (primary plus replicas, failover, backups) and CreateCacheCluster with NumCacheNodes for Memcached (independent nodes, no replication). Using the wrong call for the engine is a common first mistake.
No. Memcached has no replication, so there is nothing to promote when a node fails - that node's keys are simply lost until they refill from the backing store. If you need availability, choose Redis/Valkey with automatic failover.
No. Memcached stores opaque key-value blobs only. Lists, sets, sorted sets, hashes, counters, and streams exist only in Redis/Valkey. If your design uses any of those server-side, Memcached is not an option.
When you need a large, simple key-value cache, want to use many vCPUs on a single node (Memcached is multi-threaded), and can tolerate losing a node's cached data. Those conditions are narrow, which is why Redis/Valkey is the more common pick.
Memcached scales horizontally by adding nodes, with the client sharding keys across them via consistent hashing, and each node uses multiple threads. Redis scales per-node by adding shards (cluster mode), since command execution on a node is single-threaded.
Yes. Redis/Valkey handle simple string GET/SET with TTL perfectly well, so you can use them exactly like Memcached and keep the option to add structures, HA, or backups later. That flexibility is why they are the safe default.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026