AWS Amazon ElastiCache? The Cache in Front of Everything Explained

Amazon ElastiCache is AWS's managed in-memory caching service — a fast, temporary data store that sits in front of your real database (RDS, Aurora, DynamoDB, DocumentDB) and answers the questions your application keeps asking, so the database doesn't have to. It runs three engines — Valkey, Redis OSS, and Memcached — and comes in two deployment flavors: a serverless option where you give AWS a cache name and nothing else, and a node-based option where you pick the exact hardware. The part almost nobody tells you up front: ElastiCache Serverless only accepts clients that speak TLS, always — there is no toggle to turn that off, so an older application that connects without encryption will simply fail to reach a serverless cache, and the error will look like a mystery timeout rather than a policy choice. And the deeper truth the name hides: "ElastiCache" has nothing to do with EC2's elasticity model — it is not compute, not storage, and it shares nothing with Elastic Block Store except the word "Elastic."

Jake's phone-shop website had a problem that looked like a hosting problem but wasn't. Every product page — every single one — walked to the database, asked for the case list, the color list, the price list, waited for the answer, and then finally rendered. Ten customers browsing at once meant the same questions asked sixty times a minute, and the page took long enough to load that two of them gave up.

His host said "upgrade the plan." His developer said "add a cache." His nephew said "the site's just slow." All three were describing the same missing piece without naming it — and this article exists to name it, explain it, and show you what it costs.

What Is ElastiCache, in One Paragraph a Beginner Can Read

Amazon ElastiCache is a web service that makes it easy to set up, manage, and scale a distributed in-memory data store or cache environment in the AWS Cloud. Strip the AWS marketing language and the sentence is simpler: it is a very fast, very small short-term memory that lives in RAM instead of on disk, and it sits between your application and the thing that is actually slow. AWS manages the hardware, the monitoring, the node replacements, and the software patching, so you are buying the cache as a service rather than running Redis or Memcached on an EC2 instance yourself and becoming the person on call when it falls over at 2 a.m.

A cache — the concept, before the product — is a place to keep answers you expect to need again. If the top question at Jake's shop counter is "how much for a screen protector," you do not walk to the stockroom each time; you keep the price list at the counter. The stockroom is the database. The counter is the cache. Same information, different distance. The whole engineering discipline of caching is deciding what belongs at the counter, how long it stays there before you suspect it's stale, and what to do when someone asks a question the counter has never heard.

ElastiCache works as a front-end caching layer in front of AWS database services like Amazon RDS, Amazon Aurora, Amazon DocumentDB, and Amazon DynamoDB, reducing database load. That is the entire job: take the repetitive reads off the database's plate so the database can spend its effort on the writes, the complex queries, and the things only it can do. Every layer of a well-built AWS application ends up with some cache in front of it — a CDN like CloudFront in front of the web servers, ElastiCache in front of the databases — which is exactly why the title of this article calls it "the cache in front of everything."

"That's the mindset shift people skip," Ethan said when Jake asked why the distinction mattered. "A cache is allowed to be empty. It's allowed to vanish. Its whole contract with the rest of the system is 'I make the common case faster, and I am not the source of truth.' The database is the source of truth. Confuse the two and you'll design a system where clearing the cache loses data — which is how 'we lost the cart' stories start."

The Name Trap: ElastiCache vs EC2 vs EBS vs Every Other "Elastic" Thing

If you searched "aws elastic compute cloud" or "elastic block storage aws" or "elastic search in aws" and landed here, you are not lost — you are experiencing the single most confusing naming convention in AWS. At least six unrelated services start with "Elastic" or get tangled with it, and the word means something different in each. Here is the honest disambiguation table that the search results never give you in one place:

The one that catches people most often: ElastiCache is not a database, not block storage, and not search. It holds data in RAM, it expects that data to be recreatable, and — on the serverless flavor — it requires encrypted connections. If you came here from a search for "elastic block storage," "elastic file system," or "elastic search," you want EBS, EFS, or OpenSearch Service respectively, and the difference matters the way the difference between a counter, a stockroom, and a catalog matters: same street, different job.

There is also an "elasticity vs scalability" confusion baked into all these names. Scalability is the ability to handle more load by adding resources. Elasticity is doing that automatically, in both directions — growing when traffic spikes and shrinking when it drops, so you pay for what you use rather than for the peak you planned for. ElastiCache Serverless is the genuinely elastic member of this family; the node-based option scales, but you drive.

