Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of ElastiCache (Valkey/Redis) with its adaptation on each target. A dash means this row is not stated for that target.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

On AWS your cache is a provisioned Valkey replication group: a node type you chose, one or more shards, up to five replicas per shard and Multi-AZ failover, reached over the Redis wire protocol (RESP) from a Redis client. On Google Cloud the same application runs against a Memorystore for Redis instance, the classic single-primary product, and the Redis client connects to that instance’s private endpoint over the same wire. No adapter sits between the client and the cache; every command runs on the instance’s own Redis 7.2 engine. The ElastiCache management calls an application makes to locate its cache still work. When your code calls DescribeReplicationGroups or DescribeCacheClusters at startup to learn its endpoint, the Tensor9 service adapter answers from the Memorystore instance’s host, port and state, in the response shape the AWS SDK expects. A runtime CreateReplicationGroup, ModifyReplicationGroup or DeleteReplicationGroup from the application is refused with an ElastiCache error; provisioning belongs to your deployment, not to application code.
  • Same client, same wire: the application keeps its Redis client and speaks RESP straight to the Memorystore instance; there is no proxy in the data path.
  • Endpoint discovery through the AWS SDK still works. DescribeReplicationGroups and DescribeCacheClusters return the Memorystore host, port and status; an application that reads its endpoint from configuration never makes the call.
  • A managed cache. Google operates the instance: the cross-zone replica, automatic failover, snapshots and patching. You choose the tier and capacity.

​
Limitations

Memorystore for Redis is a different engine and a different shape from a Valkey replication group; the four divergences below decide whether it fits. △ Where a Valkey replication group and Memorystore for Redis diverge
  • The engine is Redis 7.2: the classic instance tops out at Redis 7.2, so JSON and the commands ElastiCache added at Valkey 8.1 and later are absent: Bloom filters, FT.* vector and full-text search, the hash-field TTL family (HEXPIRE, HTTL and the rest), DELIFEQ, MSETEX and CLUSTERSCAN return an unknown-command error. An application that uses them targets Memorystore for Valkey instead.
  • One primary shard: the classic instance is one primary with up to five read replicas and a 300 GB ceiling; it does not shard the keyspace. A cluster-mode-disabled replication group maps directly; a cluster-mode-enabled group that spreads slots across shards maps to Memorystore for Redis Cluster, a distinct product with its own resource.
  • One AUTH string: access is a single 36-character AUTH string per instance; there are no ACL users and no IAM authentication on the classic product, so RBAC user groups and IAM-authenticated users collapse to one shared credential that every client presents.
  • Snapshots only, on a 1 to 24 hour schedule: persistence is RDB snapshots at a 1, 6, 12 or 24 hour interval; there is no AOF and no analog of the Valkey 9.0 Multi-AZ durability log, so a write acknowledged as durable on ElastiCache 9.0 is at risk here until the next snapshot lands.

​
Other considerations

What remains is operational: how the replication group’s sizing, failover, configuration and data translate to an instance Google runs.
  • Sizing: a node type per node becomes a tier plus a memory size: Standard Tier for anything that had replicas or Multi-AZ, Basic Tier only for a cache you can afford to lose, and a memory size up to 300 GB. Read replicas (1 to 5) need a 5 GB or larger instance and serve reads through a separate read endpoint, the same split as ElastiCache’s reader endpoint.
  • Failover. Standard Tier fails over to its cross-zone replica automatically under a 99.9% SLA, where ElastiCache’s Multi-AZ replication group is backed by 99.99%; clients reconnect to the same endpoint after either failover.
  • Eviction and configuration: the eviction policy and the other supported parameters move from the parameter group to the instance’s configuration flags; the default is volatile-lru on both sides, and a runtime CONFIG SET is refused.
  • Encryption: in-transit TLS is a per-instance setting that follows the replication group’s; a customer-managed key binds at create and covers snapshots and backups, while the working set in memory is not encrypted on either side.
  • Data migration: the instance starts empty. Most caches re-warm; a replication group that holds durable data exports an RDB to S3 and imports it from Cloud Storage before cutover.

​
On Azure

​
How it works

