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.

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 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.

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.