How Caching Actually Works: Hits, Misses, and TTLs, Without the Jargon

Three words do most of the work in every caching conversation, and none of them are complicated once someone explains them plainly:

A cache hit is when the application asks the cache a question and the answer is already there. This is the fast path — the answer is sitting in RAM a network hop away instead of on a disk in a database doing real work.

A cache miss is when the answer isn't there. The application then goes to the database, gets the real answer, and (this is the part people forget to build) writes it into the cache so the next person with the same question gets the hit. A miss is not a failure; it is the system doing its job correctly — just the slow way, once.

A TTL — time to live — is the expiry date you stamp on each cached answer. Product prices change, so a price cached "forever" is a wrong price waiting to be shown. A TTL of five minutes means the cache holds the answer for five minutes, then forgets it, and the next request has to ask the database again. Choosing TTLs is where caching becomes a judgment call: too short and you barely save any database trips; too long and you serve stale data. A sane range to steal: 30 minutes to 24 hours for session context, longer or indefinite for persistent preferences.

"So it's the display case," Jake said. "The top sellers sit out front where I can grab them, and once a week I check the case still matches the stockroom."

"Exactly," Ethan said. "And the TTL is you deciding how often to re-check. Check every customer and you've gained nothing — you might as well walk to the stockroom. Never check and you sell a case at last month's price. Every caching decision is that trade, made per piece of data."

How fast is ElastiCache in practice? AWS positions it as a high-performance in-memory cache, and the specific performance claims land in microsecond territory — microsecond latency for Valkey's vector search, microsecond read latency for durability workloads. The honest framing for a phone-shop owner: the database answers in tens of milliseconds when it's having a good day; the cache answers in under one. The difference is the difference between "the site feels instant" and "the site feels like a website."

The Three Engines: Valkey vs Redis OSS vs Memcached, and Which One You Actually Want

ElastiCache is the managed wrapper; inside it runs one of three engines, and the engine choice changes what your cache can do. On the surface all three are in-memory key-value stores — a key is a label, a value is the thing you stored under that label — but in practice there are significant differences.

The history matters for one sentence: Valkey is the open-source fork that the community created after Redis changed its license, and AWS now points new deployments toward it. ElastiCache for Valkey is compatible with existing Redis OSS-based applications — and if you already own reservations, existing Redis OSS reserved nodes automatically apply to Valkey nodes in the same instance family and Region, so the engine upgrade carries your reservation benefits with it. Valkey is also priced 20% lower than Redis OSS on node-based clusters and 33% lower on serverless. If you are starting fresh, Valkey is the recommended default engine unless you have a specific reason otherwise.

The choosing logic, stated plainly:

• Choose Memcached if: you need the simplest possible model, you want large nodes with multiple cores or threads, you need to scale out and in by adding and removing nodes as demand changes, and you are caching plain objects.
• Choose Valkey or Redis OSS if: you need complex data types (sorted sets, lists, hashes, bitmaps), high availability with replication, backup and restore, pub/sub, geospatial queries — or, on newer Valkey versions, vector search and durability.

The feature comparison:

One trap worth knowing before you load anything: after you create a cache, you can upgrade to a newer engine version, but you cannot downgrade. If you want an older engine version, you must delete the existing cache and create it again with the earlier version. Pick the version before you load the data.

The Redis OSS end-of-life question. Redis OSS versions eventually reach community end-of-life, and Extended Support exists for exactly this gap: it lets you continue using Redis OSS major versions after that date while AWS provides fixes for critical security issues and bugs through patch releases, giving you up to three years to upgrade to a new major version. If you are running an older Redis OSS cluster today, the Extended Support decision and the move-to-Valkey decision are the same conversation — one buys you time, the other removes the question.

Jake's read of the table was the right one: "Memcached is the counter with nothing on it but the price list. Valkey is the counter with the till, the calendar, and the review stickers." That is not far off. Memcached does one thing — hold objects in memory — and does it with a multi-threaded simplicity some teams still prefer. Valkey (and Redis OSS before it) is the one with sorted sets for leaderboards, replication for surviving a dead node, and — since Valkey 8.2 — vector search for the AI work we'll get to later.

Serverless vs Node-Based: The Two Deployment Options, Compared Honestly

Under the engines sits a second choice that trips people up just as often: how the cache is deployed. ElastiCache Serverless is the "give it a name and walk away" option — you provide a cache name, and AWS handles capacity planning, scaling, node placement, and patching. A node-based cluster is the "I'll drive" option — you choose the node type, the number of nodes, and their placement across Availability Zones, and you keep the keys.

