Managed Redis Options Compared

ElastiCache, Azure Managed Redis and Memorystore run Redis, and now on AWS and Google Cloud Valkey, as a service inside your account: multi-AZ replication, automatic failover, backups and patching, billed as node-hours. They are the right answer for a cache or session store that lives in the same cloud as the application. Their support tier covers the service; the memory growth, eviction storm or slow command that is actually causing your latency is usually yours to diagnose, which is why estates on managed caches still carry Redis-layer support.

Valkey is the Linux Foundation fork of Redis. “Managed Valkey”, or Valkey hosting, now comes in three forms: a hyperscaler's cache service, a multi-cloud database platform, or Valkey run for you in your own account. Details below are from each vendor's documentation, checked on 14 October 2026.

Pick the hyperscaler service when the cache lives in that cloud and a vendor support tier is enough. Pick a platform such as Aiven when you want managed Valkey that is not tied to one cloud. Pick Valkey operated in your account when the data cannot move, you need a version or persistence setting the services do not offer, or you want the Redis-layer incidents covered as well. If you are still on Redis and weighing the move, Redis to Valkey migration covers the cut-over, and Redis or Valkey: how to decide covers whether to move at all.

Microsoft now runs two Redis services, and only one of them has a future. Azure Cache for Redis is built on a fork of open-source Redis and is being retired. Azure Managed Redis runs Redis Enterprise software as a first-party Azure service, and it is the migration target Microsoft names for every Azure Cache for Redis tier.

Dates are from Microsoft's Azure Cache for Redis retirement FAQ. Existing instances keep running and keep receiving Microsoft's regular maintenance and patches until their tier's retirement date, and existing reservations are honoured until then. After it, remaining caches are disabled. What changes for applications, and the alternatives, are covered in Azure Cache for Redis retirement: dates and options.

What Azure Managed Redis adds. Active geo-replication; the Redis modules RediSearch, RedisJSON, RedisBloom and RedisTimeSeries, none of which the Basic, Standard or Premium tiers offer; zone redundancy by default; and Microsoft Entra ID authentication instead of access keys. Instead of choosing a tier and scale factor you pick a performance tier, Memory Optimized, Balanced, Compute Optimized or Flash Optimized, and a memory size. It is clustered by default, with a non-clustered option up to 25 GB. The Flash Optimized tier supports RedisJSON only among the modules.

What the move changes for your applications. Every client needs the new hostname and credentials. Because Azure Managed Redis is clustered by default, clients have to be configured for a clustered endpoint, and any code using multi-key commands across hash slots (MGET, transactions or Lua scripts over keys in different slots) has to be checked before cut-over. Microsoft also notes that some management operations, regions and SKU sizes are not yet available on Azure Managed Redis, so confirm your region and size before planning dates.

Valkey on Azure. Microsoft's retirement guidance points only to Azure Managed Redis. Teams that want Valkey, or want to stay on open-source Redis, run it themselves on AKS or virtual machines, which is the self-managed option below.

AceMQ supports Redis on both Azure services and self-managed on Azure, and runs the migration itself: client and cluster-mode checks, cross-slot command audit, data transfer and a rehearsed cut-over.

Redis Ltd's managed form of Redis Enterprise: active-active geo-replication, the enterprise modules, a management layer, and vendor support for all of it. If you need those features, this is the managed way to get them. If you do not, you are paying for a product when what you need is an engineer, which is the distinction the Redis Enterprise support post works through.

You run Redis on whatever infrastructure the estate already has, on-premises, VMware, Kubernetes or a cloud VM, and a senior engineer is on the other end of the contract when something breaks and alongside you for HA design, sizing and migration. It keeps version, persistence, data model and residency entirely yours, at a cost below any managed service, and it is the only option for estates that cannot move the data or run a build the platforms do not offer. Valkey is a first-class choice here.

Redis or Valkey stays in your account, on your VMs or Kubernetes, and a specialist takes over monitoring, patching, upgrades, failover testing, memory and capacity planning, and on-call. Nothing about data residency or licensing changes, and you choose Redis or Valkey on the merits rather than on what a cloud provider happens to offer. It costs more than a support contract, because it is engineer time with no infrastructure leverage, and it suits estates where nobody on the team wants to own Redis and the data cannot move to a hosted service.

A cloud's managed cache is the right Redis hosting for most caches and session stores. It stops fitting in a few recognisable situations, and each one has a different answer.

• You need a version, persistence setting or module the service does not offer. ElastiCache runs Redis OSS and Valkey engines on its supported versions, and the enterprise modules are outside it. Redis Cloud covers the modules; self-managed Redis or Valkey covers any version and setting.
• The Redis-layer incidents keep landing on your team. The cloud's support tier covers the service, not memory growth, eviction storms or slow commands. Independent Redis support covers those on the managed service as it stands, so this alone is not a reason to move.
• The data has to live outside that cloud. On-premises, VMware or a second cloud rules a single hyperscaler's cache out. Self-managed Redis or Valkey, supported or operated for you, is the ElastiCache alternative that keeps the data where it has to be.
• Your service is being retired. The Azure Cache for Redis tiers retire on 31 March 2027 and 30 September 2028. Microsoft names Azure Managed Redis as the replacement, and self-managed Redis or Valkey on AKS or virtual machines is the other route.

Leaving a managed cache means an RDB export and re-import plus client changes, and platform-specific authentication does not travel. Cost is not on the list because it depends on node size and count: model the node-hours on your own bill against infrastructure plus a support contract before deciding.

1. Is it a cache or session store in the same cloud as the app? If yes, that cloud's managed cache, with Redis-layer support if the workload is production-critical.
2. Do you need active-active geo-replication or the enterprise modules? If yes, Redis Cloud or self-hosted Redis Enterprise.
3. Is the estate on-premises, on VMware, or unable to move the data? If yes, self-managed with a support contract.
4. Is Valkey on the roadmap? Choose an option that covers it: ElastiCache or Memorystore's Valkey engines, or self-managed with a contract that names both builds.