On AWS your cache is a provisioned Valkey replication group: a node type you chose, one or more shards, up to five replicas per shard and Multi-AZ failover, reached over the Redis wire protocol (RESP). On Azure the same application runs against an Azure Managed Redis cache built on the Redis Enterprise engine, and the Redis client connects to that cache’s endpoint over the same wire. No adapter sits between the client and the cache; every command runs on the Enterprise engine itself. The ElastiCache management calls an application makes to locate its cache still work. When your code calls DescribeReplicationGroups or DescribeCacheClusters at startup, the Tensor9 service adapter answers from the cache’s host name and its database’s port and state (Azure keeps the two on separate resources), in the response shape the AWS SDK expects. A runtime CreateReplicationGroup, ModifyReplicationGroup or DeleteReplicationGroup from the application is refused with an ElastiCache error; provisioning belongs to your deployment.
  • Same client, same wire: the application keeps its Redis client and speaks RESP straight to the cache; under the OSS clustering policy the initial connection is port 10000 and the client discovers shard ports through CLUSTER NODES, as a cluster-mode-enabled ElastiCache client already does.
  • The AWS SDK still finds the cache. DescribeReplicationGroups and DescribeCacheClusters return the cache’s host, port and status; an application that reads its endpoint from configuration never makes the call.
  • A managed cache. Microsoft operates the engine, replication, zone distribution and failover. You choose the SKU and memory size.

​
Limitations

Azure Managed Redis runs a different engine from a Valkey replication group and buys capacity differently; the divergences below are the ones that decide a cutover. △ Where a Valkey replication group and Azure Managed Redis diverge
  • The engine is Redis Enterprise 7.4: a multi-threaded, sharded-by-default implementation of the Redis wire. It serves the Redis 7.4 command set, so the hash-field TTL family is present, but Valkey’s own additions are absent: DELIFEQ, MSETEX, CLUSTERSCAN and the Valkey 9 / Redis 8 HGETEX, HSETEX and HGETDEL return an unknown-command error. An application that depends on single-threaded ordering across connections should validate against the Enterprise engine.
  • Shards belong to the SKU: a replication group’s shard count and replicas-per-shard become a SKU (Balanced, Memory Optimized, Compute Optimized or Flash Optimized) and a memory size; the service picks the shard count, and there is no scale-down, so a cache sized for a peak stays that size.
  • One logical database, and slot-bound multi-key commands. Redis Enterprise exposes one logical database, so SELECT has nothing to switch to; under the OSS and Enterprise policies a multi-key command whose keys hash to different slots returns CROSSSLOT (Enterprise allows DEL, MSET, MGET, EXISTS, UNLINK and TOUCH across slots). A cluster-mode-disabled replication group that relied on cross-key MULTI blocks picks the Non-clustered policy, which is limited to 25 GB.
  • Search constrains policy and eviction. RediSearch requires the Enterprise clustering policy and the noeviction policy, so a cache that serves FT.* queries cannot use the OSS Cluster API and cannot evict under memory pressure; size it for its full keyspace.

​
Other considerations

What remains is operational: how the replication group’s sizing, failover, identity, persistence and data translate to a cache Microsoft runs.
  • Sizing: pick the tier by the memory-to-vCPU ratio your node type implied (Memory Optimized 8:1, Balanced 4:1, Compute Optimized 2:1), then the memory size; about a fifth of each cache’s memory is reserved for replication and failover buffers, so size the SKU above the replication group’s used memory rather than at it.
  • Failover: high availability keeps a replica shard of every primary on a second node, zone-distributed by default where the region has zones, and fails over automatically under Azure’s SLA; clients reconnect to the same endpoint, as they do after an ElastiCache Multi-AZ failover.
  • Authentication: new caches default to Microsoft Entra ID (managed identity) with access keys still available; a replication group’s RBAC user groups map to Entra identities and data-access ACLs set on the control plane, and ACL SETUSER at runtime is disabled.
  • Persistence and backups. RDB or AOF persistence to a managed disk recovers the same cache after an outage; a copy you keep is an Export to a storage account, and a new cache starts empty unless you Import one.
  • Configuration: the eviction policy, the TLS minimum version and the module set are cache settings on the control plane; CONFIG SET is refused at runtime, as it is on ElastiCache.
  • Data migration: most caches re-warm. A replication group that holds durable data exports an RDB to S3 and Imports it from a storage account before cutover.

​
On Private Kubernetes

​
How it works

