Amazon ElastiCache

What it is

Amazon ElastiCache is a fully managed in-memory cache and data store, compatible with the Valkey, Memcached, and Redis OSS engines. Because data is held in memory, reads take microseconds instead of the milliseconds a disk-based database needs. AWS handles provisioning, patching, failure detection, and node replacement.

The classic use is to put a cache in front of a database, such as Amazon RDS, Aurora, or DynamoDB, so repeated reads come from memory. That reduces load on the database and speeds up the application. Other common uses are session stores, leaderboards (Valkey and Redis OSS sorted sets), Publish/subscribeA messaging pattern in which senders publish messages to a topic without knowing who receives them, and every subscriber to the topic gets a copy. Amazon SNS works this way.Glossary entry messaging, and memory for generative AI assistants.

ElastiCache needs application changes: your code decides what to cache and when. It runs inside your VPC.

Two ways to deploy

	ElastiCache Serverless	Node-based cluster
Capacity	None to plan: scales vertically and horizontally on its own	Choose the node type, number of nodes, shards, and replicas
Availability	Data stored across three AZ (Availability Zone)An isolated location within an AWS Region, made up of one or more data centers with their own power, cooling, and networking. The AZs in a Region are linked by fast, low-latency connections, so spreading resources across them protects against the failure of one site.Glossary entry; 99.99% SLA (Service level agreement)A provider's commitment to a level of service, such as a monthly uptime percentage, and what customers receive if it is missed, usually service credits.Glossary entry	You place nodes across Availability Zones and turn on Multi-AZRunning standby or extra copies of a resource in other Availability Zones so that it survives the loss of one. An Amazon RDS Multi-AZ deployment keeps one or two standby copies and fails over to one automatically.Glossary entry
Pricing	Data stored (GB-hours) plus ElastiCache Processing Units (ECPUs) for requests	Per node-hour; reserved nodes for 1 or 3 years
Choose when	Unpredictable traffic, or you want the least operations	Steady traffic, fine-grained control, or features such as Global Datastore and data tiering

Choosing an engine

	Memcached	Valkey and Redis OSS
Data types	Simple strings and objects	Strings, lists, sets, sorted sets, hashes, geospatial indexes, and more
Replication and FailoverSwitching automatically to a standby resource when the primary one fails, such as a standby database in Amazon RDS or a backup site chosen by Route 53 failover routing.Glossary entry	No	Yes: replicas with automatic failover
Backup and restore	Serverless caches only	Yes, snapshots
Pub/sub, sorted sets	No	Yes
Threads	Multi-threaded	Single-threaded command processing (Valkey adds I/O threading)
Choose when	You want the simplest cache, large multi-core nodes, and to add and remove nodes freely	You need HA (High availability)The ability of a system to keep serving users when parts of it fail, usually by running redundant copies across Availability Zones and failing over automatically. It is often stated as a percentage of uptime, such as 99.99%.Glossary entry, persistence, replication, or rich data structures

Valkey is an open-source engine compatible with Redis OSS, and AWS prices it lower: 20% less than Redis OSS on nodes, and 33% less on Serverless. Valkey 9.0 adds an optional durability setting, a Multi-AZ transactional log that can prevent data loss on failure. For a durable primary database, Amazon MemoryDB is the purpose-built service.

Vector search: ElastiCache for Valkey 8.2 and later can index vector embeddings (HNSW for fast approximate results, or FLAT for exact ones) and find the nearest with Euclidean, cosine, or inner product distance. Typical uses are semantic caching of answers from large language models, RAG, and memory for AI agents. MemoryDB also has vector search, for the lowest LatencyThe time between sending a request and receiving the response, usually measured in milliseconds. Distance and processing add to it; caching and serving users from nearby locations reduce it.Glossary entry with a durable store.

Caching strategies

Lazy loadingA caching strategy that adds data to the cache only when it is requested and missing, reading it from the database then. Only requested data is cached, but the first read is slower and cached data can become out of date.Glossary entry (cache-aside): the application reads from the cache. On a miss, it reads from the database and writes the result to the cache. Only requested data is cached, but the first read is slow and data can go stale.
Write-throughA caching strategy that writes data to the cache every time it is written to the database, so the cache stays current. Writes take longer, and data that is never read still takes up cache space.Glossary entry: the application writes to the cache every time it writes to the database. The cache is always current, but it stores data that may never be read and adds latency to every write.
TTL (Time to live)How long something stays valid before it expires. A DNS record or cached item can be reused until its TTL runs out, then is fetched again; in DynamoDB, a TTL attribute deletes items after a set time.Glossary entry (TTL): give keys an expiry so stale data ages out and memory is reclaimed. Combine TTL with lazy loading or write-through.
Eviction: when memory is full, the engine evicts keys by policy, such as least recently used.

Security, resilience, performance, and cost

Security

Deploy in SubnetA range of IP addresses in a VPC, inside one Availability Zone. A subnet is public when its route table sends internet traffic to an internet gateway, and private when it does not.Glossary entry and allow the cache port only from the application's Security groupA stateful virtual firewall for network interfaces, such as an EC2 instance's, whose rules can only allow traffic. Return traffic for allowed connections is allowed automatically, and a rule can refer to another security group instead of IP addresses.Glossary entry. ElastiCache is not reachable from the internet.
Encryption in transitEncrypting data while it moves across a network, usually with TLS, so that it cannot be read or changed on the way.Glossary entry (TLS (Transport Layer Security)The protocol that encrypts traffic between a client and a server and lets the server prove its identity with a certificate. It replaced SSL, though the older name is still common; HTTPS is HTTP over TLS.Glossary entry) and Encryption at restEncrypting data where it is stored, such as on disks, in databases, or in backups, so that it cannot be read without the key. On AWS it usually uses keys in AWS KMS.Glossary entry (with a customer managed KMS key if needed).
Authentication (Valkey and Redis OSS):
- The AUTH command takes a token (password).
- RBAC (Role-based access control)Granting permissions to roles, such as administrator or developer, and giving people the roles they need, instead of granting permissions to each person. IAM roles and IAM Identity Center permission sets follow this model.Glossary entry (RBAC) gives each user its own permissions.
- IAM authentication (version 7 or later) uses short-lived IAM tokens instead of passwords.