The decision logic is plain. Choose serverless caching if you are creating a cache for workloads that are new or difficult to predict, if your traffic is unpredictable, or if you want the easiest way to get started. Create your own node-based cluster if you want finer-grained control over node type and placement, if your traffic is relatively predictable, if you can forecast capacity to control costs — or if you need durability, which node-based Valkey 9.0+ clusters can enable through a Multi-AZ transactional log.

The full feature comparison:

Two rows in that table cause real outages and real confusion, so they deserve their own paragraph each.

The TLS-only rule. ElastiCache Serverless runs the engines in cluster mode and is only compatible with clients that support TLS. There is no setting to change this. If your application connects with a client that doesn't do TLS — some older Memcached clients, some legacy custom code — the connection fails, and the failure presents as a generic timeout or connection refused that sends people down the wrong debugging path entirely. Before choosing serverless, confirm your client speaks TLS. On node-based clusters, TLS is an option you enable; on serverless, it is a condition of entry.

The cluster-mode requirement. Serverless for Valkey and Redis OSS operates in cluster mode enabled only, and clients must support cluster mode to connect. If your existing application was built against a single-instance Redis without cluster-mode awareness, that application cannot simply be pointed at a serverless cache — the client needs cluster-mode support or the connection behavior will be wrong. This is a compatibility check, not a settings tweak.

How ElastiCache Serverless Works Under the Hood (Without Going Under the Hood)

When you create a serverless cache, ElastiCache creates VPC Endpoints in the subnets of your choice in your VPC, and your application connects through those endpoints. You receive a single DNS endpoint. When your application requests a new connection to that endpoint, ElastiCache handles it through a proxy layer — a set of proxy nodes behind a network load balancer.

That proxy layer is the trick that makes the single-endpoint experience work. The proxy abstracts the cluster topology and nodes from your client, which is what allows ElastiCache to scale out, add cache nodes, replace failed nodes, and update software — all without your application noticing and without resetting connections. On a node-based cluster, if a node is replaced, the client has to rediscover the cluster topology and re-establish connections. On serverless, the proxy absorbs that. It's the difference between the customer always talking to the same person at the counter versus the customer being told to go find whichever stockroom clerk is free today.

ElastiCache Serverless continuously monitors the memory, compute, and network bandwidth utilization of your cache and scales both vertically and horizontally — a node can grow in size while, in parallel, a scale-out operation adds capacity. Data is replicated asynchronously across three Availability Zones for availability and read latency. If the underlying cache nodes fail, ElastiCache automatically replaces them. Minor and patch software upgrades happen automatically with no application impact; for major version upgrades, you get a notification and decide when to move.

One practical note that saves people a bad afternoon: when you create a serverless cache you provide the subnets your application will access the cache from, and ElastiCache creates VPC Endpoints in those subnets. Ensure your application is deployed in the same Availability Zones. Otherwise your application incurs a cross-AZ hop when accessing the cache, and client-side latency goes up — the cache still works, but it works slower than it should, which is worse than useless because it hides the cause.

The other operational habit that matters: reuse connections. Serverless requests run over a TLS-enabled TCP connection using the RESP protocol, and initiating a connection — including authentication, if configured — takes time, so the first request on a fresh connection is slower than the rest. Requests over an already-initialized connection deliver the consistent low latency you bought the cache for. This is why connection pooling matters: a pool of warm connections beats a new connection per request every time.

Node Types Explained: Reading Names Like cache.r6g.large Without Guessing

If you choose the node-based route, you will spend real time on the node-type picker, so the naming system is worth sixty seconds of explanation. A node is the smallest building block of an ElastiCache cluster — and current-generation types provide more memory and computational power at lower cost than their previous-generation equivalents. That single sentence is the reason nobody should be launching previous-generation node types for a new cluster.

The name pattern reads: family letter + generation number + size, as in cache.r6g.large. The family letter tells you the shape of the machine — the M family is the balanced line, the R family is the memory-heavy line you reach for when the dataset is the point. The generation number is the hardware refresh — each new generation gives you more for the money. The size word (large, xlarge, 2xlarge, and upward) scales everything within the family. And one suffix carries a specific meaning worth memorizing: the d in r6gd marks the data-tiering nodes that pair memory with a local SSD, automatically moving your least-frequently-used data to the cheaper tier.