On AWS your cache is a provisioned Valkey replication group: a node type you chose, one or more shards, up to five replicas per shard and Multi-AZ failover, reached over the Redis wire protocol (RESP). On the target cluster the same application runs against a Valkey deployment from the Bitnami Helm chart, the same engine ElastiCache runs (the chart ships Valkey 8.1.3), and the Redis client connects to the deployment’s in-cluster service over the same wire. No adapter sits between the client and the cache. The deployment takes its shape from the replication group: the node type sets the pod’s memory and CPU, the replica count becomes one replica pod per ElastiCache replica, automatic failover enables Sentinel, in-transit encryption enables TLS with a cert-manager certificate, and password AUTH is on with the password held in a Kubernetes secret. The ElastiCache management calls an application makes to locate its cache still work: DescribeReplicationGroups and DescribeCacheClusters are answered by the Tensor9 service adapter from the deployment’s service names, port 6379 and status. A runtime CreateReplicationGroup, ModifyReplicationGroup or DeleteReplicationGroup from the application is refused with an ElastiCache error.
  • The same engine: the data plane runs on Valkey itself, so commands, data structures, eviction and the Valkey-specific additions behave as they did, at whichever engine version the chart’s image is set to.
  • Your settings follow you: node type, replica count, automatic failover and in-transit encryption on the replication group become pod resources, replica pods, Sentinel and TLS on the chart.
  • Endpoint discovery through the AWS SDK is answered in-cluster. DescribeReplicationGroups returns the in-cluster primary and replica service names on port 6379; an application that reads its endpoint from configuration never makes the call.

​
Limitations

The engine is the same, so the divergences are operational: what AWS ran for you, you now configure and run, and three defaults differ from ElastiCache’s. △ Where a Valkey replication group and self-hosted Valkey diverge
  • No managed SLA: availability and durability are bounded by how the cluster is run. Sentinel elects a new primary when the old one fails, with a failover time set by its quorum and down-after-milliseconds settings rather than ElastiCache’s Multi-AZ promotion, and there is no 99.99% commitment behind it.
  • The engine version is the image tag: the chart ships Valkey 8.1.3. A replication group on 9.0 or 9.1 that uses hash-field TTL, DELIFEQ, MSETEX or CLUSTERSCAN gets an unknown-command error until the image is set to the matching release; set it before cutover, and upgrades from then on are yours.
  • Modules are not bundled. JSON, Bloom and FT.* search are separate Valkey modules that the chart’s image does not include; an application that used them on ElastiCache gets an unknown-command error unless you build the modules into the image and load them.
  • Primary-replica by default, and noeviction by default: the chart deploys a primary with replicas rather than Valkey Cluster, so a cluster-mode-enabled replication group’s keyspace lands on one primary unless you configure Cluster; and the engine’s default eviction policy is noeviction where ElastiCache’s parameter group defaults to volatile-lru, so a cache that filled up and evicted on AWS returns out-of-memory errors on writes here until you set the policy.

​
Other considerations

What remains is the operating work a managed service did for you: sizing, durability, encryption, access and the open admin surface.
  • Sizing: the node type becomes the primary pod’s memory limit and CPU request, and the PersistentVolume size bounds what a snapshot or AOF can hold; there is no larger node to move to without editing the release, and no headroom beyond the pod’s limit. Read replicas scale with a replica HPA if you enable it; the primary does not autoscale.
  • Durability. RDB snapshots and AOF write to the PersistentVolume; surviving a node loss depends on the storage class’s replication plus AOF’s fsync policy, and the Valkey 9.0 Multi-AZ durability log has no analog. A volume snapshot from your storage class is the scheduled-backup equivalent.
  • Encryption. TLS follows the replication group’s in-transit setting and is issued by cert-manager; at-rest encryption is whatever the storage class and node disks provide, since the engine encrypts nothing itself.
  • Access: password AUTH is on, with the password in a Kubernetes secret; Valkey ACL users are engine configuration you add, and IAM authentication has no analog, so an IAM-authenticated client switches to the password or an ACL user.
  • The admin surface is open. CONFIG, SAVE, REPLICAOF and CLUSTER admin all run, because you operate the server; an application that could not issue them on ElastiCache gains nothing from this, and an operator gains the whole toolset and its consequences.
  • Data migration: most caches re-warm. A replication group that holds durable data exports an RDB to S3 and seeds the deployment with it as dump.rdb on the primary’s PersistentVolume before first start.
Service Catalog.