What is Azure Managed Redis (preview)?
Azure Managed Redis (preview) provides an in-memory data store based on the Redis Enterprise software. Redis Enterprise improves the performance and reliability of the community edition of Redis, while maintaining compatibility. Microsoft operates the service, hosted on Azure, and usable by any application within or outside of Azure. For more information on how Azure Managed Redis is built, see Azure Managed Redis Architecture.
Important
Azure Managed Redis is currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
Azure Managed Redis can improve the performance and scalability of an application that heavily uses backend data stores. It's able to process large volumes of application requests by keeping frequently accessed data in the server memory, which can be written to and read from quickly.
Redis brings a critical low-latency and high-throughput data storage solution to modern applications. Additionally, Redis is increasingly used for noncaching applications, including data ingestion, deduplication, messaging, leaderboards, semantic caching, and as a vector database.
Azure Managed Redis can be deployed standalone, or it can be deployed along with other Azure app or database services, such as Azure Container Apps, Azure App Service, Azure Functions, Azure SQL, or Azure Cosmos DB.
Key scenarios
Azure Managed Redis improves application performance by supporting common application architecture patterns. Some of the most common include the following patterns:
| Pattern | Description |
|---|---|
| Data cache | Databases are often too large to load directly into a cache. It's common to use the cache-aside pattern to load data into the cache only as needed. When the system makes changes to the data, the system can also update the cache, which is then distributed to other clients. Additionally, the system can set an expiration on data, or use an eviction policy to trigger data updates into the cache. |
| Content cache | Many web pages are generated from templates that use static content such as headers, footers, banners. These static items shouldn't change often. Using an in-memory cache provides quick access to static content compared to backend datastores. This pattern reduces processing time and server load, allowing web servers to be more responsive. It can allow you to reduce the number of servers needed to handle loads. Azure Managed Redis provides the Redis Output Cache Provider to support this pattern with ASP.NET. |
| Session store | This pattern is commonly used with shopping carts and other user history data that a web application might associate with user cookies. Storing too much in a cookie can have a negative effect on performance as the cookie size grows and is passed and validated with every request. A typical solution uses the cookie as a key to query the data in a database. When you use an in-memory cache, like Azure Managed Redis, to associate information with a user is faster than interacting with a full relational database. |
| Vector similarity search | A common AI use-case is to generate vector embeddings using a large language model (LLM). These vector embeddings need to be stored in a vector database and then compared to determine similarity. Azure Managed Redis has built-in functionality to both store and compare vector embeddings at high throughputs. |
| Semantic caching | Using LLMs often introduces a high amount of latency (due to generation time) and cost (due to per token pricing) to an application. Caching can help solve these problems by storing the past output of an LLM so that it can quickly be retrieved again. However, because LLMs use natural language, this can be difficult for typical caches to handle. Semantic caches like Azure Managed Redis are capable of caching not just a specific query, but the semantic meaning of a query, allowing it to be used much more naturally with LLMs. |
| Deduplication | Often, you need to determine if an action already happened in a system, such as determining if a username is taken or if a customer was already sent an email. In Azure Managed Redis, bloom filters can be used to rapidly determine duplicates and prevent problems. |
| Leaderboards | Redis offers simple and powerful support for developing leaderboards of all kinds using the sorted set data structure. Additionally, using active geo-replication can allow one leaderboard to be shared globally. |
| Job and message queuing | Applications often add tasks to a queue when the operations associated with the request take time to execute. Longer running operations are queued to be processed in sequence, often by another server. This method of deferring work is called task queuing. Azure Managed Redis provides a distributed queue to enable this pattern in your application. |
| PowerBI/Analytics Acceleration | You can use the Redis ODBC driver to utilize Redis for BI, reporting, and analytics use-cases. Because Redis is typically much faster than relational databases, using Redis in this way can dramatically increase query responsiveness. |
| Distributed transactions | Applications sometimes require a series of commands against a backend data-store to execute as a single atomic operation. All commands must succeed, or all must be rolled back to the initial state. Azure Managed Redis supports executing a batch of commands as a single transaction. |
Redis version
Azure Managed Redis supports Redis version 7.4.x. For more information, see How to upgrade the version of your Azure Managed Redis instance.
Choosing the right tier
There are four tiers of Azure Managed Redis available, each with different performance characteristics and price levels.
Three tiers are for in-memory data:
- Memory Optimized Ideal for memory-intensive use cases that require a high memory-to-vCPU ratio (8:1) but don't need the highest throughput performance. It provides a lower price point for scenarios where less processing power or throughput is necessary, making it an excellent choice for development and testing environments.
- Balanced (Memory + Compute) Offers a balanced memory-to-vCPU (4:1) ratio, making it ideal for standard workloads. This tier provides a healthy balance of memory and compute resources.
- Compute Optimized Designed for performance-intensive workloads requiring maximum throughput, with a low memory-to-vCPU (2:1) ratio. It's ideal for applications that demand the highest performance.
One tier stores data both in-memory and on-disk:
- Flash Optimized Enables Redis clusters to automatically move less frequently accessed data from memory (RAM) to NVMe storage. This reduces performance, but allows for cost-effective scaling of caches with large datasets.
Note
For more information on how the Flash Optimized tier is architected, see Azure Managed Redis Architecture
Important
You can also use the data persistence feature to store data on-disk for the in-memory tiers. Data persistence stores a backup copy of data on-disk for quick recovery in case of a unexpected outage. This is different than the Flash Optimized tier, which is designed to store data on-disk for typical operations. Storing some data on-disk using the Flash Optimized tier does not increase data resiliency. You may use data persistence on the Flash Optimized tier as well.
For instructions on how to scale between tiers and SKUs, see Scale an Azure Managed Redis instance.
Tiers and SKUs at a glance
For pricing information, see the Azure Managed Redis Pricing
Feature comparison
The following table helps describe some of the features supported by tier:
| Feature Description | Memory Optimized | Balanced | Compute Optimized | Flash Optimized |
|---|---|---|---|---|
| Size (GB) | 12 - 1920 | 0.5 - 960 | 3 - 720 | 250 - 4500 |
| Service Level Agreement (SLA) | Yes | Yes | Yes | Yes |
| Data encryption in transit | Yes (Private endpoint) | Yes (Private endpoint) | Yes (Private endpoint) | Yes (Private endpoint) |
| Replication and failover | Yes | Yes | Yes | Yes |
| Network isolation | Yes | Yes | Yes | Yes |
| Microsoft Entra ID based authentication | Yes | Yes | Yes | Yes |
| Scaling | Yes | Yes | Yes | Yes |
| Data persistence | Yes | Yes | Yes | Yes |
| Zone redundancy | Yes | Yes | Yes | Yes |
| Geo-replication | Yes (Active) | Yes (Active) | Yes (Active) | No |
| Connection audit logs | Yes (Event-based) | Yes (Event-based) | Yes (Event-based) | Yes (Event-based) |
| JSON data structures(that is, Redis JSON) | Yes | Yes | Yes | Yes |
| Search functionality (including vector search) | Yes | Yes | Yes | No |
| Probabilistic data structures (that is, Redis Bloom) | Yes | Yes | Yes | Yes |
| Time Series database capability (that is, Redis TimeSeries) | Yes | Yes | Yes | Yes |
| Redis on Flash(also known as autotiering) | Yes | Yes | Yes | Yes |
| Import/Export | Yes | Yes | Yes | Yes |
| Update channel and Schedule updates | No | No | No | No |
Important
The Balanced B0 and B1 SKU options do not support active geo-replication.
Important
SLA is only available at GA, and is not available during preview.
Note
Scaling down support is limited in some situations. For more information, see Prerequisites/limitations of scaling Azure Managed Redis.
Other considerations when picking a tier
- Network performance: If you have a workload that requires high throughput, you might be bottlenecked by network bandwidth. You can increase bandwidth by moving up to a higher performance tier or by moving to a large instance size. Larger size instances have more bandwidth because of the underlying VM that hosts the cache. Higher bandwidth limits help you avoid network saturation that cause timeouts in your application. For more information on bandwidth performance, see Performance testing
- Maximum number of client connections: Each SKU has a maximum number of client connections. This limit increases with higher performance tiers and larger instances sizes. For more information on the limit for each SKU, see Azure Managed Redis Pricing.
- High availability: Azure Managed Redis provides multiple high availability options. The SLA only covers connectivity to the cache endpoints. The SLA doesn't cover protection from data loss. For more information on the SLA, see the SLA. It's possible to disable high availability in an Azure Managed Redis instance. This lowers the price but results in data loss and downtime. We only recommend disabling high availability for dev/test scenarios.
Other pricing considerations
Important
Azure Managed Redis Enterprise requires an IP address for each cache instance. Currently, the IP address charge is absorbed by Azure Managed Redis and not passed on to customers. This may change in the future. For more information, see IP address pricing.
Important
Using active geo-replication will produce data transfer between Azure regions. These bandwidth charges are currently absorbed by Azure Managed Redis and not passed on to customers. This may change in the future. For more information, see Bandwidth pricing.
Availability by region
Azure Managed Redis is continually expanding into new regions. To check the availability by region, see Products available by region.
Migration from Azure Cache for Redis
For more information about migrating from Azure Cache for Redis to Azure Managed Redis, see Move from Azure Cache for Redis to Azure Managed Redis