Two concrete rates, to anchor the scale: cache.r7g.large at $0.1752 per hour on the small end, and cache.r6gd.xlarge at $9.9816 per hour for a data-tiering node in a large durability setup. The full per-node specification table — vCPUs and memory for every type — lives on the Supported node types page, and that is the one to consult before committing to a size: node specs change with generations, and any table copied into an article goes stale on the next hardware refresh.

"So I read the name like a shirt label," Jake said. "R for the big-pocket one, d for the one with the spare drawer."

"That's better than most cloud naming mnemonics," Ethan said. "And remember reserved nodes are size-flexible within the family — you can buy the reservation at one size and run another, which removes most of the fear from the initial pick."

That last point de-stresses the decision: reserved nodes are size-flexible — applicable across differently sized nodes in the same family and Region — so your first node-size choice is not a commitment but a starting point you right-size later without losing the reservation discount.

Pricing: What ElastiCache Actually Costs, With Worked Examples

There are three pricing options: on-demand nodes, serverless, and Database Savings Plans. On-demand and serverless have no minimum fees and no upfront commitments. Database Savings Plans trade a one-year usage commitment (measured in dollars per hour) for savings. Every figure below uses US East (N. Virginia) rates — rates vary by Region, so treat these as the shape of the math rather than your exact bill.

Serverless pricing: GB-hours plus ECPUs

Serverless bills on two dimensions. Data storage is billed in gigabyte-hours — ElastiCache samples the amount of data stored multiple times per minute, averages it per hour, and bills that. Compute is billed in ElastiCache Processing Units, or ECPUs, a unit that includes both vCPU time and data transferred.

The ECPU math is the part worth actually understanding, because it's where bills surprise people:

• Simple reads and writes — GET and SET — consume 1 ECPU per kilobyte of data transferred. A GET that transfers up to 1 KB consumes 1 ECPU. A SET that transfers 3.2 KB consumes 3.2 ECPUs.
• Commands that consume more vCPU time charge on the higher of the two dimensions — vCPU time or data transferred. An HMGET that takes 3× the vCPU time of a SET/GET and transfers 3.2 KB costs 3.2 ECPUs; if it transfers only 2 KB, it still costs 3 ECPUs because the vCPU dimension was higher.
• With Memcached, commands operating on multiple items charge proportionally — a multiget on 3 items consumes 3 ECPUs.

There is a minimum metered storage per cache: 100 MB for ElastiCache Serverless for Valkey, and 1 GB per cache for Memcached and Redis OSS. That minimum is the reason a tiny dev cache still shows up on the bill — and the reason Valkey's lower minimum is genuinely useful for staging environments.

Worked examples, at US East (N. Virginia) rates:

Three things to read off those examples. First, the Valkey serverless rates are $0.084 per GB-hour and $0.0023 per million ECPUs — the storage rate alone is the line item most people underestimate. Second, the leaderboard example shows how compute-heavy commands (the 3× vCPU case) can make ECPUs the majority of the bill, not storage. Third, the e-commerce and Memcached examples show serverless beating on-demand nodes at moderate scale with spiky traffic — serverless optimizes costs by scaling when needed rather than provisioning for peak, and that is exactly the workload it was designed for.

On-demand node pricing: per node-hour

On the node-based side, you pay per hour for each cache node, billed from the moment the node is available until it is terminated — each partial node-hour counts as a full hour. The ladder spans from cache.r7g.large at $0.1752 per hour to cache.r6gd.xlarge (the data-tiering family) at $9.9816 per hour — from "rounding error" to "line item you explain to the CFO."

Reserved nodes bring the node-based costs down for predictable workloads: no-upfront reservations save up to 48.2% versus on-demand, partial-upfront up to 52%, and all-upfront up to 55%, in one- or three-year terms. Reservations are size-flexible within the same instance family and Region, and — a detail worth knowing if you're migrating — existing Redis OSS reserved nodes automatically apply to Valkey nodes in the same family and Region, so upgrading the engine keeps your reservation benefits with 20% more value because Valkey is priced lower.

Durability pricing: the 18% surcharge for synchronous writes

If you enable durability on a Valkey 9.0+ node-based cluster, asynchronous writes carry no additional charge beyond node-hours. Synchronous writes — the zero-data-loss option — are priced at 18% on top of the standard node-hour price. That is a clean number to hold in your head: durability with sync writes costs roughly a fifth more than the same cluster without it.

The AWS Free Tier: read this part carefully, it changed

