What happens when your caching layer quietly becomes the most important database in your stack? It happens more often than teams admit. A session store grows into a primary data path. A rate limiter becomes the thing that keeps your API from falling over. And suddenly the managed cache you picked in an afternoon architecture meeting is load-bearing infrastructure you cannot easily move. (In-memory database)
That is why the three big managed caching services deserve a closer look than a pricing table. AWS ElastiCache, Azure Managed Redis (the successor to Azure Cache for Redis), and Google Cloud Memorystore look similar from a distance. Up close, they make different bets about how memory, persistence, and scaling should work. Those bets shape how your application behaves at 3 a.m. when traffic spikes.
Why the managed cache decision is harder than it used to be
For years, the choice was simple: pick the engine, pick a node size, done. That era is over. Between 2023 and 2024, all three providers changed their offerings in ways that break the old mental model.
AWS added a serverless option to ElastiCache and introduced Valkey as a supported engine. Azure rebranded its cache service around Redis Enterprise software. Google brought Memorystore for Redis Cluster to general availability. Meanwhile, the licensing shakeup around Redis in 2024 pushed the whole ecosystem toward forks and vendor-specific builds.
The practical result: two teams can both say “we use a managed Redis-compatible cache” and be running architectures that behave nothing alike. Understanding the differences starts with knowing what each service actually is.
The three services, stripped to essentials
| Service | Engines | Scaling model | Notable twist |
|---|---|---|---|
| AWS ElastiCache | Valkey, Redis OSS, Memcached | Node-based clusters plus serverless | Serverless mode removes node sizing entirely |
| Azure Managed Redis | Redis Enterprise software | Tier-based, including a Flash tier on NVMe | Built on Redis Enterprise, not Redis OSS |
| Google Cloud Memorystore | Redis and Memcached, plus Redis Cluster | Basic, Standard (HA), and cluster mode | Cluster mode adds sharding across nodes |
Each row hides a decision. The engine column matters because Valkey and Redis OSS are no longer the same product line, even though they share a code ancestry. The scaling column matters because serverless and node-based caching fail in different ways under pressure. The twist column is where most surprises live.
Engine choice: Valkey, Redis OSS, and Redis Enterprise are not interchangeable
This is the first architecture decision, and it is easy to get wrong.
AWS announced ElastiCache support for Valkey in October 2024, positioning it as a drop-in replacement for Redis OSS 7.2. Valkey itself is a Linux Foundation project, forked from Redis OSS in March 2024 after Redis Inc. moved to a dual license. That licensing history explains why the ecosystem split, and it explains why AWS leans on Valkey while Azure leans on Redis Enterprise. (Redis official documentation)
For architects, the question is not “which is faster.” It is “which build will still receive patches and features in three years, and who controls that roadmap?” A team that assumed engine compatibility meant behavioral compatibility has learned the hard way that persistence defaults, eviction policies, and command support can differ by product and tier, not just by engine version.
The practical tip: before migrating, test your specific commands against the target build. Modules and newer commands are where incompatibilities surface first. If your application depends on a Redis module, confirm it exists in your target offering before you commit.
Scaling: serverless versus nodes versus clusters
The second decision is how the cache grows. Each provider now offers at least two paths, and the paths behave differently.
AWS gives you node-based clusters and a serverless option. Serverless removes the “pick a node size” step and scales capacity automatically, which is genuinely useful for spiky workloads. The tradeoff is less control over instance families and placement. Teams that need specific instance types for cost or compliance reasons often stay on nodes.
Azure organizes capacity into tiers, including a Flash Optimized tier that uses NVMe storage to lower cost per gigabyte. That tier is interesting for large, cold-ish datasets where latency tolerance is a little wider. It is not a substitute for memory when every microsecond counts.
Google splits Memorystore into Basic, Standard, and Cluster. Basic is a single node with no replication. Standard adds a replica for high availability. Cluster mode shards data across nodes, which changes how your client connects and how keys distribute.
Here is the mistake people make: they pick a scaling model based on the demo, not the failure mode. Serverless handles traffic spikes gracefully but can surprise you on cold-start latency. Node-based clusters give predictable performance but require you to plan shard counts. Cluster mode distributes load but complicates multi-key operations.
A useful exercise is to map your workload to one of three shapes: steady, spiky, or huge. Steady workloads fit node-based setups well. Spiky workloads benefit from serverless. Huge datasets that exceed a single node push you toward cluster mode or a tiered offering. If you are running across several providers at once, tracking these shapes consistently is easier with a shared approach to multi cloud metrics track across aws azure google cloud rather than three separate dashboards.
Persistence, eviction, and the defaults that bite
The third decision is the one most teams skip: what happens to data when memory fills up or a node restarts.
Persistence semantics differ by product and tier, not just by engine. Whether snapshots are available, how often they run, and what the default eviction policy is can all change between offerings. A cache used purely for acceleration can tolerate data loss. A cache holding session state or job queues cannot.
The practical rule: decide explicitly whether your cache is disposable. If it is, set eviction policies that favor keeping hot keys and accept loss. If it is not, you need persistence configured and tested, plus a plan for what happens during a failover. Many outages traced to “the cache went down” are really outages where the cache was treated as disposable but the application treated it as durable.
Test the restart path before you need it. Evict a node deliberately in staging and watch what your application does. The behavior you observe will tell you more than any parameter reference.
Cost architecture: where the bills actually come from
Cost is an architecture decision, not an accounting one. The three services bill differently, and the differences compound at scale.
Node-based pricing rewards predictable, steady usage. Serverless pricing rewards elasticity but can climb quickly with sustained high throughput. Flash and tiered offerings trade latency for cost per gigabyte. Cross-region replication adds bandwidth charges that rarely appear in initial estimates.
The common overspend pattern is running oversized nodes because nobody revisited the sizing after launch. A second pattern is paying for high availability on caches that do not need it. A disciplined review of cloud cost management stop overspending aws azure google cloud usually surfaces both within a week.
For GPU-adjacent workloads, caching decisions interact with compute pricing in ways that are easy to miss. Teams comparing accelerators should look at gpu pricing comparisons alongside cache costs, because the cache tier often determines how much compute you actually need.
Multi-cloud reality: what changes when you run two or three
Most large organizations end up with more than one provider, whether by design or by acquisition. That changes the caching conversation.
Running the same cache product everywhere is rarely possible. What you can standardize is the interface and the operational model. A framework that abstracts the cache client, handles connection pooling, and normalizes failure behavior pays for itself quickly. Teams building this often start from a multi cloud framework run workloads across aws azure google cloud and adapt it to their own topology.
The biggest practical gap in multi-cloud caching is feature parity by region. A tier available in one region may be missing in another, and no single comparison page captures this. Verify per region before you commit an architecture to a specific tier.
If your team is also weighing broader platform choices, a side-by-side of aws vs azure vs google cloud 2026 helps frame where each provider’s caching strengths fit into a larger stack.
A decision sequence that actually works
Rather than starting with the provider, start with the workload. This sequence tends to produce better outcomes:
- Classify the cache as disposable or durable. This single answer eliminates half the options.
- Estimate the working set size and growth rate. If it exceeds a single node comfortably, plan for cluster mode or tiering.
- Characterize traffic shape as steady, spiky, or bursty. This points toward nodes or serverless.
- Confirm engine compatibility for every command and module you depend on.
- Check regional availability for your chosen tier.
- Model cost at your expected throughput, not at launch volume.
- Test failover and eviction behavior in staging before production.
Steps four through seven are where most teams cut corners, and they are exactly the steps that prevent nasty surprises.
Common mistakes worth avoiding
A few patterns show up again and again in post-incident reviews.
Treating engine compatibility as behavioral compatibility ranks near the top. So does choosing a tier based on a blog post rather than the provider’s current documentation. Another frequent error is ignoring connection limits, which cluster mode and serverless handle differently.
There is also a subtler mistake: letting the cache become a hidden dependency with no owner. When nobody owns the cache architecture, defaults accumulate, and defaults are rarely what you would have chosen deliberately.
Conclusion
The choice between AWS ElastiCache, Azure Managed Redis, and Google Cloud Memorystore is less about which service is best and more about which set of tradeoffs fits your workload. Engine lineage, scaling model, persistence semantics, and cost shape all differ, and each difference maps to a real operational consequence.
The teams that get this right do three things. They classify their cache as disposable or durable before choosing a product. They verify engine and tier behavior against current documentation rather than assumptions. And they test failure modes in staging, where surprises are cheap. Do those three things and the provider choice becomes a detail rather than a gamble.
FAQ
Is Azure Cache for Redis the same as Azure Managed Redis?
No. Azure Managed Redis is the newer offering built on Redis Enterprise software, announced in late 2024. Azure Cache for Redis is the older service, and migration guidance exists for teams moving between them. Confirm the current retirement timeline for older tiers before planning a migration.
Does ElastiCache still support Redis OSS?
Yes. ElastiCache supports Valkey, Redis OSS, and Memcached. Valkey was added in October 2024 as a drop-in option for Redis OSS 7.2. Which engine you should choose depends on module dependencies and your appetite for the newer build.
What is the difference between Memorystore Basic and Standard?
Basic runs on a single node with no replication. Standard adds a replica for high availability, so a node failure does not take the cache offline. Cluster mode is a separate option that shards data across multiple nodes.
Should I use serverless caching or provisioned nodes?
Serverless suits spiky or unpredictable traffic because it scales without node sizing. Provisioned nodes suit steady workloads where predictable performance and instance control matter. Many teams run both for different workloads.
How do I know if my cache needs persistence?
Ask whether losing the cache would break the application. If the cache only accelerates reads, it is disposable and persistence is optional. If it holds sessions, queues, or counters, configure persistence and test failover.
Why did the Redis licensing change matter for managed caches?
Redis Inc. moved to a dual license in March 2024, which prompted forks including Valkey under the Linux Foundation. That split is why AWS promotes Valkey and Azure builds on Redis Enterprise. It is the backdrop for most engine decisions today.
