What Is Managed Redis?

Managed Redis is Redis — or, increasingly, Valkey — run as a cloud service, where the provider owns provisioning, patching, replication, failover, backups and monitoring, and you get an endpoint. AWS ElastiCache, Azure Managed Redis, Google Cloud Memorystore, Redis Cloud, Aiven and DigitalOcean are all managed Redis offerings.

"Managed Redis" is a category label, not a product or a protocol. There is no specification behind it, and no two providers draw the line in the same place. That is the practical problem with the term: it tells you who runs the server, and almost nothing about what your application is allowed to do with it.

Because the trade is usually described in operational language — less toil, higher availability, a support contract — it is easy to miss that a managed service also changes your application's runtime contract. Commands you relied on are disabled. Configuration you used to set in redis.conf is now a console setting, an API call, or unavailable. Failover happens on the provider's schedule and your client has to follow it. This page covers what actually changes, and what it means for the code connecting to it.

Managed vs. Self-Hosted: What You Actually Trade

The operational case for managed Redis is strong and mostly uncontroversial. The costs are less often stated plainly.

The row that surprises teams is the last one. Managed Redis is excellent at preventing incidents and noticeably worse at letting you diagnose them, because most of the diagnostic surface is exactly the administrative surface the provider had to remove in order to offer the service safely.

The Provider Landscape

Enough to orient yourself; this is not a buying guide, and the details change quarterly.

• AWS ElastiCache offers both Valkey and Redis OSS, plus a serverless mode. Redis OSS is capped at 7.1; Valkey continues to track upstream releases and is priced below the Redis OSS option.
• Amazon MemoryDB is the durable sibling — a multi-AZ transaction log makes it a primary database rather than a cache. Always clustered.
• Azure Managed Redis became generally available in May 2025 and is built on Redis Enterprise, so it is multi-core and ships modules. It replaces Azure Cache for Redis, which is being retired: the Enterprise and Enterprise Flash tiers on 31 March 2027, and Basic, Standard and Premium on 30 September 2028.
• Google Cloud Memorystore offers Valkey, Redis Cluster and Redis, plus a Memcached product that has been deprecated. Memorystore for Valkey reached GA in April 2025; the Redis products are capped at 7.2 and earlier.
• Redis Cloud is the first-party service from Redis Ltd., and the only route to current Redis Enterprise features direct from the vendor.
• Independents — Aiven, DigitalOcean, Upstash, Scaleway, Oracle OCI Cache and others — compete on price, region coverage and billing model rather than on engine.

The one structural point worth carrying away: the hyperscalers have diverged. AWS and Google made Valkey their default and price it below Redis; Microsoft went the other way and licensed Redis Enterprise. "Managed Redis" now means materially different engines depending on where you buy it.

Why the Licence Change Reshaped Managed Redis

That divergence is recent and has a single cause. In March 2024 Redis moved from BSD-3-Clause to a dual RSALv2/SSPLv1 licence, which prohibits offering the software as a competing managed service. Redis 8 later added AGPLv3 as a third option, but AGPL does not restore the permissive terms a cloud provider needs.

The response was Valkey, a fork of the last BSD-licensed Redis, governed by the Linux Foundation. AWS and Google both adopted it, priced it below their Redis OSS options and pitched the governance model explicitly. Microsoft went the opposite way, deepening its relationship with Redis Ltd. and building Azure Managed Redis on Redis Enterprise.

For most application code this is invisible — Valkey is protocol-compatible and your commands do not change. It matters when you are choosing a provider, planning a version upgrade, or relying on a Redis module or a post-7.2 feature that Valkey implements differently or not at all. Our Valkey vs. Redis comparison covers the divergence in detail.

Commands Your Managed Provider Has Disabled

This is the part that reaches your code, and the part almost no provider comparison covers. To offer Redis safely as a service, every provider removes the commands that would let a tenant reconfigure, inspect or destabilise the host. The lists overlap heavily but are not identical, and the differences are load-bearing.

Two entries deserve attention because they contradict the reasonable assumption that a provider's newer service behaves like its older one.

Azure Managed Redis is not Azure Cache for Redis with a new name. Because it runs Redis Enterprise rather than Redis OSS, its restrictions are drawn differently: CONFIG is partially available rather than blocked outright, but only a subset of settings is exposed — CONFIG GET maxmemory, for instance, is not, because an Enterprise database may span several shards. Anyone porting operational tooling from Azure Cache to Azure Managed Redis during the retirement window should expect a different failure surface, not a smaller one.

Azure Managed Redis supports one database per instance. If your Java configuration sets a database index other than 0, it will not connect. This is easy to miss because the default is 0 and most applications never change it — but any code that used a non-zero index for environment separation on Azure Cache needs a different strategy, normally a key prefix or a separate instance.

