> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Azure Managed Redis > Azure Managed Redis APIs with Cloud Adapter. 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 | Environment | Mapping | | ------------ | ------- | | AWS | API | | Google Cloud | API | 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 | Capability | Azure Managed Redis | AWS | Google Cloud | | ------------ | ------------------- | ------- | ------------ | | API coverage | full | partial | partial | ## On AWS ### ElastiCache | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------ | ------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Microsoft Entra authentication | Connect | Out of scope | Most usage | The target does not accept Entra tokens. The build identifies the switch to target identity-based authentication, including the client library used to obtain tokens. | | Active geo-replication | Control | Partial | Full surface | Azure merges writes across regions using conflict-free replicated data types. The target replicates from one primary region; the build requires acknowledgement of the new replication topology. | | Instances, databases and access keys | Control | Supported | Common | The instance and database become a managed cache cluster with target access keys, mapped capacity and a target-compatible engine version. The build identifies unsupported size or version selections. | | Transport encryption | Control | Supported | Most usage | Connections use the target's transport encryption. | | Cache wire protocol | Data | Supported | Common | The application keeps its cache protocol and client library, subject to the authentication differences below. | | Clustered keyspace | Data | Supported | Most usage | Both services use clusters with the same hash slots and redirects, so the cluster-aware client keeps its key routing. | | Redis modules (RediSearch, RedisJSON, RedisBloom, RedisTimeSeries) | Data | Out of scope | Most usage | Rejected at build time: the target engine does not provide these Redis Enterprise modules. | 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 | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------ | ------- | ------------ | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Microsoft Entra authentication | Connect | Out of scope | Most usage | The target does not accept Entra tokens. The build identifies the switch to target identity-based authentication, including the client library used to obtain tokens. | | Instances, databases and access keys | Control | Supported | Common | The instance and database become a managed cache instance with mapped capacity and a target-compatible engine version. The build identifies unsupported size or version selections. | | Transport encryption | Control | Supported | Most usage | Connections use the target's transport encryption. | | Cache wire protocol | Data | Supported | Common | The application keeps its cache protocol and client library, subject to the authentication differences below. | | Clustered keyspace | Data | Partial | Most usage | The build identifies whether the target will use a single shard or a cluster. A client expecting Azure's default clustered configuration must account for that choice. | | Redis modules (RediSearch, RedisJSON, RedisBloom, RedisTimeSeries) | Data | Out of scope | Most usage | Rejected at build time: the target engine does not provide these Redis Enterprise modules. | 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](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.