The Free Tier terms split on July 15, 2025. If you signed up before that date, you have 750 hours of ElastiCache cache.t3.micro node usage free for up to 12 months, plus 15 GiB of free data transfer out per month aggregated across AWS services — with ElastiCache Serverless, GovCloud, and the China (Beijing) Region excluded. If you sign up after July 15, 2025, you choose between a Free Plan or a Paid Plan; either way you receive $100 in credits, plus up to an additional $100 for activating foundational AWS services, and once those credits are gone you need the Paid Plan to continue. The practical read: there is no longer an open-ended "free micro cache forever" tier for new accounts — there is a credit, and then there is a bill.

What ElastiCache Is Actually Used For: The Real Workloads

The use cases cluster into five patterns, and each one answers a different "why is my thing slow" question.

Database caching — the classic. The application asks the cache before the database; only misses reach RDS, Aurora, DynamoDB, or DocumentDB. This is Jake's product-page problem in its purest form — a front-end caching layer for those database services, reducing database load. The win is both latency and database headroom: the database stops answering the same question sixty times a minute.

Session storage. When a user logs in, their session — who they are, what's in their cart, where they were — has to live somewhere every request can reach quickly. A cache is the natural home: fast, shared across all your web servers, and with TTLs that expire sessions on a schedule rather than accumulating forever. The canonical workload is exactly what it sounds like: a distributed session store for an e-commerce platform, holding user sessions and shopping cart data.

Gaming leaderboards. A leaderboard is a sorted set — a data structure where items are stored with scores and stay in order — and sorted sets exist in Valkey and Redis OSS but not Memcached. The canonical example: a gaming company maintaining a leaderboard with a 100 GB dataset of 1.2 KB objects in a Valkey SortedSet, at 500,000 requests per second, where each request consumes 3 ECPUs because sorted-set operations take roughly three times the vCPU time of a plain SET/GET. That example is worth internalizing because it's the rare case where the compute dimension, not storage, dominates the bill.

Real-time analytics and messaging. Pub/Sub — publish/subscribe messaging — is supported on Valkey and Redis OSS, letting parts of your system broadcast events that other parts listen for, all through the cache. Combined with ElastiCache's throughput, this covers real-time dashboards and event-driven patterns where a full message broker would be heavier than the job needs.

AI workloads — semantic caching and agentic memory. This is the newest and fastest-growing cluster of use cases, and it deserves its own section, which is next.

Semantic Caching and Agentic Memory: The New Reason People Are Buying ElastiCache

Everything above is the last decade of caching. This section is the next one, and it is why ElastiCache for Valkey specifically has become interesting again.

Semantic caching is caching that matches on meaning rather than exact string. A traditional cache treats "How do I install the VPN app on my laptop?" and "Can you guide me through setting up the company VPN?" as two different questions, because they are two different strings, and answers the LLM twice. A semantic cache converts each query into a vector embedding — a long list of numbers produced by a model like Amazon Titan Text Embeddings that captures semantic meaning in a high-dimensional space — stores the embedding alongside the response, and compares each new query's embedding against the cached ones. If a similar query exists above a configured similarity threshold, the cached response comes back and the LLM is never invoked.

The benchmarks for the pattern are worth staring at: semantic caching reduced LLM inference cost by up to 86% and achieved up to 88% latency reduction, with cache hits returning in milliseconds rather than seconds. The use cases it fits: RAG-based assistants and copilots (IT help chatbots, product FAQ bots), agentic AI applications (compliance agents reusing policy lookups, research agents reusing prior findings), and multimodal applications matching similar audio, image, or video queries.

Valkey's vector search arrived in version 8.2 with microsecond latency and a 95%+ recall rate, which is what makes ElastiCache viable as the vector store in this pattern — and version 9.0 extended it with full-text search, hybrid search (text plus vector), and aggregation pipelines. The point for a buyer: the gap between "a cache" and "a vector database" has narrowed enough that one service can sometimes do both jobs.

One term to untangle before it untangles you, because it brings people to this page: prompt caching is not an ElastiCache feature. The phrase refers to caching at the AI model provider — reusing the processed front of a long prompt so repeated conversations sharing the same context cost less to run — and it happens inside the AI service, billed by that service. Semantic caching with ElastiCache attacks the same bill from your side of the fence: instead of the provider caching your prompt prefix, you cache whole answers and skip the model entirely on similar questions. Same goal, different layer, and the two can stack.

