Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Managed Redis has several configuration options that you set when you create an instance. Many of these choices are permanent or difficult to reverse. Before you provision a cache, work through your capacity requirements, reservation strategy, clustering policy, module selection, reliability posture, and security design. This way, you don't have to re-create the instance to fix an early decision. This article is a decision map: it sequences the questions you need to answer, points you to the specialist article that covers each decision in depth, and helps you tell which choices you're locking in at creation versus which ones you can adjust later.
This article doesn't recommend a configuration for a specific workload pattern, such as caching, session storage, or retrieval-augmented generation. For that guidance, see Key scenarios. It also doesn't repeat the detailed comparison tables from the specialist articles it links to. Use this hub to decide which article you need, then read that article for the full detail.
Decision sequence
Work through these steps in order before you create your instance. Each step links to the article with full detail.
- Define your data and performance requirements. Estimate your current dataset size (including per-key overhead and expected growth), your expected peak client connection count, and whether throughput/CPU or memory capacity is your primary constraint. These inputs drive every decision that follows.
- Choose a tier and initial capacity. Compare the memory-to-vCPU tradeoffs of the Memory Optimized, Balanced, and Compute Optimized tiers against the Flash Optimized tier's memory-plus-NVMe model, and size the instance with headroom for growth. See Choose a tier and plan capacity.
- Evaluate reservation savings. After you identify a stable region, tier, and baseline node quantity, decide whether a one-year or three-year compute commitment fits your deployment plan. See Plan reservation savings.
- Choose a clustering policy. Decide between OSS, Enterprise, and Non-clustered based on your client library's Redis Cluster API support, whether your application needs RediSearch, and whether your workload issues multikey or transaction commands that can't guarantee a shared hash slot. See Choose a clustering policy.
- Select modules at creation. Decide whether you need RediSearch, RedisJSON, RedisBloom, or RedisTimeSeries. The module set is fixed at creation, and RediSearch further constrains your clustering and eviction policy choices. See Plan Redis modules.
- Decide your reliability and durability posture. Plan high availability (HA), availability-zone distribution, data persistence, active geo-replication, and an application-level backup process. These capabilities protect against different failure scopes and some are mutually exclusive. See Plan reliability and durability.
- Plan security, networking, and observability. Decide how you'll isolate network access, authenticate clients, and monitor the cache. This planning is largely independent of the tier, clustering, and module choices above, but confirm your approach before you provision so your network design (for example, a virtual network for private endpoints) is ready. See Secure your Azure Managed Redis deployment, Azure Managed Redis with Azure Private Link, Use Microsoft Entra ID for cache authentication, and Monitor Azure Managed Redis data using diagnostic settings.
- Identify which of your choices are immutable or constrained. Review Decisions locked at creation versus decisions you can adjust later so you know which decisions deserve the most scrutiny now.
- Complete the pre-provisioning decision record. Fill in the decision record with your choices from the previous steps before you create the instance.
Important
Tier family, clustering policy, and module selection are the three decisions with the least flexibility after creation. You generally can't change them without deleting and re-creating the cache. Confirm these three decisions carefully, because they also constrain your eviction policy and geo-replication options.
Decisions locked at creation versus decisions you can adjust later
Some Azure Managed Redis settings are permanent from the moment you provision the instance. Others can change, but only in one direction, or only under specific conditions. Use this summary to prioritize which decisions need the most scrutiny before you create your cache; each linked article covers the exact constraints.
- Fixed for the life of the instance: The tier family (you can't move between Flash Optimized and any in-memory tier), the OSS or Enterprise clustering policy, and the module set (you can't add, remove, or change the version of a module after creation).
- Changeable in only one direction: A Non-clustered cache can move to a clustered policy later, unless it's part of an active geo-replication group, but a clustered cache can't become Non-clustered. HA can be enabled on an existing cache, but can't be disabled once enabled.
- Adjustable with constraints: Capacity can scale up, but scaling down requires your current usage to already be below the target size and a compatible vCPU/shard configuration. Data persistence can be enabled or disabled, but it's mutually exclusive with active geo-replication on the same cache. Active geo-replication is effectively one-way: adding an existing instance to a geo-replication group clears its data, and removing an instance from the group requires deleting that cache instance. Every instance in a geo-replication group must also share an identical configuration.
- Adjustable with little friction: Availability-zone distribution applies automatically with HA in a zone-enabled region. Most security, networking, and observability settings—such as private endpoints, Microsoft Entra ID authentication, and diagnostic settings—can be changed after creation, although planning them early avoids rework.
Pre-provisioning decision record
Fill in this table before you create your instance. Use it as a checklist to confirm you made a deliberate choice for each area. Don't use it as a substitute for the detail in the linked articles.
| Decision area | Your choice | Locked at creation? | Where to decide |
|---|---|---|---|
| Data and performance requirements | Dataset size, growth, peak connections, throughput versus memory priority | Not applicable; this decision is a planning input | This article |
| Tier and initial capacity | Tier and size | Tier family is fixed; size can scale up, with limited scale-down | Choose a tier and plan capacity |
| Reservation commitment | Region, tier, scope, term, billing frequency, node quantity, and auto-renewal | Separate billing commitment; scope and auto-renewal can change, while exchange and refund limits apply | Plan reservation savings |
| Clustering policy | OSS, Enterprise, or Non-clustered | OSS and Enterprise are fixed; Non-clustered can move to a clustered policy unless it's in an active geo-replication group | Choose a clustering policy |
| Modules | RediSearch, RedisJSON, RedisBloom, RedisTimeSeries, or none | Fixed at creation; can't add, remove, or change versions later | Plan Redis modules |
| High availability | Enabled or disabled | Can enable later; can't disable once enabled | Plan reliability and durability |
| Availability-zone distribution | Applied automatically with HA in zone-enabled regions | Not independently configurable | Plan reliability and durability |
| Persistence versus active geo-replication | Persistence, geo-replication, or neither | Mutually exclusive; persistence is reversible, but geo-replication effectively isn't—joining clears an instance's data, and leaving requires deleting it | Plan reliability and durability |
| Application-level backups | Import/export automation cadence | Adjustable at any time | Plan reliability and durability |
| Network isolation | Public access, private endpoints, or both | Adjustable after creation | Azure Managed Redis with Azure Private Link |
| Authentication | Microsoft Entra ID, access keys, or both | Adjustable after creation | Use Microsoft Entra ID for cache authentication |
| Observability | Metrics, connection logs, diagnostic settings | Adjustable after creation | Monitor Azure Managed Redis data using diagnostic settings |
Note
This decision record covers workload-independent configuration only. If your design also depends on a specific application pattern, such as caching, session storage, or vector search, review that pattern's guidance separately. That guidance isn't part of this hub.