Skip to main content
This page describes how Azure Managed Redis maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

How the targets compare

Each row compares a capability of Azure Managed Redis with its adaptation on each target. A dash means this profile does not state the capability for that target.

Cloud Adapter

On AWS

ElastiCache

Azure Managed Redis becomes an ElastiCache cluster. Your Redis client continues using the same protocol, hash slots and cluster redirects.

Client routing and state

The adapter manages the cache configuration; cache commands use the target engine. A clustered client follows hash-slot redirects to the node holding a key. Confirm the selected topology, supported modules, TLS, and credential provider together so a working TCP connection is not mistaken for application compatibility.

Moving cached data

Decide whether the application can repopulate the cache or needs an explicit transfer of keys and expiry times. A newly created cache does not inherit replication state. Test retries and reconnects after a node fails, and review any change from writes in several regions to a single primary.

Compatibility differences

The build rejects configurations that require RediSearch, RedisJSON, RedisBloom or RedisTimeSeries because the target engine does not provide those modules. Authentication also changes: ElastiCache does not accept Entra tokens, so you must use its identity-based authentication and update the client library that obtains the token.

On Google Cloud

Memorystore for Redis

Azure Managed Redis becomes a Memorystore instance. The Redis protocol remains the same, but the build selects and identifies whether the target is a single shard or a cluster. Check that choice if your client expects Azure’s default clustered configuration.

Client routing and state

The adapter manages the cache configuration; cache commands use the target engine. A clustered client follows hash-slot redirects to the node holding a key. Confirm the selected topology, supported modules, TLS, and credential provider together so a working TCP connection is not mistaken for application compatibility.

Moving cached data

Decide whether the application can repopulate the cache or needs an explicit transfer of keys and expiry times. A newly created cache does not inherit replication state. Test retries and reconnects after a node fails, and review any change from writes in several regions to a single primary.

Compatibility differences

The build rejects configurations using RediSearch, RedisJSON, RedisBloom or RedisTimeSeries because the target engine does not provide those modules.

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.