Managed Redis and Valkey Services: On Your Infrastructure or Hosted on Ours

Managed Redis services mean someone else operates your Redis: monitoring, on-call, patching, upgrades, failover, capacity and incident response. There are two models. A hosted service such as Amazon ElastiCache, Google Cloud Memorystore, Azure Managed Redis or Redis Cloud runs Redis in the provider's environment. AceMQ offers two models. We operate Redis or Valkey on your own infrastructure, so the data and the account stay yours, or we host a dedicated deployment on ours. In both, a Redis specialist owns the whole platform.

Those services host Redis in the provider's environment. Amazon ElastiCache is a fully managed service compatible with Valkey, Memcached and Redis OSS; Azure Managed Redis is built on Redis Enterprise software, created in the Azure portal and integrated with Microsoft Entra ID authentication; Google Cloud Memorystore does the same job on Google Cloud. The provider manages the nodes, but key design, eviction behaviour, client configuration and most incident causes remain yours. AceMQ operates Redis where it already runs, in your account, or hosts a dedicated deployment for you on AceMQ infrastructure, and in both cases takes responsibility for the whole platform. Teams choose this for data residency, version and licence control, a named engineer, or to avoid lock-in. The options are compared in Managed Redis options compared.

Yes. Microsoft retires the Basic, Standard and Premium tiers of Azure Cache for Redis on 30 September 2028 and disables any remaining instances from 1 October 2028. The Enterprise and Enterprise Flash tiers retire earlier, on 31 March 2027. Microsoft's recommended path is Azure Managed Redis. The alternative is Redis Open Source or Valkey running in your own Azure subscription, or anywhere else, operated by AceMQ. We help teams choose between the two, then plan and run the migration with a tested cutover.

Yes. We operate Redis Open Source or Valkey on Azure Kubernetes Service or virtual machines in your own Azure subscription, configured to fit your existing Azure networking and monitoring. Teams leaving Azure Cache for Redis choose this when they need what Azure Managed Redis does not offer, such as multiple databases, keyspace notifications or virtual network deployment. The retirement dates and the differences are covered in our Azure Cache for Redis retirement guide, linked under related reading.

With replicas and automatic failover, using Redis Sentinel or Redis Cluster depending on whether the data needs sharding for scalability, and with RDB snapshots or AOF persistence configured per workload rather than left at the default. We test failover so clients reconnect to the new primary, and size memory and CPU so the high-performance, low-latency behaviour Redis is chosen for holds under peak throughput.

Support is an SLA over Redis your team runs: you hold the pager and call us when something breaks. Managed services means we run it: monitoring, patching, upgrades, capacity and on-call are ours. Teams with a capable platform team usually want support (Stages 1 and 2); teams that want Redis to stop being their problem want managed services (Stages 3 and 4).

Stage 1 is reactive support: you run Redis and raise tickets to a specialist under an SLA. Stage 2 is proactive support: you still run and own it, and AceMQ adds monitoring and alerting through its observability setup so problems surface early. Stage 3 is managed Redis or Valkey on your infrastructure: AceMQ operates it in your account and holds the pager. Stage 4 is managed Redis or Valkey on AceMQ infrastructure: AceMQ hosts and operates a dedicated deployment for you. The pager changes hands at Stage 3.

Yes. At Stage 4 AceMQ hosts and operates a dedicated Redis or Valkey deployment on its own infrastructure, so you get endpoints without a cloud account, Kubernetes cluster or on-call rota to run. Monitoring, patching, upgrades, failover, capacity and incident response are the same as when we run it in your account, with the same emergency response. If compliance or data-residency rules require it to stay in your account, we operate it there instead at Stage 3.

Yes. Managed Valkey is available both ways: we operate Valkey on your infrastructure, or we host it on ours. We run Redis Open Source and Valkey side by side, and can migrate between them with replication-based cutover when a change of licence or cost makes sense. Valkey remains BSD licensed; Redis 8 and later are available under RSALv2, SSPLv1 or AGPLv3. If you are weighing the move, the Redis to Valkey migration page covers the decision.

Yes. Most estates we take over are inherited. We start with an assessment of version and patch position, topology, persistence and memory configuration, eviction policy, client behaviour and monitoring gaps, remediate the active risks, and only then take the pager.

They stay covered while you plan the upgrade. For security patches on end-of-life versions, AceMQ's OSSeva platform backports CVE fixes to Redis 6.2.x and 7.0.x and to Valkey, so you can keep a version you cannot yet move off without running it unpatched.

Emergencies such as a primary down, a failover that did not complete or writes refused under memory pressure get a 15-minute first response from a senior engineer, 24/7. Because we already run the platform, proactive monitoring of memory, latency, throughput and replication catches most of those incidents before your team notices.

When Redis has become critical to the application and nobody on the team wants to own it. Redis is a low-latency in-memory data store built on data structures such as hashes, lists, sets and sorted sets. It is used as a cache, user session store, rate limiter, queue and increasingly as a primary in-memory database; since Redis 8, JSON documents, time series, search and vector sets ship in Redis Open Source itself. The failure modes that cause outages, such as eviction storms, fork stalls during snapshots and failovers the client never noticed, need someone watching availability, memory and replication continuously. If your team already runs Redis well and only needs an expert on call, support is the better fit.

All the common ones: Java with Jedis, Lettuce or Redisson, Python with redis-py, .NET with StackExchange.Redis, Node.js with node-redis or ioredis, and Go with go-redis. Many Redis incidents start in the client rather than the server, so we review connection pool sizing, timeouts, retry behaviour and how the client follows cluster topology changes, and tell the application team what to change.

Very little. Applications keep the same endpoints, client libraries, commands and data model, so no developer has to learn a new tool; teams request changes such as a new database, a setting change or more capacity through an agreed process, and AceMQ handles the configuration, testing and rollout. Where a client setting is causing incidents, such as connection pool sizing or timeouts, we tell the application team what to change and why.

Yes. AceMQ works on Redis in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your Redis environment, the SLA you need, the hours of cover and the scope of work. We do not send generic quotes or publish a price list, because two estates of the same size rarely need the same thing. Request a quote and AceMQ replies within 1 hour.