Agentic memory is the other half of the AI story, and it has become a first-class use case in its own right. AI agents — programs that plan tasks, call tools, and carry context across steps — need memory of two kinds:

• Short-term memory maintains context within a single session — the current conversation flow, recent interactions, intermediate reasoning steps. ElastiCache for Valkey supports it with lists (ordered chat history), hashes (session metadata), and strings (tool result caching with TTL-based expiration).
• Long-term memory stores information across sessions — user preferences, past decisions, historical context — and requires semantic retrieval, finding memories by meaning rather than keyword match. Valkey's vector similarity search (8.2+) provides this.

Three additional memory types for agents: episodic memory (records of specific past interactions, via vector search over stored conversation embeddings), semantic memory (general knowledge and facts, via vector similarity search with HNSW or FLAT indexes), and procedural memory (knowledge of how to perform tasks and use tools, via hash-based storage of tool configurations and workflows).

Jake's version, after Ethan explained it: "So the agent has a counter brain and a stockroom brain. During one conversation it remembers what you just said — that's the counter. Between conversations it remembers what you like — that's the stockroom with a search engine." That is a fair compression of the whole idea.

ElastiCache vs MemoryDB vs DAX vs CloudFront: Which Cache for Which Layer

"AWS caching service comparison" is a genuinely confusing search because AWS offers several caches at different layers of the stack, and they are not substitutes. Here is the layer map:

The ElastiCache vs MemoryDB question deserves one more paragraph because it's the one people get wrong in both directions. Amazon MemoryDB is a fully managed, Valkey- and Redis OSS-compatible, in-memory database — it delivers both in-memory performance and Multi-AZ durability, and can serve as a high-performance primary database for microservices applications. ElastiCache is the cache: cheaper, and honest about the fact that its data is disposable. The blunt rule: if you can afford to lose the data and rebuild it from a real database, that's ElastiCache. If losing the data is unacceptable and you still need microsecond reads, that's MemoryDB. The line has blurred slightly — Valkey 9.0's durability feature brings transactional-log persistence into ElastiCache's node-based option — but the intended jobs remain different.

Security: VPC, Encryption, IAM, and the Things That Bite People

ElastiCache runs inside Amazon VPC — the virtual private cloud that defines your private network in AWS — and the use of EC2-Classic for launching ElastiCache clusters is deprecated; all current-generation nodes launch in a VPC. Within the VPC, you control access to the cache using VPC security groups, and you place cache nodes in the subnets you choose.

Encryption at rest. On serverless caches, encryption at rest is always enabled — no option, no toggle — and you can use either an AWS-managed key or your own customer-managed key in AWS KMS. What it encrypts: disk during sync, backup, and swap operations; backups stored in Amazon S3; and Multi-AZ transactional durability logs where durability is enabled. Data on SSDs in data-tiering-enabled clusters is always encrypted. On node-based clusters, encryption at rest is optional — you enable it and choose your key.

Encryption in transit. The TLS story again, because it's the one that actually breaks deployments: serverless is TLS-only, always; node-based lets you enable or disable it. If you are migrating an old application that has never spoken TLS to a cache, either add TLS support to the client or use node-based with TLS disabled — but know that disabling encryption in transit on any cache holding session tokens or user data is a decision to defend, not a default to drift into.

IAM. ElastiCache integrates with AWS Identity and Access Management for controlling who can manage the caches themselves — creating, modifying, deleting — through identity-based policies, resource-level permissions, and condition keys. Authentication of the cache clients is separate: Valkey and Redis OSS support user authentication via IAM, with automatic password rotation, and the older AUTH mechanism still exists with documented migration paths from AUTH to IAM.

Backups and Restore: What Survives, What Doesn't

A backup is a point-in-time copy of a serverless cache or a Valkey/Redis OSS node-based cluster, consisting of all the data in the cache plus some metadata. You can take backups at any time or set up automatic backups, and backups can be used to restore an existing cache or to seed a new one.

The differences worth knowing between the deployment options: serverless supports automatic and manual backups with no performance impact. Node-based clusters support both too, but may see some performance impact depending on the available reserved memory. And there is a cross-compatibility detail that saves real migration pain: Valkey and Redis OSS backups are cross-compatible, and can be restored into either an ElastiCache Serverless cache or a node-based cluster. You are not locked into one deployment option by your backup history.

Memcached, on node-based clusters, does not support backup and restore — that capability is serverless-only for Memcached. If backup matters to your Memcached use case, that is serverless Memcached or a different engine.