The error a blocked command returns is not standardised, which makes these failures easy to misdiagnose. Azure Cache for Redis reports ERR unknown command — indistinguishable from a typo or a version mismatch. Google Memorystore returns NOPERM, which at least names the cause. AWS documents no error string at all. Do not write client code that pattern-matches on the message.

That failure is not hypothetical. Spring Data Redis's keyspace-notification listener issues CONFIG GET and CONFIG SET notify-keyspace-events when it starts, which throws on ElastiCache; the project added a configuration parameter specifically so the call can be suppressed. The same pattern has been reported against clients in several other languages. It is worth knowing which of your libraries touch CONFIG at startup before you migrate.

Cluster Mode, Clustering Policy, and What They Mean for Your Client

Every provider exposes a choice between a single logical dataset and a sharded one, and each has invented its own name for it. The name matters less than the fact that the choice changes which client configuration is correct — and getting it wrong produces failures that look like network problems.

ElastiCache: cluster mode disabled vs. enabled. Disabled means one shard with up to five read replicas; enabled means up to 500 shards. The trap is the disabled case, because it is the one that looks simpler. AWS documents that cluster-mode-disabled clusters do not support the cluster discovery commands and are not compatible with clients' dynamic topology discovery. A client configured for cluster mode against a non-clustered endpoint cannot discover anything, so you must use a mode that polls node roles instead.

Azure Managed Redis: OSS vs. Enterprise clustering policy. This is the less documented of the two and the more surprising. Under OSS clustering policy the client connects on port 10000 and is then redirected to individual shards on ports in the 85XX range — which requires both a cluster-aware client and network reachability to those ports. Outside the VNet, that manifests as MOVED errors pointing at private addresses the client cannot open. Under Enterprise clustering policy a proxy presents one endpoint and the instance looks non-clustered; in exchange, only DEL, MSET, MGET, EXISTS, UNLINK and TOUCH work across slots, the CLUSTER introspection commands are blocked, and the proxy is a throughput ceiling. Enterprise policy is also the only one that supports RediSearch.

The general rule across providers: a single-endpoint managed instance and a sharded one need different client configurations, and the provider's console rarely tells you which. The mapping table in the next section is the practical answer.

Keyspace Notifications on Managed Redis

A specific consequence of blocked CONFIG commands, and one that breaks features rather than connections. Keyspace notifications are off by default in Redis, and normally enabled with CONFIG SET notify-keyspace-events. On a managed service that command is unavailable, so each provider substitutes its own mechanism:

The failure mode is quiet: notifications are simply never delivered, no error is raised, and anything built on them — expiration listeners, cache invalidation, session timeout handling — silently does nothing. If you depend on this, enable it deliberately as part of provisioning and verify it, rather than assuming a default.

Connecting to Managed Redis From Java

Redisson is a Java client for Redis and Valkey, and it documents an explicit compatibility list per connection mode. Choosing the wrong one is the single most common cause of managed-Redis connection problems in Java, so the mapping is worth stating directly:

Replicated mode is the one built for managed services. It polls each node's role so that when the provider promotes a replica, the client follows without application code being involved:

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

Config config = new Config();
config.useReplicatedServers()
      .addNodeAddress("rediss://primary.example.cache.amazonaws.com:6379",
                      "rediss://replica-001.example.cache.amazonaws.com:6379")
      .setScanInterval(2000)      // role re-check period; default is 1000 ms
      .setMonitorIPChanges(true); // default false

RedissonClient redisson = Redisson.create(config);

setMonitorIPChanges is off by default and matters here specifically: managed providers replace nodes behind stable DNS names, so an address that resolved correctly at startup can point at a decommissioned node later. With it enabled, Redisson re-resolves each configured hostname during the scan and drops the connection when the IP has changed, forcing it to be re-established against the new node. It exists only in Replicated mode; cluster mode instead re-reads topology on setScanInterval.

Note the node addresses in that example. Redisson's documentation is explicit that a single hostname resolving to multiple masters or replicas requires Redisson PRO — which is what an ElastiCache reader endpoint is. On the community edition, list the individual node endpoints rather than the reader endpoint.

TLS and authentication. Most managed endpoints require TLS, which means the rediss:// scheme rather than redis:// — a mismatch that produces a connection timeout rather than a clear error. Redisson 4.0 moved TLS and credential settings from the per-mode configuration onto the Config object itself — a breaking change, so samples written against 3.x will not compile unchanged:

import org.redisson.config.Config;
import org.redisson.config.SslVerificationMode;

Config config = new Config();
config.setSslVerificationMode(SslVerificationMode.STRICT)  // default
      .setUsername("appuser")
      .setPassword(System.getenv("REDIS_PASSWORD"));

config.useReplicatedServers().addNodeAddress("rediss://primary.example.com:6379");

The older setSslEnableEndpointIdentification is deprecated in favour of setSslVerificationMode; where you previously disabled endpoint identification, CA_ONLY is the equivalent.

