Managed Redis pricing and providers compared (2026)

A single 12 to 13 GB managed Redis or Valkey node costs $1,535 to $1,918 a year at list price on AWS, Google Cloud and Azure, which is $117 to $158 per GB a year, and Redis Cloud Pro starts at $2,400 a year. Managed Redis is billed by node, plan or usage, so the table lists each vendor’s published price in its own unit and converts hourly prices to a year at 8,760 hours, which is our arithmetic. The four node-priced rows are single nodes with no replica, and the per-GB column divides the yearly figure by the size the vendor states (GiB on AWS, GB elsewhere). Prices exclude replicas, storage, backups, data transfer and tax, and they vary by region. The availability column is each vendor’s own published figure, and it applies to replicated or multi-zone setups, not to a single node. Since our 28 October read the node prices are unchanged, and Aiven now also lists a free plan and a $15 a month Developer plan.

The cloud-native node prices land within about 25% of each other at 12 to 13 GB, so for a cache already in one cloud, price rarely decides it. What moves the bill is a replica in each availability zone, data transfer between zones, and whether you pick the Valkey engine on AWS, where the node is 20% cheaper. Redis Cloud and Upstash price by plan and usage, which suits small or spiky workloads and gets expensive per gigabyte at scale. Support is a separate line: the cloud’s support plan covers the service, not the Redis-layer incident.

The hyperscaler caches publish list prices, so you can price them yourself in the cloud’s calculator; Redis Software, Redis Cloud annual plans and any provider that operates Redis for you quote from six numbers. Send the same six to every provider and the quotes become comparable.

AceMQ runs Redis and Valkey for you, on your own infrastructure or hosted on ours, and quotes it per scope rather than from a list. Send those six numbers with a request a managed Redis quote and we reply within 1 hour; the service is described under managed Redis and Valkey from AceMQ.

No provider wins every row, and the right answer depends on where the application runs. This table picks one by situation.

Managed Redis is used as a cache, a session store, a message queue and, increasingly, a primary database for real-time and AI applications such as semantic caching and agent memory, and the use case decides what you should pay for. A cache needs RAM, low latency and an eviction policy. A session store needs high availability and automatic failover. An AI workload with vector search needs memory sized for the index and a tier that includes the modules. Scaling differs by service: node-based services scale by changing node size or adding shards, serverless plans scale with use, and every resize or migration changes the endpoint or authentication your clients use, for example Microsoft Entra ID on Azure. Data persistence options also differ, so decide whether the workload can lose its data before you turn persistence off. The production readiness checklist covers what stays your job on a managed service, and Redis for AI in production covers the AI case.

None of the managed services run inside your Kubernetes cluster, so a team that wants Redis or Valkey on Kubernetes either connects its pods to a hosted service or runs the engine itself with an operator or Helm chart. Statuses below come from each project’s GitHub releases and documentation, read on 28 October 2026.

An operator removes the manual work of failover, resharding and pod replacement, but it does not choose your maxmemory, your eviction policy or your container memory limit, which should sit well below the limit so the kernel does not kill the pod. The full walk-through, including storage and the pitfalls we see, is in Redis on Kubernetes.

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, on your own infrastructure or on AceMQ’s. 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 for you 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.

A specialist takes over monitoring, patching, upgrades, failover testing, memory and capacity planning, and on-call, in one of two places. On your infrastructure, Redis or Valkey stays in your account, on your VMs or Kubernetes, and nothing about data residency or licensing changes. Hosted on AceMQ’s infrastructure, you get endpoints and no cloud account, cluster or on-call rota to run, and the region and residency are scoped in the quote. Either way 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, and it suits estates where nobody on the team wants to own Redis.

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.

Check five things in writing before you pick a provider: how it scales, how it fails over, how it keeps data, how you authenticate to it, and which Redis version it runs. The questions below apply to any managed Redis service, and the provider's own documentation or contract should answer each one. A managed service keeps data in memory to improve performance for a database-backed application, so the use cases that matter most are caching, session storage and queues, and the cost of getting one wrong is a cold cache or lost sessions.

1. Scalability. Can you scale up or out without downtime, and how large a dataset can one instance or cluster store? Large datasets change both the price tier and the failover time.
2. Failover and disaster recovery. What is the uptime SLA, how long does a failover take, and is a second region covered? Ask for the failover time as a number in the contract, not as a promise of automatic failover.
3. Data persistence and backup. Is data persistence on by default, how often are backups taken, and can you restore into a test instance?
4. Access and authentication. How do you configure authentication and TLS, and is there a CLI or private endpoint for developer access?
5. Version and features. Which Redis version does it run, how soon does it offer the latest Redis release, and are the modules you need included? Check this before you migrate an application that depends on a newer command.

To get started with managed Redis, create one small instance in the same cloud region as the application, configure authentication and TLS, point a test copy of the application at it, run a failover on purpose and time it, then set alerts on memory and evictions before production traffic moves over. If you use Azure, the migration question has its own answer in the Azure Cache for Redis section above.

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.

We compared three ways to run Redis or Valkey, the cloud managed caches (ElastiCache, Azure Managed Redis and Memorystore), Redis Cloud, and self-managed Redis or Valkey with a support contract, on nine criteria: where the data lives, engine and version, enterprise features, who answers an incident, cost shape, data residency and compliance, exit, Kubernetes, and when each wins. We added Aiven and Upstash to the price table because they are the managed Valkey and usage-priced options buyers ask about. Prices and availability targets are each vendor’s published figures read on its own pricing and SLA pages on 9 November 2026, in US dollars, with the unit, region and node size stated; where a vendor publishes no list price, the table says so. The per-GB column is our arithmetic. The feature details come from each vendor’s documentation, checked on 14 October 2026, and the Kubernetes statuses from project releases on 28 October 2026. AceMQ supports self-managed Redis and Valkey and can operate them for you on your infrastructure or its own, so the wins-when row and the situation table also say when a cloud service is the better answer.