Creating Your First Cache: Console and CLI, Step by Step

The serverless path is short enough to be almost anticlimactic. In the AWS Management Console:

1. Sign in to the AWS Management Console and open the ElastiCache console at https://console.aws.amazon.com/elasticache/.
2. In the navigation pane on the left, choose the engine — for example, Redis OSS caches (or Valkey caches, depending on the console's current grouping).
3. On the right side of the console, choose Create Redis OSS cache (or the Valkey equivalent).
4. In Cache settings, enter a Name, and optionally a description.
5. Leave the default settings selected — for a first cache, the defaults are the point.
6. Choose Create.
7. Once the cache is available, find its endpoint in the cache details and configure your client to use it.

The same journey from the command line, as a sequence you can run end to end:

1. Create the cache with a single command:

   aws elasticache create-serverless-cache \
     --serverless-cache-name my-first-cache \
     --engine valkey

2. Wait for the cache status to reach Available — visible in the console or through the ElastiCache CLI. Until it is available, there is nothing to connect to.
3. Copy the cache endpoint from the cache details. This single DNS endpoint is the only address your application ever needs.
4. From an EC2 instance in the same Availability Zone, connect with valkey-cli (or your language's Redis-compatible client) over the TLS connection the serverless cache requires.
5. Write a test key and read it back — a SET followed by a GET — to confirm the round trip works before pointing your application at it.
6. When you are done experimenting, delete the cache. Billing runs from creation to deletion; there is no paused state.

For connecting from an application: find the cache endpoint and connect from an EC2 instance using valkey-cli, over TLS. For Python, there's a getting-started tutorial covering exactly this, including configuring Lambda to access ElastiCache in a VPC. And for AI coding agents, an ElastiCache Skill and a Valkey MCP server now exist to give agents the specialized knowledge to work with the service — an unusual but real corner of the current offering.

Terraform users manage serverless caches through the aws_elasticache_serverless_cache resource, and node-based clusters through the aws_elasticache_replication_group and aws_elasticache_parameter_group resources — the resource names the infrastructure-as-code crowd searches for.

Troubleshooting: The Failures That Actually Happen

Organized by what you see, because that's how failures present themselves:

One billing behavior that belongs in every troubleshooting table in spirit: billing for ElastiCache Serverless commences as soon as the cache is available and continues until the cache is deleted, in any Available or Updating state. There is no stop button — only delete. Dev and staging caches left running over a weekend are the classic source of the "what is this charge" email.

When You Should NOT Use ElastiCache

Some walls are real, and naming them plainly does more good than pretending otherwise.

If your data cannot be recreated from a source of truth, it does not belong in a cache — that is a database's job, and possibly MemoryDB's if you need it fast and durable. If your access pattern is almost entirely writes with no repeated reads, a cache adds cost and complexity without hits to serve; caching is an optimization for repetition. If your reads are unique per user and never repeat — think fully personalized feeds with no shared hot set — the hit rate that justifies the cache may never materialize.

And if what you actually want is to make a website faster for users around the world, start with CloudFront caching the HTTP responses at the edge before adding an application-layer cache — caching at the CDN layer solves the geographic-latency problem that ElastiCache, sitting in one Region next to your database, cannot.

FAQ

What is AWS ElastiCache in simple terms?

It's a managed, very fast temporary data store that sits between your application and your database. Your app asks ElastiCache first; only if the answer isn't there does it go to the database. AWS runs it on the Valkey, Redis OSS, or Memcached engine and handles all the server management.

Is ElastiCache the same as Redis?

No — Redis OSS is one of three engines ElastiCache can run (the others are Valkey and Memcached). ElastiCache is AWS's managed wrapper: the engine inside, plus AWS handling hardware, scaling, patching, backups, and failover. Valkey, the open-source fork of Redis, is now the recommended engine for new deployments, and it's compatible with existing Redis OSS-based applications.

How much does AWS ElastiCache cost?

Two models. Serverless bills on data stored (GB-hours) plus compute (ECPUs) — at US East rates, Valkey serverless runs about $0.084 per GB-hour and $0.0023 per million ECPUs, with a 100 MB minimum per Valkey cache. Node-based bills per node-hour; cache.r7g.large runs $0.1752/hour. Reserved nodes cut node costs up to 55% for committed terms.

What is the difference between ElastiCache and MemoryDB?

MemoryDB is a durable in-memory database — it can be your primary data store, with Multi-AZ durability surviving failures. ElastiCache is a cache: it makes the common case faster and expects its data to be recreatable from a real database. If losing the data is unacceptable, that's MemoryDB; if the data is disposable and speed is the point, that's ElastiCache.

What are ECPUs in ElastiCache serverless pricing?

ElastiCache Processing Units are the compute billing unit for serverless — one unit covers both vCPU time and data transferred. Simple GET/SET commands cost 1 ECPU per kilobyte transferred; commands that take more vCPU time (like sorted-set operations) bill on whichever dimension is higher. The ElastiCacheProcessingUnits CloudWatch metric shows your consumption.

Should I choose Valkey, Redis OSS, or Memcached?

Valkey is the recommended engine for new deployments — it's the open-source Redis fork, compatible with existing Redis OSS applications, 20% cheaper on nodes and 33% cheaper on serverless, and it carries the newest features (vector search from 8.2, full-text search and durability from 9.0). Choose Memcached only if you need its multi-threaded simplicity for pure object caching with no replication, backups, or complex data types.

When should I use serverless vs node-based ElastiCache?

Serverless for new or unpredictable workloads where you want the easiest start and automatic scaling — you name the cache and AWS handles capacity. Node-based when traffic is predictable, when you can forecast capacity to control costs, or when you need features serverless doesn't offer: data tiering, Global Datastore, or durability.

Can I disable TLS on ElastiCache Serverless?

No. Serverless requires TLS-capable clients, always — there is no setting to change it, and it also requires clients that support cluster mode. If your client does neither, your options are updating the client or using a node-based cluster where both are optional.

What do node type names like cache.r6g.large mean?

Family letter + generation number + size. The M family is the balanced line, the R family is memory-optimized, the generation number is the hardware refresh, and the size scales within the family. The "d" suffix (as in r6gd) marks data-tiering nodes that pair memory with a local SSD. The full per-node spec table lives on the Supported node types page.

Does ElastiCache encrypt data by default?

On serverless, yes — encryption at rest and in transit are always on, using either an AWS-managed or customer-managed KMS key. On node-based clusters, both are optional and you enable them at creation.

What happens if my ElastiCache goes down?

A healthy setup degrades, not dies — requests fall back to the database (cache misses), which is slower but works, and the cache refills as it serves hits again. Serverless replicates across three Availability Zones with automatic node replacement and a 99.99% SLA. If losing the cache takes your application down, the architecture treats the cache as a database, which is the actual bug.

Can ElastiCache be used as a primary database?

Not by design — it's a cache, and its contract is that data can be lost and recreated. The exception worth knowing: Valkey 9.0+ node-based clusters can enable durability through a Multi-AZ transactional log, blurring the line for specific workloads. For a genuine durable in-memory primary database, the service designed for that is Amazon MemoryDB.

How do I connect Python to ElastiCache?

Find the cache endpoint in the ElastiCache console, then use a Redis-compatible Python client pointed at that endpoint — with TLS enabled, since serverless requires it and node-based may have it on. A getting-started tutorial covers exactly this, including configuring Lambda to access ElastiCache in a VPC.

What is semantic caching in ElastiCache?

Caching that matches on meaning instead of exact strings. Queries are converted to vector embeddings, and a new query is compared against cached embeddings — if a similar-enough query exists, the cached response returns without invoking the LLM. Benchmarks show up to 86% LLM inference cost reduction and 88% latency reduction, running on Valkey's vector search (version 8.2+).

Does ElastiCache support backups?

Yes — automatic and manual backups for serverless caches (no performance impact) and for node-based Valkey/Redis OSS clusters (possible performance impact depending on reserved memory). Valkey and Redis OSS backups are cross-compatible and restorable into either serverless or node-based. Node-based Memcached does not support backup and restore.

Is there a free tier for ElastiCache?

It depends on when you signed up. Before July 15, 2025: 750 hours of cache.t3.micro free for 12 months (serverless excluded). After July 15, 2025: you choose a Free or Paid plan, get $100 in credits plus up to $100 more for activating foundational services, and upgrade to Paid once credits run out.

Revision note. Written September 2026. Pricing figures are US East (N. Virginia) rates and will drift as AWS revises them — check the live pricing page before committing to a number. If you have been squinting at a slow application and a hosting bill that keeps growing while the problem stays the same, the fix was probably never a bigger plan — it was a counter between your customers and your stockroom, and now you know what to ask for.