For token-based authentication, setCredentialsResolver() takes a CredentialsResolver, which resolves credentials per connection and signals expiry through nextRenewal() rather than refreshing on a fixed schedule. Redisson ships EntraIdCredentialsResolver for Microsoft Entra ID; for AWS IAM you supply your own implementation against the AWS SDK, and our ElastiCache IAM walkthrough gives the full class.

On disabled CONFIG commands. Redisson discovers topology using CLUSTER NODES, INFO REPLICATION and the SENTINEL commands rather than CONFIG, and exposes CONFIG only through the explicit RedisNode API — so it is reached when your code asks for it, not during connection setup. Keyspace-notification listeners are the exception that applies to every client: Redisson's documentation states that notify-keyspace-events must be enabled server-side, and Redisson will not set it for you. Where you cannot enable it — on ElastiCache Serverless, for instance — setting expirationEventPolicy to DONT_SUBSCRIBE on org.redisson.api.options.LocalCachedMapOptions lets a local cache operate without depending on expired events.

For multi-region managed deployments — ElastiCache Global Datastore, Azure active geo-replication, Redis Enterprise Active-Active — Multi Cluster, Multi Sentinel and Proxy modes are Redisson PRO features, available on a free trial. These are not runtime-gated: the corresponding use* methods are absent from the community artifact, so a configuration written against them will not compile against it. The provider-specific walkthroughs cover AWS ElastiCache, Azure Cache, Google Cloud Memorystore, Amazon MemoryDB and Aiven in more depth.

Managed Redis: Frequently Asked Questions

What Is Managed Redis?

Managed Redis is Redis or Valkey offered as a cloud service, where the provider handles provisioning, patching, replication, failover, backups and monitoring, and the customer connects to an endpoint. AWS ElastiCache, Azure Managed Redis, Google Cloud Memorystore and Redis Cloud are examples. It is a category label rather than a specific product, and providers differ substantially in which commands and configuration settings they expose.

What Is the Difference Between Managed Redis and Self-Hosted Redis?

Self-hosted Redis gives you full control of the configuration file, every command, and the failover mechanism, at the cost of operating it yourself. Managed Redis takes over operations but restricts administrative commands, limits configuration to a provider-approved subset, and controls engine versions and failover timing. The practical trade is fewer incidents in exchange for a smaller diagnostic surface when one occurs.

Which Commands Are Disabled on Managed Redis?

Every provider blocks the administrative set: CONFIG, DEBUG, SAVE, BGSAVE, SHUTDOWN, REPLICAOF, SLAVEOF, PSYNC, SYNC, MODULE LOAD and the cluster write subcommands. Beyond that the lists differ — AWS ElastiCache Serverless additionally restricts KEYS, MONITOR, SLOWLOG and others, while Azure Managed Redis allows a subset of CONFIG because it runs Redis Enterprise. The error returned is not standardised: Azure reports ERR unknown command, Google Memorystore returns NOPERM, and AWS documents no specific string.

Is Azure Managed Redis the Same as Azure Cache for Redis?

No. Azure Managed Redis became generally available in May 2025 and is built on Redis Enterprise, making it multi-core and module-capable, with a clustering-policy choice that affects client configuration. Azure Cache for Redis is the older Redis OSS-based service and is being retired — Enterprise and Enterprise Flash tiers on 31 March 2027, and Basic, Standard and Premium on 30 September 2028. The two have different blocked-command lists, and Azure Managed Redis supports only one database per instance.

Why Do Keyspace Notifications Not Work on Managed Redis?

Keyspace notifications are disabled by default and are normally enabled with CONFIG SET notify-keyspace-events, which managed providers block. Each provider substitutes its own mechanism: a custom parameter group on AWS ElastiCache, an Advanced settings page on Azure Cache for Redis, an ARM template redeploy on Azure Managed Redis, and an instance configuration parameter on Google Memorystore. Until one of these is applied, no notifications are delivered and no error is raised.

Does Managed Redis Support Redis Cluster?

Yes, though every provider names it differently. AWS calls it cluster mode enabled; Azure Managed Redis offers OSS and Enterprise clustering policies, where OSS exposes the Redis Cluster API and Enterprise hides it behind a proxy; Google offers Memorystore for Redis Cluster as a separate product. The choice determines which client configuration is correct, and a mismatch typically appears as MOVED errors or a failure to discover topology.

Do I Still Need Redis Sentinel on a Managed Service?

No. Managed providers implement their own failover and promotion, and do not expose Sentinel. Your client should be configured to follow provider-driven failover — in Redisson, that is Replicated mode for non-clustered instances, which polls node roles and repoints to the new primary automatically.

Similar terms

• Redis
• Valkey
• Redis Architecture
• Redis Cluster
• Redis Sentinel
• Redis Master-Slave Replication
• Redis Persistence
• Redis Caching
• Distributed Caching
• In-Memory Database
• Redis Java Client