Resilience

Replication groups (Valkey and Redis OSS): a primary node plus up to 5 Read replicaA read-only copy of a database that is updated asynchronously from the primary. It takes read traffic off the primary, can be in another Region, and can be promoted to a standalone database.Glossary entry per shard.
With Multi-AZ on, a replica in another Availability Zone is promoted automatically if the primary or its Availability Zone fails. Automatic failover is optional with cluster mode disabled and required with cluster mode enabled.
Snapshots back up the data so you can restore a cache or seed a new one.
Global Datastore (node-based Valkey and Redis OSS): one primary (active) cluster that takes writes, and secondary (passive) clusters in other AWS RegionA separate geographic area where AWS runs its services, such as us-east-1 in Northern Virginia, made up of several Availability Zones. Most resources live in one Region; you choose Regions for latency, data residency, and the services you need.Glossary entry that serve low-latency local reads and can be promoted for DR (Disaster recovery)Preparing for and recovering from events that take a workload down, such as a Regional outage or deleted data. AWS describes four strategies, from cheapest and slowest to costliest and fastest: backup and restore, pilot light, warm standby, and multi-site active/active.Glossary entry.
Memcached has no replication: losing a node loses its data. Treat it purely as a cache.

Performance

Cluster mode enabled (Valkey and Redis OSS) shards data across up to 500 shards for more memory and write throughput, with online resharding.
Read replicas (up to 5 per shard) scale reads only. With cluster mode disabled there is one primary, so writes and data size are limited by one node; when writes or memory run out, move to cluster mode enabled with more shards rather than adding replicas.
Auto scaling (node-based) adds shards or replicas with target tracking.
Data tiering (r6gd nodes) moves less-used data from memory to local SSD (Solid state drive)Storage on flash memory with no moving parts, fast at small random reads and writes (high IOPS). Amazon EBS gp3, gp2, io2, and io1 volumes are SSD-backed.Glossary entry, for large data sets at lower cost.

Cost

Serverless: pay for data stored (GB-hours) and ECPUs. Node-based: pay per node-hour, with reserved nodes for 1 or 3 years for steady use.
Choose Valkey for the lowest price. Database Savings Plans cover ElastiCache for Valkey.
A cache can lower total cost by letting you run a smaller database.

Monitoring

CloudWatch metrics include CPU, memory use, evictions, cache hits and misses, replication lag, and, for Serverless, ECPUs consumed.
A low hit rate or many evictions means the cache is too small or the caching strategy needs work.
Events go to SNS (node-based) or EventBridge (Serverless).

ElastiCache or another option?

If the requirement is	Choose
Microsecond reads of hot data in front of any database	Amazon ElastiCache
Microsecond reads in front of DynamoDB only, with no caching code	DynamoDB Accelerator (DAX)
Shared session state for a fleet of web servers	ElastiCache (or DynamoDB)
Read-heavy SQL (Structured Query Language)The standard language for querying and changing data in relational databases. Analytics services such as Amazon Athena and Amazon Redshift also use SQL.Glossary entry queries that need the full database	RDS or Aurora read replicas
Cache static content and media close to users	Amazon CloudFront
A durable in-memory primary database	Amazon MemoryDB

Reverse mindmap: when the question points here

Is it Amazon ElastiCache?

Yes, when the question says
- Reduce read load on RDS or Aurora leads to ElastiCache in front
- Sub-millisecond or microsecond reads of repeated queries leads to ElastiCache
- Store user sessions outside the web servers leads to ElastiCache
- Real-time leaderboard leads to Valkey or Redis OSS sorted sets
Choose the setup
- No capacity planning leads to ElastiCache Serverless
- Simplest cache, multi-threaded, no replication leads to Memcached
- High availability with automatic failover leads to Valkey or Redis OSS, Multi-AZ
- More memory or write throughput leads to Cluster mode with shards
- More read throughput only leads to Add read replicas
- Fast reads in another Region, DR leads to Global Datastore
- Lowest price leads to Valkey engine
- Cache only what is requested leads to Lazy loading
- Cache always up to date leads to Write-through
- Remove stale data automatically leads to TTL
Secure it
- Password for the cache leads to AUTH or RBAC
- No passwords, IAM identities leads to IAM authentication
No, when the question says
- Cache for DynamoDB only, no code changes leads to DAX
- Cache static files at the edge leads to CloudFront

Key takeaways

ElastiCache is a managed in-memory cache (Valkey, Memcached, Redis OSS) that gives microsecond reads and offloads databases; the application must be changed to use it.
Serverless needs no capacity planning; node-based clusters give control and reserved nodes.
Memcached is simple and multi-threaded but has no replication or failover; Valkey and Redis OSS add replicas, Multi-AZ failover, snapshots, sharding, and Global Datastore.
Lazy loading caches on a miss; write-through updates on every write; TTL expires stale data.
Valkey is priced 20% lower on nodes and 33% lower on Serverless than other engines.