Redis stopped being simple open-source software in March 2024, and the fallout is still reshaping how engineering teams pick a managed cache. AWS ElastiCache, Azure Cache for Redis, and Google Cloud Memorystore all sat on top of the same underlying engine for a decade. Then Redis Inc. changed its license, the Linux Foundation forked the project into Valkey, and all three hyperscalers had to decide, publicly, which side they were on. That decision now shows up in pricing pages, node names, and retirement notices dated years out. This comparison breaks down what each service actually costs per hour, which engines they run today, how their SLAs differ, and which one fits a given workload heading into 2026.
None of this is a minor footnote for anyone running a session store, a rate limiter, a leaderboard, or a feature-flag cache in production. Picking the wrong engine today means either paying a Redis Inc. licensing premium indefinitely or planning a migration later once a team has already built dozens of integrations around a specific client library. The rest of this guide works through pricing, specs, benchmarks, compliance, and a step-by-step migration path so that decision can be made with real numbers instead of a vendor’s marketing page.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
The License War That Forced This Comparison to Exist
Until March 20, 2024, Redis shipped under the permissive BSD 3-Clause license, and every cloud vendor built a managed product on top of it without friction. That day, Redis Inc. announced that all versions from Redis 7.4 onward would move to a dual license: the Redis Source Available License v2 (RSALv2) or the Server Side Public License v1 (SSPLv1). Neither license is OSI-approved open source, and both restrict cloud providers from reselling the software as a competing service without a commercial deal with Redis Inc.
The cloud industry did not wait around. On March 28, 2024, exactly eight days later, the Linux Foundation announced it would form an independent project called Valkey, a hard fork of the last BSD-licensed Redis codebase. The founding backers named in the announcement and follow-up coverage included AWS, Google Cloud, Oracle, Ericsson, and Snap Inc., with Verizon, Percona, Alibaba Cloud, Aiven, and Heroku joining shortly after, according to the Linux Foundation’s own press release and a Percona statement on the fork. Every major cloud provider covered in this article now treats Valkey as its default recommended engine over Redis OSS for new deployments.
Redis Inc. then reversed part of its own decision. On May 1, 2025, the company published a post titled “Redis is now available under the AGPLv3 open source license,” confirming that starting with Redis 8, customers get an OSI-approved open-source option again alongside the existing RSALv2/SSPLv1 terms, according to the official Redis blog. That partial about-face did not undo the fork. Valkey now ships independently, with its own release cadence, and AWS ElastiCache and Google Cloud Memorystore both offer Valkey as a first-class, separately priced engine. Azure Cache for Redis has not added Valkey support as of this writing and remains Redis-only, based on Microsoft’s current product documentation.
The practical reason this mattered so much to cloud vendors comes down to what the RSAL and SSPL licenses actually restrict. Both licenses block anyone from offering the software as a hosted, commercial database-as-a-service without a separate agreement with Redis Inc., which is exactly the business AWS, Microsoft, and Google were already running. Rather than negotiate a new licensing arrangement for every future Redis release, the three hyperscalers backed an independent fork they could keep shipping under permanent open-source terms. That is why the Valkey backer list reads like a who’s-who of the same companies that build competing managed cache products, and why none of them waited to see whether Redis Inc. would eventually reverse course.
| Date | Event |
|---|---|
| March 20, 2024 | Redis Inc. announces Redis 7.4+ moves from BSD 3-Clause to dual RSALv2/SSPLv1 licensing |
| March 28, 2024 | Linux Foundation announces the Valkey fork, backed by AWS, Google Cloud, Oracle, Ericsson, and Snap Inc. |
| August 30, 2024 | Google Cloud launches Memorystore for Valkey in preview (Valkey 7.2 support) |
| May 1, 2025 | Redis Inc. relicenses Redis 8 under AGPLv3, restoring an OSI-approved open-source option |
| April 18, 2025 | Google Cloud announces general availability of Memorystore for Valkey with a 99.99% SLA |
| 2026 | AWS extends ElastiCache to Graviton4-based R8g, M8g, and C8gn node families for Valkey and Memcached |
AWS ElastiCache vs Azure Cache for Redis vs Google Memorystore: Full Specs
Here is how the three services stack up on the specs that actually change an architecture decision, not just marketing copy.
| Category | AWS ElastiCache | Azure Cache for Redis | Google Cloud Memorystore |
|---|---|---|---|
| Engines supported | Valkey, Redis OSS, Memcached | Redis OSS (Azure Managed Redis adds Redis Enterprise) | Valkey, Redis OSS |
| Valkey support | Yes, since 2024, priced separately from Redis OSS | No native Valkey support as of 2026 | Yes, GA since April 18, 2025 |
| Newest node/instance family | Graviton4-based R8g, M8g, C8gn (added 2026) | Enterprise E-series (via Azure Managed Redis) | Standard/Basic tiers on custom GCE-backed capacity |
| Serverless option | ElastiCache Serverless, GA since November 27, 2023 | No dedicated serverless tier; consumption is tier-based | No dedicated serverless tier; capacity-based scaling |
| Max instance/cluster size | Up to 500 shards per cluster on Valkey 7.2+/Redis OSS 5.0.6+ | Enterprise tier scales to hundreds of GB via clustering | Up to 300 GB per instance (Basic/Standard tiers) |
| Multi-AZ / HA SLA | 99.99% for Multi-AZ configurations | 99.9% for Standard/Premium tiers with replication | 99.99% (Memorystore for Valkey, per Google Cloud) |
| Lower-tier retirement notice | None announced | Basic/Standard/Premium retire Sept. 30, 2028; Enterprise retires March 30, 2027 | None announced |
| Free tier | 750 hrs/month of cache.t3.micro for 12 months (pre-July 2025 accounts) or credit-based for newer accounts | C0 Basic: 250 MB, 750 hrs/month for 12 months | No dedicated always-free tier |
| Cross-region replication | Global Datastore for Redis OSS/Valkey | Active geo-replication on Premium and Enterprise tiers | Cross-region replication on Memorystore for Valkey |
| Latency claims (vendor-published) | Sub-millisecond to low single-digit ms at high TPS | Sub-millisecond typical for cached reads | Sub-millisecond typical for cached reads |
| Encryption | In-transit TLS and at-rest, both optional/configurable | TLS by default, at-rest via Azure Storage encryption | In-transit and at-rest encryption available |
| Primary use in the provider’s own stack | Backs Amazon.com session and catalog caching at large scale | Backs Microsoft 365 and Azure-native app caching | Backs Google Cloud-native app and Vertex AI adjacent workloads |
AWS ElastiCache: Architecture, Node Generations, and Pricing
AWS ElastiCache is the oldest of the three services and the most aggressive about pushing customers toward Valkey. On its pricing page, AWS states that ElastiCache for Valkey costs roughly 20% less than equivalent Redis OSS nodes on the node-based tier and about 33% less on the serverless tier, a gap AWS built in deliberately to reward migration away from Redis Inc.’s licensed engine, according to the official ElastiCache pricing page.
For a mid-size cache.r7g.xlarge node in us-east-1, on-demand pricing runs about $0.437 an hour for Redis OSS versus roughly $0.350 an hour for Valkey, a difference of nearly nine cents an hour on identical hardware for running a different license. In 2026, AWS extended its newest node family further: a “What’s New” announcement confirmed Graviton4-based R8g, M8g, and C8gn node families now support Valkey and Memcached workloads, giving ElastiCache customers a newer silicon generation than either Azure or Google currently advertises for their equivalent services.
ElastiCache Serverless, generally available since November 27, 2023 according to the AWS What’s New announcement, lets teams skip node sizing entirely and pay per GB-hour and per-request compute unit. On the pricing page, Valkey Serverless starts as low as $6 a month for light workloads, which is the cheapest entry point of any tier across all three providers covered here.
Clustering and Throughput Ceilings
AWS documentation states that ElastiCache clusters running Valkey 7.2 or higher, or Redis OSS 5.0.6 through 7.1, can scale to a maximum of 500 shards per cluster, up from a 250-node ceiling on older engine versions. Default account limits still cap most clusters at 90 total nodes unless a customer requests a service quota increase. On the performance side, AWS’s own database engineering blog has published concrete numbers: an upgrade from Redis 7.0 to Redis 7.1 let one internal benchmark scale to 500 million requests per second per cluster while cutting P99 latency per node by more than 50%, to under 1 millisecond. A separate AWS blog on I/O multiplexing improvements measured P50 latency dropping from 0.55 ms to 0.44 ms, and P99 latency falling from 8.3 ms to 2.45 ms, a 71% reduction, on a cache.r6g.xlarge node.
Azure Cache for Redis: Tiers, Retirement Dates, and the Managed Redis Shift
Azure Cache for Redis is the outlier in this comparison because Microsoft is actively retiring it. According to Microsoft’s own documentation, Basic, Standard, and Premium tiers are scheduled to retire on September 30, 2028, and the Enterprise tier retires earlier, on March 30, 2027, both in response to the general availability of Azure Managed Redis (AMR), the service’s replacement. Any team building new infrastructure on Azure in 2026 needs to weigh whether to deploy on the legacy tiers or start directly on Azure Managed Redis, per the official retirement notice.
Basic vs Standard vs Premium vs Enterprise
Pricing on the legacy tiers varies noticeably by region and billing model, which is itself a point of friction against AWS and Google’s flatter published rate cards. Third-party pricing trackers put a Standard C1 instance (1 GB) at roughly $0.095 to $0.138 an hour, or about $70 to $100 a month, while a Premium P1 instance (6 GB) with clustering and persistence runs approximately $0.555 an hour, or $370 to $405 a month. Microsoft’s official Azure Cache for Redis pricing page is the authoritative source for exact current regional rates, since these estimates shift with currency and reserved-capacity discounts.
One documented figure holds steady across sources: Azure’s Standard and Premium tiers carry a 99.9% availability SLA when configured with two-node replication, a full order of magnitude weaker than the 99.99% AWS and Google both publish for their comparable multi-node configurations. For teams running payment processing, session stores, or anything where cache downtime cascades into user-facing errors, that SLA gap is not cosmetic. It is the difference between roughly 8.7 hours of allowed annual downtime and about 52 minutes.
Google Cloud Memorystore: Redis, Valkey, and the 300 GB Ceiling
Google Cloud runs two parallel Memorystore products: Memorystore for Redis, the original service, and Memorystore for Valkey, which entered preview on August 30, 2024 and reached general availability on April 18, 2025, according to Google’s GA announcement blog post. That blog post states the Valkey service ships with a 99.99% availability SLA plus Private Service Connect, multi-VPC access, cross-region replication, and built-in persistence, features Google positions as parity with, or ahead of, its own legacy Redis offering.
Memorystore for Redis prices by capacity tier rather than by instance type. In us-central1, the Standard tier runs $0.064 per GiB-hour for the smallest M1 tier (1 to 4 GiB), stepping down to $0.054 for M2 (5 to 10 GiB), $0.046 for M3 (11 to 35 GiB), $0.035 for M4 (36 to 100 GiB), and $0.030 for M5 (101 to 300 GiB), based on Google’s official Memorystore pricing documentation. That per-GiB model rewards larger, denser instances more directly than AWS or Azure’s flat-rate node pricing, but it also caps out: Memorystore for Redis tops out at a 300 GB primary instance size across both Basic and Standard tiers, a hard ceiling neither AWS nor Azure enforces in the same way.
Monthly Pricing Comparison: 1 GB, 10 GB, and Serverless Entry Points
Converting hourly and per-GiB rates into monthly numbers makes the real spread easier to see. The table below uses on-demand, non-reserved, single-region pricing, since reserved and multi-year discounts vary too much by contract to compare fairly.
| Tier / Scenario | AWS ElastiCache | Azure Cache for Redis | Google Cloud Memorystore |
|---|---|---|---|
| Cheapest paid entry point | Valkey Serverless from $6/month | Basic C0 (250 MB) from ~$16/month after free tier | Standard M1 (1 GiB) at $0.064/GiB-hr, ~$47/month |
| Free tier | 750 hrs/month cache.t3.micro, 12 months (legacy accounts) | C0 Basic, 250 MB, 750 hrs/month, 12 months | No dedicated free tier |
| ~1 GB mid-tier node/instance, on-demand | cache.r7g.xlarge Valkey: ~$0.350/hr (~$255/month) | Standard C1 (1 GB): ~$0.095-$0.138/hr (~$70-$100/month) | Standard M1 (1-4 GiB): $0.064/GiB-hr |
| ~6 GB comparable tier | cache.r7g.xlarge Redis OSS: ~$0.437/hr (~$319/month) | Premium P1 (6 GB): ~$0.555/hr (~$370-$405/month) | Standard M2 (5-10 GiB): $0.054/GiB-hr |
| Large-scale tier (100 GB+) | Cluster mode, priced per shard/node | Enterprise tier via Azure Managed Redis, custom quote | Standard M5 (101-300 GiB): $0.030/GiB-hr |
| Billing model | Per-node-hour or per-GB-hour + ECPU (serverless) | Per-instance-hour by tier and size | Per-GiB-hour by capacity tier |
The pattern that falls out of this table: AWS wins on the cheapest possible entry point through ElastiCache Serverless, Google wins on pure per-GB cost at scale because of its stepped capacity pricing, and Azure sits in the middle on raw dollars but carries the added cost of migrating off retiring tiers within the next two to three years regardless of price.
Benchmark Data: Latency and Throughput Across the Three Services
Vendor-published benchmarks are not independent, but they are the most granular latency data publicly available for these three services, and all three converge on the same broad claim: sub-millisecond reads under normal load, single-digit-millisecond reads under heavy write pressure.
- AWS’s ElastiCache for Valkey durability engineering blog reports read latency staying under 300 microseconds at 50,000 transactions per second, and sub-millisecond (879 microseconds) at 100,000 TPS, with write latency in the single-digit-millisecond range under the same load.
- A separate AWS database blog benchmarking enhanced search on a cache.r7g.2xlarge Valkey cluster measured P50 latencies between 0.135 and 0.175 milliseconds and P99 latencies between 0.199 and 0.295 milliseconds across different query types.
- An AWS Partner Network blog pairing ElastiCache for Redis with Confluent Cloud Kafka in a logistics inventory system recorded ElastiCache read operations completing in 0.352 to 0.713 milliseconds for a 1 KB JSON payload, about 47 times faster than the 20 to 30 millisecond Kafka consumption latency it replaced.
- Google Cloud’s Memorystore for Valkey GA announcement cites the same 99.99% availability SLA as AWS’s Multi-AZ ElastiCache configuration, positioning the two services as functionally tied on uptime commitments even though their pricing models differ sharply.
None of the three vendors has published a head-to-head, apples-to-apples benchmark against the other two clouds’ caching services, which is typical for this category. Independent, reproducible cross-cloud latency testing for managed Redis/Valkey services remains thin in the public record as of this writing, so treat any specific millisecond figure above as a best-case number measured by the vendor on its own infrastructure, not a guaranteed result on a customer’s specific workload.
Why Vendor Benchmarks Diverge From Real-World Numbers
Every microsecond figure published by AWS, Azure, or Google comes from a controlled test: a specific node size, a specific payload size, same-region client and server, and often a synthetic key distribution that avoids hot-key contention. Production traffic rarely looks like that. Real applications mix small session-token reads with larger serialized-object writes, run across availability zones for redundancy (which adds round-trip latency), and hit uneven key access patterns that create hot shards. A workload that AWS benchmarks at 300 microseconds in a lab can easily land in the low single-digit milliseconds once it is serving live traffic across three availability zones with a mixed read/write ratio. None of that makes the vendor numbers wrong, it just means they represent a ceiling on performance, not a guarantee, and the same caveat applies equally to Azure and Google Cloud’s published figures.
High Availability, Failover, and SLA Fine Print
The SLA numbers matter more than they look on paper because they compound with retirement timelines. AWS publishes 99.99% availability for Multi-AZ ElastiCache configurations, with a maximum allowed downtime of 4 minutes and 21 seconds per month, according to the official ElastiCache SLA document. Google Cloud matches that 99.99% figure for Memorystore for Valkey. Azure’s Standard and Premium tiers commit to 99.9%, and that gap becomes more relevant given that those exact tiers are the ones scheduled for retirement by 2027 and 2028.
Cross-region resilience differs by design philosophy rather than by raw numbers. AWS offers Global Datastore for cross-region replication on both Redis OSS and Valkey. Azure’s Premium and Enterprise tiers support active geo-replication, letting a cache span multiple Azure regions with active-active writes on Enterprise. Google’s Memorystore for Valkey added cross-region replication as one of its headline GA features, a capability the older Memorystore for Redis service historically lacked in the same form.
Regional Availability and Data Residency
All three services ride on top of their parent cloud’s global region footprint, so availability tracks each provider’s overall region count rather than any cache-specific limitation. AWS ElastiCache is available in effectively every AWS commercial region, including AWS’s GovCloud partitions for US federal workloads. Azure Cache for Redis follows the same pattern across Azure’s commercial and government clouds, though newer Enterprise-tier capabilities sometimes lag behind on rollout to smaller regions by a few months after a global announcement. Google Cloud Memorystore is generally available across Google Cloud’s standard region list, with Memorystore for Valkey’s newer feature set, including cross-region replication, rolling out to additional regions incrementally rather than all at once at GA.
For teams with strict data residency requirements, such as EU-only processing under GDPR or data localization rules in specific countries, the practical question is not whether the caching service exists in-region, since all three vendors support the major EU, UK, and APAC regions, but whether cross-region replication or Global Datastore features are enabled by default. Both AWS Global Datastore and Azure active geo-replication are opt-in, meaning data does not leave a specified region unless a team explicitly configures cross-region replication, which is the correct default for anyone under strict residency rules.
Compliance and Security Certifications
Enterprise buyers evaluating a managed cache almost always need to check a compliance box before signing off, and here the three services land in roughly the same place because they inherit certifications from their parent cloud platform rather than certifying the caching service in isolation. AWS ElastiCache falls under AWS’s broader SOC 1, SOC 2, SOC 3, PCI DSS, ISO 27001, and HIPAA-eligible service umbrella, meaning it can be used in HIPAA workloads when configured according to AWS’s published HIPAA reference architecture. Azure Cache for Redis inherits the same category of certifications through the Azure compliance program, including HIPAA/HITECH, PCI DSS, and FedRAMP for government-facing deployments through Azure Government. Google Cloud Memorystore sits under Google Cloud’s compliance umbrella as well, covering SOC 2, ISO 27001, PCI DSS, and HIPAA when configured per Google’s shared-responsibility guidance.
The differentiator in practice is encryption defaults, not certification lists. Azure enables TLS in transit by default on new cache instances, while both AWS and Google treat in-transit and at-rest encryption as configurable options that need to be explicitly turned on during provisioning. Teams in regulated industries should treat that as a checklist item during initial setup on any of the three platforms rather than assuming encryption is on by default everywhere.
Real-World Adoption: Who Is Actually Running What
Named case studies specific to a single cloud’s managed cache are rare, since most companies do not publish their exact caching bill. What is well documented is which organizations backed the Valkey fork itself, which functions as a public signal of where each company’s infrastructure strategy is heading.
- Snap Inc. was named as one of the original founding contributors to the Valkey project when the Linux Foundation announced it in March 2024, alongside AWS, Google Cloud, Oracle, and Ericsson.
- Verizon joined as an early Valkey supporter shortly after the initial announcement, according to Linux Foundation and industry coverage of the fork’s momentum.
- Percona, Alibaba Cloud, and Heroku all added their names to the Valkey backer list within the fork’s first year, a roster the Valkey project itself describes as evidence the fork grew from an emergency response into an established open source project in its one-year retrospective blog post.
- On AWS’s own ElastiCache customer page, an unnamed enterprise customer is quoted describing a migration from Redis OSS to Valkey that delivered sub-millisecond latency at a lower cost, while another unnamed customer reports maintaining P99 latency below 5 milliseconds and 99.99% availability through a traffic surge.
- Google Cloud markets Memorystore for Valkey directly against workloads that need vector similarity search alongside caching, positioning it for retrieval-augmented generation pipelines that already sit on Google Cloud’s AI stack, a use case Google’s product documentation calls out explicitly as a 2025-2026 growth driver for the service.
A Worked Cost Example: 10 GB Session Cache at Moderate Traffic
Numbers are easier to compare with a concrete scenario. Take a mid-size SaaS application that needs roughly 10 GB of cache memory for session tokens and API rate-limit counters, running with high availability across two nodes. On AWS ElastiCache, that maps to a cache.r7g.xlarge Valkey primary plus a replica, at roughly $0.350/hour each, for a combined on-demand cost near $511 a month before data transfer. On Azure, the same footprint likely lands on a Premium P1 tier with clustering for redundancy, priced around $370 to $405 a month per node, so a highly available pair runs somewhere between $740 and $810 a month. On Google Cloud Memorystore, a 10 GB instance falls into the M2 capacity tier at $0.054 per GiB-hour, which works out to roughly $394 a month for a single highly available instance, since Google’s HA pricing is built into the per-GiB rate rather than billed as a separate replica node.
That example is illustrative, not a quote, since actual pricing shifts with region, reserved-capacity discounts, and data transfer volume. It does show the general shape of the market, though: Google’s per-GiB model tends to compress the cost of redundancy into the base rate, AWS separates primary and replica costs but offers the newest hardware and the lowest possible floor via serverless, and Azure’s node-based Premium pricing carries the highest sticker price of the three for this specific 10 GB, HA-enabled scenario.
5 Use Cases and Which Service Fits Each One
The right choice depends far more on existing cloud commitment and workload shape than on any single benchmark number. These five scenarios cover most of the decisions teams face in 2026.
- Real-time bidding, fraud scoring, or trading systems needing microsecond-level reads: AWS ElastiCache for Valkey on a Graviton4 R8g node with cluster mode enabled, since AWS has the most granular published latency benchmarks under high TPS load of the three providers.
- .NET-heavy enterprise shops already standardized on Azure: Azure Managed Redis, deployed fresh rather than on a legacy Basic/Standard/Premium tier, given the 2027-2028 retirement dates on those older tiers.
- RAG pipelines or vector-search-adjacent AI workloads on Google Cloud: Memorystore for Valkey, which Google explicitly built with vector similarity search and Vertex AI-adjacent integration in mind.
- Cost-sensitive startups with unpredictable, spiky traffic: ElastiCache Serverless, since its $6-a-month floor and per-request billing model beats provisioning a fixed node on either Azure or Google for low, unpredictable load.
- Regulated industries needing the strongest uptime guarantee on paper: AWS ElastiCache Multi-AZ or Google Memorystore for Valkey, both at 99.99% SLA, ahead of Azure’s 99.9% commitment on its Standard and Premium tiers.
Migration Guide: Moving Between ElastiCache, Azure Cache, and Memorystore
Because Valkey and Redis OSS share the same wire protocol and command set through the versions covered here, migrating a cache between clouds is mostly an operations problem, not a rewrite. The steps below apply whether the move is AWS-to-Azure, Azure-to-Google, or simply Redis OSS-to-Valkey within the same provider.
Step-by-Step Migration Checklist
- Audit which Redis commands, modules, and client libraries the application actually uses; Valkey diverges from Redis Enterprise-specific modules like RedisJSON and RediSearch, so module-dependent code needs a compatibility check first.
- Confirm target engine version support: ElastiCache requires Valkey 7.2+ or Redis OSS 5.0.6-7.1 for the 500-shard ceiling; Memorystore for Valkey requires checking Google’s current supported-versions page before provisioning.
- Stand up the destination cluster sized to match current memory footprint plus 20-30% headroom, since eviction behavior differs slightly between Redis OSS and Valkey under memory pressure.
- Use built-in replication (RDB/AOF export, or a tool like RIOT or redis-shake) to seed the new cluster while the old one keeps serving live traffic.
- Run both caches in parallel with dual writes for a soak period of at least a week for any workload with weekly seasonality (batch jobs, weekend traffic patterns, month-end billing runs).
- Cut over reads first behind a feature flag, monitor P99 latency and error rate for 24-48 hours, then cut over writes.
- Decommission the old cluster only after confirming TTLs on the new cluster have fully cycled at least once, so no stale cache entries silently persist past their intended lifetime.
A simple compatibility check before migrating looks like this on the command line, run against both the source and destination endpoints to confirm command support before moving real traffic:
redis-cli -h source-endpoint.cache.amazonaws.com -p 6379 INFO server | grep redis_version
redis-cli -h dest-endpoint.redis.cache.windows.net -p 6380 --tls INFO server | grep redis_version
redis-cli -h dest-memorystore-ip -p 6379 COMMAND COUNTFor teams provisioning infrastructure as code, a minimal Terraform resource block for standing up an ElastiCache Valkey replication group looks like this:
resource "aws_elasticache_replication_group" "cache" {
replication_group_id = "prod-valkey-cache"
description = "Production Valkey cluster"
engine = "valkey"
engine_version = "7.2"
node_type = "cache.r7g.xlarge"
num_node_groups = 2
replicas_per_node_group = 1
automatic_failover_enabled = true
multi_az_enabled = true
}Pros and Cons of Each Managed Caching Service
AWS ElastiCache pros: newest silicon (Graviton4 R8g/M8g/C8gn), the cheapest serverless entry point in the category, the largest published body of vendor latency benchmarks, and a 500-shard cluster ceiling for extreme scale. AWS ElastiCache cons: pricing is node-hour based and can get complicated once reserved instances, data transfer, and snapshot storage enter the bill; Memcached and Redis OSS pricing still trails Valkey pricing by design, which pressures teams into an engine migration they may not have planned.
Azure Cache for Redis pros: tight integration with Entra ID, VNet, and the rest of the Azure control plane, plus active geo-replication on Enterprise. Azure Cache for Redis cons: no native Valkey support, a materially weaker 99.9% SLA on its most common tiers, and a hard retirement date forcing every current customer onto Azure Managed Redis by 2027 or 2028 regardless of preference.
Google Cloud Memorystore pros: the cleanest per-GiB pricing model for predictable capacity planning, a matching 99.99% SLA on Memorystore for Valkey, and the tightest integration with Google’s AI/vector-search stack. Google Cloud Memorystore cons: a hard 300 GB ceiling per instance on the Redis tier, no dedicated serverless product, and no free tier at all, unlike its two competitors.
The Verdict: Which One to Choose in 2026
There is no single winner across every dimension, but the data points to clear defaults. Teams that are cloud-agnostic and purely optimizing for latency and price should default to AWS ElastiCache for Valkey: it has the newest node hardware, the lowest serverless floor at $6 a month, and the deepest published benchmark record, including sub-millisecond reads at 100,000 TPS. Teams already committed to Azure should skip the legacy Basic/Standard/Premium tiers entirely and provision on Azure Managed Redis from day one, since the older tiers carry both a weaker 99.9% SLA and a fixed expiration date. Teams building AI-adjacent workloads on Google Cloud, especially anything touching vector search or Vertex AI, get the most direct product fit from Memorystore for Valkey, which matches AWS on the 99.99% SLA and ships cross-region replication as a core GA feature rather than an add-on.
The one universal recommendation: default to Valkey over Redis OSS wherever it is available. It is cheaper on AWS by design, it carries the same 99.99% SLA as Redis OSS on Google Cloud, and it is no longer a risky bet now that Snap, Verizon, Oracle, Ericsson, Percona, Alibaba Cloud, and both AWS and Google Cloud themselves have committed engineering resources to it since March 2024.
Frequently Asked Questions
Is AWS ElastiCache more expensive than Azure Cache for Redis?
On a like-for-like mid-size node, AWS ElastiCache for Redis OSS (about $0.437/hour on a cache.r7g.xlarge) runs higher than Azure’s Standard C1 tier (roughly $0.095-$0.138/hour), but that Azure tier caps out at 1 GB, while the AWS node handles over 26 GB. AWS ElastiCache for Valkey narrows the per-hour gap to about $0.350, and AWS’s serverless option can undercut both starting at $6 a month for light workloads.
Does Azure Cache for Redis support Valkey?
No. As of 2026, Microsoft’s Azure Cache for Redis and its successor, Azure Managed Redis, remain Redis-only products. Both AWS ElastiCache and Google Cloud Memorystore added native Valkey support in 2024 and 2025 respectively.
Why is Azure retiring Azure Cache for Redis?
Microsoft is consolidating its caching product line into Azure Managed Redis (AMR). Per Microsoft’s own documentation, Basic, Standard, and Premium tiers retire on September 30, 2028, and the Enterprise tier retires earlier, on March 30, 2027, with AMR positioned as the direct replacement for all four tiers.
What is the maximum size of a Google Cloud Memorystore instance?
Memorystore for Redis, on both Basic and Standard tiers, caps out at 300 GB per primary instance according to Google Cloud’s product documentation. Teams needing more capacity typically shard across multiple instances at the application layer or evaluate Memorystore for Valkey’s cluster mode.
Is Valkey a drop-in replacement for Redis?
For the vast majority of applications using standard Redis commands and data structures, yes. Valkey forked from the last BSD-licensed Redis codebase and maintains protocol and command compatibility. Applications relying on Redis Enterprise-specific modules such as RedisJSON or RediSearch need a separate compatibility check, since those modules are not part of the Valkey core project.
Which managed cache has the best uptime SLA?
AWS ElastiCache Multi-AZ and Google Cloud Memorystore for Valkey both publish a 99.99% availability SLA. Azure Cache for Redis’s Standard and Premium tiers publish 99.9%, roughly ten times more allowed downtime per year than the 99.99% tier offered by its two competitors.
Do any of these three services offer a free tier?
AWS ElastiCache and Azure Cache for Redis both offer time-limited free usage: AWS provides 750 hours a month of a cache.t3.micro node for 12 months on eligible accounts, and Azure’s C0 Basic tier offers 250 MB and 750 hours a month for 12 months. Google Cloud Memorystore has no dedicated always-free tier as of 2026.
Can I run ElastiCache, Azure Cache, and Memorystore side by side in a multi-cloud setup?
Technically yes, since all three speak the same Redis/Valkey wire protocol, but cross-cloud replication between them is not natively supported by any of the three vendors. Teams running true multi-cloud caching typically run independent caches per region/cloud with application-level cache invalidation, rather than trying to replicate a single cache cluster across providers.
