The caching product most Azure architects are designing around has a published end-of-life date. Azure Cache for Redis, across all tiers from Basic to Enterprise Flash, is being retired. Enterprise and Enterprise Flash retire on 31 March 2027, with remaining non-migrated instances disabled from 1 April 2027; Basic, Standard and Premium retire on 30 September 2028. Any architect selecting a caching technology in 2026 without accounting for that timeline is making a decision they will have to remake before the infrastructure has earned back its design cost. Azure Managed Redis, the GA replacement product that Microsoft is actively steering all new deployments toward, uses a completely different SKU model, has dropped VNet injection in favour of Private Link only, and prices compute and memory independently rather than bundling features into a tier hierarchy. The product landscape has changed more in the past eighteen months than in the previous five years, and almost none of the comparison articles circulating on the topic reflect the current state.
The majority of Azure caching decisions follow a pattern that is both familiar and expensive. A team identifies a performance problem, reaches for Azure Cache for Redis as the obvious answer, picks a tier based on memory size rather than workload profile, and ships. The result is commonly a Standard or Premium cache absorbing monthly charges for capabilities the application never exercises, sitting in front of a workload that could have been served entirely by Azure Front Door edge caching at a fraction of the cost, or where the Cosmos DB integrated cache would have eliminated the Redis dependency entirely. The wrong question is “which Redis tier should we use?” The right question is “does this workload need Redis at all?” That distinction matters because the decision sequence from edge to application layer can reduce caching infrastructure cost by 60-80% for workloads with high read-to-write ratios, and it is a question most teams never ask before provisioning.
This post gives senior architects a sequenced decision framework for Azure caching in 2026: working top-down from Azure Front Door through Azure API Management response caching, the Cosmos DB integrated cache, and Azure Managed Redis, with a full SKU breakdown for the cases where a distributed in-memory cache is the correct answer. The framework also covers the migration implications of the Azure Cache for Redis retirement timeline, the VNet injection architectural break that is catching teams off guard, and the cost levers that most TCO models get wrong. Towards the end of 2024, Chipotle Mexican Grill cited Azure Cache for Redis as the component improving website performance across more than 2,500 restaurants in five countries. The framework below explains how to make that determination systematically, rather than by default.
The Product Transition Shaping Every Azure Caching Decision in 2026
The retirement of Azure Cache for Redis is not a gradual deprecation. It has published dates close enough to affect capital planning now. Azure Managed Redis (AMR) is Microsoft’s strategic replacement, built on Redis Enterprise software rather than open-source Redis, and the company is steering all new deployments there explicitly.
Where Azure Cache for Redis organised capability into feature tiers: Basic (no SLA), Standard (99.9% SLA and a replica), Premium (persistence, clustering, VNet injection), and Enterprise (modules and active geo-replication). AMR replaces that model with two independent axes: performance tier (Balanced, Memory Optimised, Compute Optimised, Flash Optimised) and size. Critically, high availability, zone redundancy, persistence, and Private Link are available across all AMR tiers and sizes. You no longer pay a feature tax to access production-grade HADR capability. For teams running Premium P2 today primarily to access persistence on a 20 GB dataset, the AMR migration will typically deliver both lower cost and better performance.
The one capability that has not carried over is VNet injection. Azure Cache for Redis Premium supported deploying a cache directly into a customer’s virtual network. AMR supports Private Link only. This is not a minor change: it touches NSG rules, route tables, DNS configuration, and in some cases application connection strings. Teams with VNet-injected Premium caches should treat the migration as a network project that happens to include a Redis component. The private endpoint patterns required are covered in our guide to Azure Private Link and Private Endpoints.
As of November 2025, AMR Balanced B50 through B350, Memory Optimised M10 through M350, and Compute Optimised X10 through X350 are GA. Sizes above 500 GB and the entire Flash Optimised family remain in Public Preview and carry no SLA. Verify GA status at deployment time for any size above 350 GB.
The Azure Caching Landscape in 2026: Four Layers Before You Reach for Redis
A production caching architecture on Azure in 2026 has at least four distinct layers available before a distributed in-memory cache becomes necessary. Working through them in sequence, rather than defaulting to Redis, is where most teams can recover the most cost.
Layer one: Azure Front Door edge caching. Azure Front Door caches responses at edge POPs distributed globally. Anything cacheable per URL and headers: static assets, API responses identical across users or varying only by cookie, and content that tolerates staleness of 30 seconds or more. All of it belongs here before it belongs in Redis. The economic argument is simple: a cache hit at Front Door costs nothing in Redis memory, nothing in Redis compute, and eliminates the origin request entirely. Front Door’s rules engine controls caching behaviour through three modes. “Override always” ignores origin Cache-Control headers and forces the TTL you specify. “Override if origin missing” applies a TTL only when the origin sends no Cache-Control directive, which works well for backends that are inconsistent about their headers. Front Door will not cache responses carrying private, no-cache, or no-store directives regardless of rules engine configuration, so responses carrying those headers correctly are safe from inadvertent caching. Maximum TTL is 366 days; absent any rule, Front Door applies a randomised TTL of one to three days. The WAF and routing considerations for Front Door at production scale are covered in our post on Azure Front Door WAF configuration.
Layer two: Azure API Management response caching. APIM supports two caching models: an internal cache (volatile, per-region, not available on the Consumption tier) and an external Redis-compatible cache that connects to any Azure Cache for Redis or AMR instance. Cache behaviour is controlled through cache-lookup and cache-store policies applied per operation. Only HTTP GET requests are cached by default, and the cache key is built from the request URL plus any headers or query parameters you configure. For workloads where the API layer sits between your application and a hot data source, APIM response caching can absorb read traffic without requiring application code changes. A newer capability that is increasingly relevant for AI-enabled applications is the llm-semantic-cache-lookup policy, which caches Azure OpenAI responses for semantically similar prompts rather than exact string matches: a meaningful cost control mechanism for high-volume AI workloads. The full APIM architecture including caching patterns is covered in our Azure API Management Enterprise Guide.
Layer three: Azure Cosmos DB integrated cache. For workloads built on the Cosmos DB NoSQL API, the integrated cache is the most underused cost-reduction tool in the Azure data platform. It is a read-through, write-through cache with LRU eviction, deployed via a dedicated gateway endpoint (distinct from your standard Cosmos DB endpoint). The cache is free to use in the sense that cache hits consume zero Request Units. For read-heavy workloads where the same item or query result is accessed repeatedly: product catalogues, user preferences, reference data, session documents. The integrated cache can reduce RU consumption by 50-80% on cached read traffic. Median cache hit latency, according to Microsoft’s own documentation, is 2-4 milliseconds. The constraint is scope: it supports only the Cosmos DB NoSQL API, it requires session or eventual consistency, and it only caches point reads and queries that are deterministic per session. It does not replace Redis for shared mutable state, distributed locking, pub-sub, or data structures beyond key-value. But for the very common pattern of an application making repeated reads to a Cosmos DB collection of semi-static data, it is almost always the cheaper and operationally simpler answer.
Layer four: Azure Managed Redis (or Azure Cache for Redis, during the transition). Once you have established that the workload cannot be served by edge caching, API gateway caching, or an integrated database cache, you need a distributed in-memory store. This is the layer that handles shared mutable state across multiple application instances: session state, distributed locking with Redlock, leaderboards and sorted sets, pub-sub and SignalR backplane, vector similarity search for AI applications, and hot-key acceleration for data access patterns that are too dynamic or too personalised for a CDN.
The in-process L1 layer. Before sizing the Redis instance, every .NET application should be layering an in-process cache in front of it. Microsoft’s HybridCache library, which reached GA in March 2025 as part of .NET 9, provides L1 (in-process MemoryCache) and L2 (any IDistributedCache, including AMR) in a single abstraction with stampede protection, tag-based invalidation, and configurable serialisation. A cache-aside pattern hand-rolled on top of IDistributedCache requires typically 30-50 lines of boilerplate per cache entry type; HybridCache replaces that with a single GetOrCreateAsync call that handles L1 hit, L2 hit, and origin fetch transparently. Reducing hot-key traffic to Redis by serving L1 hits in-process is the most cost-effective scaling technique available, and it degrades safely to in-process-only if the Redis backend is unreachable.
Technical Architecture: Azure Managed Redis SKU Selection
Once the decision framework has confirmed that a distributed in-memory cache is needed, the SKU selection question for AMR has three components: performance tier, size, and redundancy configuration.
The Balanced (B-series) tier is appropriate for the majority of production workloads. It delivers a 1:4 memory-to-vCPU ratio, which suits mixed read/write patterns, session state, and general-purpose caching. The Memory Optimised (M-series) tier shifts to a 1:8 ratio, prioritising memory density over CPU, and makes sense for large datasets with low write rates and high read throughput needs. The Compute Optimised (X-series) inverts the balance at 1:2, appropriate for CPU-intensive operations such as complex Lua scripting, large SCAN operations, or workloads running extensive Redis module queries. Flash Optimised pairs a smaller RAM working set with NVMe SSD for cold-tier storage, making sense specifically for datasets above approximately 300 GB where access patterns are skewed: hot keys served from RAM, cold keys demoted to flash. It is not the right choice for write-heavy workloads, uniform random access across a large keyspace, or workloads with a high proportion of small values and long key names, because keys always reside in RAM regardless of tier.
Redis modules (RediSearch, RedisJSON, RedisBloom, RedisTimeSeries) are available on AMR across all GA performance tiers and represent the primary architectural differentiation over the retiring Azure Cache for Redis Enterprise tiers. RediSearch combined with RedisJSON is the combination driving adoption for AI applications: it enables full-text search, vector similarity search (KNN queries), and hybrid search over JSON documents stored natively in Redis, which makes it a practical vector store for retrieval-augmented generation patterns without adding a separate embedding database to the stack.
The table below reflects the capabilities of both the retiring Azure Cache for Redis tiers and the AMR replacement, to support teams making active migration decisions.
| Capability | ACfR Basic | ACfR Standard | ACfR Premium | ACfR Enterprise | AMR (All GA tiers) |
|---|---|---|---|---|---|
| SLA | None | 99.9% | 99.9% | 99.99% (zone-redundant) | No SLA without HA; availability SLA with HA; higher SLA for zone-redundant deployments |
| Replication | None | Primary/replica | Primary/replica + clustering | Redis Enterprise | Redis Enterprise |
| Max memory | 53 GB | 53 GB | 1.2 TB (clustered) | 2 TB | 350 GB GA; 4 TB+ preview |
| RDB persistence | No | No | Yes | Yes | Yes (all SKUs) |
| AOF persistence | No | No | Limited | Yes | Yes (all SKUs) |
| Clustering | No | No | Up to 30 shards | Native | Native (OSS cluster mode default) |
| VNet injection | No | No | Yes | No | No |
| Private Link | Yes | Yes | Yes | Yes | Yes |
| Zone redundancy | No | Partial | Yes | Yes | Yes (with HA enabled) |
| Passive geo-rep | No | No | Yes | No | No |
| Active geo-rep | No | No | No | Up to 5 instances | Yes (AMR with active geo-rep) |
| Redis modules | No | No | No | Full suite | Full suite (all SKUs) |
| Entra ID auth | Yes | Yes | Yes | Yes | Yes |
| Retirement date | Sep 2028 | Sep 2028 | Sep 2028 | Mar 2027 | Current strategic product |
High availability on AMR doubles the node count and approximately doubles the base cost; it is never appropriate for non-production environments. Zone redundancy spreads nodes across availability zones within a region and is enabled automatically when HA is active in a supported region. Reserving capacity at 1-year (35% saving) or 3-year (55% saving) terms materially changes the TCO calculation, and AMR Reserved Instances are now available in over 30 regions.
Approach Comparison: Matching the Caching Primitive to the Workload
| Caching layer | Best for | Not suited for | Relative cost | Operational complexity |
|---|---|---|---|---|
| Azure Front Door | Public/cacheable responses, static assets, global user base | Personalised or authenticated content, mutable shared state | Very low (per-request pricing) | Low |
| APIM response cache | Read-heavy APIs with deterministic responses per route | Real-time data, write-behind patterns | Low (included with APIM tier) | Low–Medium |
| Cosmos DB integrated cache | Repeated point reads/queries on Cosmos DB NoSQL API | Non-Cosmos data stores, write-heavy patterns | Very low (zero RU on hits) | Low |
| AMR Balanced (B-series) | Session state, distributed locking, mixed workloads | Datasets >350 GB (use M-series), ultra-high compute (use X-series) | Medium | Medium |
| AMR Memory Optimised | Large read-heavy datasets, low write rate | CPU-intensive module queries | Medium-High | Medium |
| AMR Compute Optimised | Module-heavy workloads (vector search, Lua), high write rate | Memory-dominated workloads | Medium-High | Medium |
| AMR Flash Optimised | Datasets >300 GB, skewed access, cost-sensitive | Write-heavy, uniform random access, small values | Lower per GB at scale | Medium-High |
| In-process HybridCache | Hot-key elimination, per-instance warm path | Cross-instance shared state | Effectively zero (uses existing memory) | Low |
The comparison that catches most teams out is not Redis tier versus Redis tier but Redis versus Cosmos DB integrated cache. Both address “how do I stop hammering my database with repeated reads.” For teams already on Cosmos DB NoSQL, the integrated cache is almost always the lower-cost, lower-effort answer: it requires no additional infrastructure, no connection string management in application code, and no cache invalidation logic beyond the LRU policy the service manages automatically. The trade-off is control. Redis gives you explicit TTL management, key-level invalidation, and visibility into cache hit rates through detailed metrics. The integrated cache does not expose those controls. Teams with strict consistency requirements on cached data, where a stale hit is a business correctness problem rather than a performance nuisance, need the control that Redis provides.
Real-World Deployments
Case Study: Chipotle Mexican Grill, Restaurant / Consumer Retail
Company Name and Industry: Chipotle Mexican Grill, Restaurant / Consumer Retail
Scale Context: 2,500+ restaurants across the US, Canada, UK, France and Germany; web platform serving millions of transactions monthly
Challenge: Chipotle needed to rebuild its customer-facing website to handle peak ordering traffic at scale, with performance levels consistent across global markets. Solution Implemented: The rebuilt website runs on .NET Core with Azure as the primary platform. Azure Cache for Redis was selected as the in-memory caching layer for session data and frequently accessed application data, integrated alongside Azure SQL Database and Azure CDN.
Measurable Outcomes: The official Microsoft customer story attributes website performance improvements to Azure Cache for Redis as the in-memory caching component. Specific latency or throughput figures attributable to the Redis layer are not published in the customer story.
Source: https://www.microsoft.com/en/customers/story/787157-chipotle-retailers-azure
The following three deployments are documented on official Microsoft customer story pages and confirm Azure Cache for Redis as a named component of the architecture. Measurable outcomes cited are platform-level results and cannot be attributed specifically to the caching layer; they are presented as deployment examples rather than completed case studies in the Wednesday format.
Ahold Delhaize USA, Retail/Grocery selected Azure Cache for Redis for high-performance in-memory caching to improve responsiveness and reduce latency across its digital commerce platform. The Microsoft customer story confirms the service selection and architecture but does not publish Redis-specific throughput or cost figures.
AT&T, Telecommunications deployed Azure Cache for Redis as part of a broader Azure AI platform to keep customer interactions responsive in real time. The platform as a whole processes approximately 9 billion tokens daily and achieved 33% faster resolution times for customer agents, according to the Microsoft customer story. The 33% figure is a platform-level outcome; the Redis-specific contribution is not disaggregated in the published story.
Zooniverse, Citizen Science/Non-Profit uses Azure Cache for Redis for shared state management across Azure Kubernetes Service pods and nodes. The Microsoft customer story includes deployment speed improvements for the platform but does not publish Redis-specific latency or throughput metrics.
Cost Analysis and ROI
Caching infrastructure looks inexpensive until it is modelled at scale over three years with all cost components included. The components most Azure cost estimates omit are the ones that drive budget conversations six months into a deployment.
Reserved Instances are the single largest lever. AMR list pricing can be reduced by 35% with a 1-year RI and by 55% with a 3-year RI. Any cache running continuously in a production environment should be on at least a 1-year reserve. As explored in our post on FinOps strategy and value creation, the framework mirrors compute RI decisions: baseline stable load is reserved, burst is on-demand.
High availability doubles node count and approximately doubles base cost. For internal-facing caches where a brief unavailability triggers degraded mode rather than a customer-facing outage, non-HA in non-production and HA only in production is the right default. For session-critical workloads where cache unavailability means users are logged out mid-transaction, the HA premium is justified.
Active geo-replication is the cost item that surprises teams most. The cache itself carries a tier premium, but replication bandwidth costs have the potential to dominate at scale. As an illustrative raw-payload model, 10,000 write operations per second at 1 KB per operation represents roughly 864 GB of write data per day before protocol overhead, compression, or service-specific replication behaviour. Microsoft currently absorbs AMR active geo-replication bandwidth charges between Azure regions and does not pass them on to customers, but states explicitly that this billing may change in future. Architects should model this line item explicitly for any TCO projection beyond 18 months. Active geo-replication is justified when the application is running active-active across regions. For active-passive architectures, passive geo-replication on the legacy Premium tier or a warm standby with an acceptable RTO is the more economical choice.
For comparison: a 50 GB production cache requiring 99.99% SLA, zone redundancy, and no Redis modules, on a 3-year reserve in West Europe, costs roughly half the equivalent pay-as-you-go rate. That calculation does not include the engineering cost of migrating off a VNet-injected Premium cache before September 2028, which is commonly estimated at four to twelve weeks depending on network complexity.
The more significant ROI story for most teams is not SKU selection within Redis but whether Redis is the right layer. A high-traffic product catalogue on Cosmos DB, moved to the integrated cache, can eliminate 60-80% of RU charges on cached reads with zero Redis cost. That saving frequently exceeds any Redis tier optimisation.
Decision Framework
The decision sequence below is a flow, not a checklist. Start at the top and proceed to the next layer only when the current one cannot serve the workload.
First: does the read path produce cacheable responses? If responses are public or vary only by cookie, have deterministic content per URL, and tolerate staleness of 30 seconds or more, Azure Front Door handles this without touching application infrastructure. Configure via rules engine. Nothing further needed.
Second: is this an API response that is deterministic per route and set of query parameters? Azure API Management cache-lookup and cache-store policies absorb these reads at the gateway layer, with or without a backing Redis instance. Only proceed to Redis if responses are too dynamic, too personalised, or too low-latency for gateway-level caching.
Third: is the data store Cosmos DB NoSQL, and is the access pattern dominated by repeated point reads or queries? Cosmos DB integrated cache via the dedicated gateway endpoint eliminates RU costs on cache hits and delivers 2-4 ms median latency. Only proceed to Redis if consistency requirements exceed eventual/session, if you need key-level TTL control, or if the data store is not Cosmos DB.
Fourth: you need Redis. The workload requires shared mutable state across application instances: session store, distributed lock, leaderboard, pub-sub, vector search, or cache acceleration of a non-Cosmos data source. AMR Balanced B-series with HA enabled, zone-redundant, Private Link, and Entra ID authentication is the correct default. Deviate only when a specific driver applies: M-series for large read-heavy datasets, X-series for module-intensive compute, Flash Optimised for cost-sensitive datasets above 300 GB with skewed access.
SLA driver: 99.9% suits the majority of internal-facing systems. 99.99% is justified when Redis sits on a synchronous critical path for a customer-facing transaction: authenticated session lookup, in-line fraud scoring, real-time pricing. 99.999% via active geo-replication across three or more regions is only justified when the application itself is running active-active; otherwise you are buying an SLA the rest of the stack cannot exploit.
Module driver: only purchase an Enterprise or AMR tier with Redis modules when the use case requires them. RediSearch and RedisJSON together for vector/semantic search and AI retrieval patterns. RedisBloom for deduplication at scale. RedisTimeSeries for IoT telemetry and real-time monitoring. For pure key-value, sorted sets, lists, and hashes, Balanced B-series outperforms Premium on the legacy product at a typically lower cost.
Implementation Roadmap
Phase 1: Foundation (Months 1-3)
The immediate priority for any team with existing Azure Cache for Redis deployments is an accurate inventory of which caches are running, at which tier, and what they are being used for. Enterprise and Enterprise Flash caches have a retirement deadline of 31 March 2027, which leaves fewer than twelve months of runway from mid-2026. Those should be prioritised for migration assessment now, not at the end of 2026.
For greenfield deployments, the Phase 1 deliverable is a caching architecture decision that has worked through all four layers of the framework before provisioning. That means confirming what Front Door, APIM, and any Cosmos DB integrated cache can absorb, then sizing AMR for the residual workload only. Phase 1 also includes the Private Link design for AMR: DNS zone configuration, private endpoint subnet planning, and firewall rules. Teams migrating from VNet-injected Premium caches should plan two to four weeks for the network change alone.
Team requirements at this stage: one cloud platform engineer with networking depth for the Private Link design, plus application engineers from each service that connects to the cache.
Phase 2: Migration and Expansion (Months 4-9)
Phase 2 covers migrating existing workloads from Azure Cache for Redis to AMR. For most applications this means a connection string change, a driver update, and validation of key patterns in cluster mode. Applications that use multi-key commands with keys hashing to different slots require code changes before they are cluster-compatible; identify these early during migration assessment.
For .NET applications, Phase 2 is the natural point to adopt HybridCache. Reducing hot-key traffic to Redis by serving L1 hits in-process is the most cost-effective scaling technique available, and it improves resilience by degrading gracefully if the Redis backend is temporarily unavailable. For applications running on Azure Kubernetes Service, AMR’s OSS Cluster mode with the Azure Service Operator enables managing Redis instances via Kubernetes CRDs, integrating naturally with GitOps workflows.
Phase 2 cost deliverable: apply Reserved Instance purchasing across all caches confirmed for a production horizon of 12 months or more. The 35% 1-year and 55% 3-year savings require no architectural change.
Phase 3: Maturity (Months 10-18)
Mature caching architecture requires observability at the right granularity. The key metrics are cache hit rate (target above 90% for a warm production cache), memory fragmentation ratio (above 1.5 indicates fragmentation reducing effective capacity), and connected clients. Azure Monitor for AMR exposes these natively; alerting on hit rate drops is the earliest signal of an application behaviour change or a key pattern that has drifted out of TTL range.
AMR supports online scaling within the same performance tier: Balanced B50 can scale to B150 without downtime. Scaling across tiers requires provisioning a new instance and migrating, as the compute architecture differs. Tier selection at Phase 1 should be based on a 24-month growth model rather than current point-in-time requirements.
Future Trends and Innovation
The most significant shift underway in Azure caching is the convergence of the caching layer and the AI data layer. AMR’s support for RedisSearch and RedisJSON makes it a practical vector store for retrieval-augmented generation patterns: embeddings stored as JSON documents, indexed and queried via KNN similarity search, sitting in the same Redis instance that handles session state and hot-key acceleration. A separate managed vector database for AI workloads alongside a separate Redis for operational caching introduces connection overhead, operational complexity, and cost that a single AMR instance with modules can eliminate.
Microsoft’s investment in the llm-semantic-cache-lookup policy for APIM signals a second convergence: AI inference cost management via semantic caching at the gateway layer. Rather than caching exact prompt-response pairs, semantic caching identifies prompts that are similar enough to serve a cached response, reducing Azure OpenAI token spend on repeat or near-repeat queries. As AI-augmented APIs become standard in enterprise applications, this layer of the caching stack will become as routinely deployed as database query result caching is today.
Sustainability is a less-discussed driver that is gaining weight in procurement decisions, particularly in UK public sector and large enterprise. Flash Optimised tiers have a lower memory-to-power footprint than equivalent DRAM configurations at scale, and the Cosmos DB integrated cache, by eliminating redundant data copies, reduces the total compute footprint of the caching stack. Neither consideration should drive architecture decisions alone, but both are worth including in vendor assessments where environmental criteria carry formal weight.
Strategic Recommendations
For teams currently running Azure Cache for Redis Enterprise or Enterprise Flash, the migration project needs to start now. March 2027 sounds distant; a realistic migration programme for an estate of five to ten caches with VNet injection complexity and application code changes will consume most of the available runway if it starts in Q3 2026. Treat this as a forced migration with a hard deadline, not a discretionary modernisation project.
For teams on Standard or Premium with no immediate pressure, the September 2028 deadline gives more room, but the recommendation is to target AMR for any new cache deployed in 2026 and to plan Premium migrations as part of the next infrastructure refresh cycle rather than waiting for the final year.
The decision framework laid out in this post gives the same guidance in all cases: work top-down through the four caching layers before provisioning Redis, use AMR Balanced B-series with HA as the default, and reserve at the 1 or 3-year term for any cache in continuous production use. The teams that get this wrong spend on Redis for workloads that Front Door or the Cosmos DB integrated cache could have served for a tenth of the cost. The teams that get it right treat caching as a deliberately sequenced architectural layer rather than a single-product default.
Useful Links
- Azure Managed Redis overview and SKU documentation
- Azure Cache for Redis retirement and migration guidance
- Azure Managed Redis pricing
- Azure Cache for Redis pricing (legacy tiers)
- Azure Cosmos DB integrated cache
- .NET HybridCache GA announcement
- Azure Front Door caching documentation
- Azure Managed Redis Ignite 2025 feature announcements
- Chipotle customer story (Microsoft)
- Azure Cache for Redis best practices for Enterprise tiers
