This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can trysigning in orchanging directories.
Access to this page requires authorization. You can trychanging directories.
Azure Managed Redis provides an in-memory data store based on theRedis 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, seeAzure Managed Redis Architecture.
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, and leaderboards
Azure Managed Redis can be deployed standalone, or 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.
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 thecache-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. |
| 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 rapidly determine duplicates, and prevent problems. |
| Leaderboards | Redis offers simple and powerful support for developing leaderboards of all kinds using thesorted set data structure. Additionally, usingactive 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 singletransaction. |
Azure Managed Redis supports Redis version 7.4.x. For more information, seeHow to upgrade the version of your Azure Managed Redis instance.
There are four tiers of Azure Managed Redis available, each with different performance characteristics and price levels.
Here are three tiers store that store data in memory:
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.
Here's the tier that stores data both in-memory and on-disk:
Flash Optimized (preview) 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.
You can also use thedata 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 if you experience an unexpected outage. Data persistence is different from 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 doesn't increase data resiliency. You can use data persistence on the Flash Optimized tier as well.
Note
For more information on how the Flash Optimized tier is architected, seeAzure Managed Redis Architecture
Important
All in-memory tiers that use over 235 GB of storage are in Public Preview, including Memory Optimized M350 and higher; Balanced B350 and higher; and Compute Optimized X350 and higher. All these tiers and higher are in Public Preview.
All Flash Optimized tiers are in Public Preview.
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 |
| High availability | *Yes | *Yes | *Yes | *Yes |
| Data persistence | Yes | Yes | Yes | Yes |
| Geo-replication | Yes (Active) | Yes (Active) | Yes (Active) | No |
| Non-clustered instances | Yes | Yes | Yes | 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 |
| Import/Export | Yes | Yes | Yes | Yes |
* WhenHigh availability is enabled, Azure Managed Redis is zone redundant in regions with multiple Availability Zones.
When you use High availability (HA), an Azure Managed Redis instance is deployed with primary and replica shards across two nodes. In regions without Availability Zones, the primary and replica shards are deployed across two nodes in the same zone.
Important
The Balanced B0 and B1 SKU options don't support active geo-replication.
Note
Scaling down support is limited in some situations. For more information, seeLimitations of scaling Azure Managed Redis.
If you have a workload that requires high throughput, network bandwidth might cause a bottleneck. 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 causes timeouts in your application. For more information on bandwidth performance, seePerformance testing
Each SKU has a maximum number of client connections. This limit increases with higher performance tiers and larger instances sizes. The following table shows the maximum client connections allowed per Azure Managed Redis SKU.
This table shows the max connections by tier and memory size in the Memory Optimized, Balanced, and Compute SKUs.
| Size (GB) | Memory Optimized | Balanced | Compute Optimized |
|---|---|---|---|
| 0.5 | - | 15,000 | - |
| 1 | - | 15,000 | - |
| 3 | - | 15,000 | 30,000 |
| 6 | - | 15,000 | 30,000 |
| 12 | 15,000 | 30,000 | 75,000 |
| 24 | 30,000 | 75,000 | 150,000 |
| 60 | 75,000 | 150,000 | 200,000 |
| 120 | 150,000 | 200,000 | 200,000 |
| 175 | 200,000 | 200,000 | 200,000 |
| 235 | 200,000 | 200,000 | 200,000 |
| 360 * | 200,000 | 200,000 | 200,000 |
| 480 * | 200,000 | 200,000 | 200,000 |
| 720 * | 200,000 | 200,000 | 200,000 |
| 960 * | 200,000 | 200,000 | - |
| 1440 * | 200,000 | - | - |
| 1920 * | 200,000 | - | - |
| 4500 * | - | - | - |
* The sizes with an asterisk are in Public Preview.
This table shows the max connections by tier and memory size in the Flash optimized (preview) SKU.
| Size (GB) | Flash Optimized (preview) |
|---|---|
| 235 * | 75,000 |
| 480 * | 150,000 |
| 720 * | 200,000 |
| 960 * | 200,000 |
| 1440 * | 200,000 |
| 1920 * | 200,000 |
| 4500 * | 200,000 |
* The sizes with an asterisk are in Public Preview.
Azure Managed Redis provides high availability. 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 theSLA. It's possible to disable high availability in an Azure Managed Redis instance. Disabling high availability lowers the price but results in data loss and downtime. We only recommend disabling high availability for dev/test scenarios.
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. Billing can change in the future. For more information, seeIP address pricing.
Important
Using active geo-replication produces data transfer between Azure regions. These bandwidth charges are currently absorbed by Azure Managed Redis and not passed on to customers. Billing can change in the future. For more information, seeBandwidth pricing.
Azure Managed Redis is continually expanding into new regions. To check the availability by region, seeProducts available by region.
For more information about migrating from Azure Cache for Redis to Azure Managed Redis, seeMove from Azure Cache for Redis to Azure Managed Redis.
Was this page helpful?
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?
Was this page helpful?
Want to try using Ask Learn to clarify or guide you through this topic?