Azure Cache for Redis vs Memcached
Azure positioned around Redis as the canonical in-memory layer long before the rest of the industry agreed. There is no managed Memcached. The interesting questions are which Redis tier, whether to move to the new Azure Managed Redis service, and how the Redis SSPL license affects what Azure can ship.
The five tiers and what they actually mean
Azure Cache for Redis presents five SKUs and the differences matter both for capability and for cost. The Basic tier is a single VM with no SLA, intended for development and proof-of-concept work, priced from a few dollars per month. The Standard tier is a primary-replica pair on dedicated VMs with a 99.9% SLA, suitable for production workloads that can tolerate a few minutes of failover downtime. Both Basic and Standard use the open-source Redis codebase managed by Microsoft.
Premium adds the features production teams actually want: clustering (sharded keyspace across multiple shards), persistence (RDB snapshots to Azure Storage, AOF for write-ahead logging), VNet integration (private network deployment), and geo-replication (one-way replication between paired regions). Premium also offers larger instance sizes (up to 530GB on the largest C8 nodes per Azure documentation). The Premium tier is where most serious Azure-hosted Redis workloads land.
Enterprise and Enterprise Flash are powered by Redis Inc.'s Redis Enterprise software, which Microsoft licenses and embeds. Enterprise adds the Redis modules (RediSearch for full-text and vector search, RedisJSON for native JSON, RedisTimeSeries, RedisBloom) and active-active geo-replication via CRDTs. Enterprise Flash uses NVMe storage to extend memory tiering for very large datasets where the cost per GB on pure RAM would be prohibitive. Enterprise tiers are noticeably more expensive but bring functionality the open-source tiers cannot.
Azure Managed Redis: the path forward
Azure Managed Redis went generally available in May 2025 as the next-generation Azure offering. The service is built on the Redis Enterprise codebase across all tiers (not just the legacy Enterprise SKU), with a simplified pricing model, integrated tooling for Azure-native compute services, and sub-millisecond latency targets. Microsoft positions Azure Managed Redis as the recommended choice for new Redis workloads on Azure, with Azure Cache for Redis remaining supported but in maintenance mode for new development.
The migration path from Azure Cache for Redis to Azure Managed Redis is documented as in-place with a few caveats: the client protocol is unchanged (existing Redis clients work without modification), the data migration is handled by Microsoft tooling, but the SKU and billing entity changes, which can affect cost reporting and reserved-instance contracts. For teams running large Azure Cache for Redis fleets, the migration is non-trivial mostly in the operational and finance dimensions, not the technical one.
Pricing on Azure Managed Redis is currently structured around "compute units" that map roughly to vCPU and memory bundles, broadly comparable to Azure Cache for Redis Premium and Enterprise tiers on equivalent capacity. The clearer differentiator is that Azure Managed Redis includes Redis modules (Search, JSON, vector search) across all tiers, not just Enterprise. For applications that want vector search for RAG and AI workloads, this matters because the Redis 8.0 vector set support is bundled.
The license question and Garnet
When Redis switched to SSPL in March 2024, Microsoft's position became interesting. As an embedder of Redis Enterprise (licensed from Redis Inc.), Microsoft has a commercial agreement that lets it offer Redis as a managed service regardless of upstream license, so Azure Cache for Redis and Azure Managed Redis are unaffected by the SSPL/AGPL fork in any visible way. AWS, by contrast, was running on Redis OSS without a Redis Inc. license and had to either pay up, switch, or fork.
Microsoft Research published Garnet in March 2024 as an alternative implementation: a RESP-compatible cache server with MIT license, multi-threaded throughput, and storage tiering. Garnet is not a managed Azure service and Microsoft has not announced plans to make it one. It is positioned as an open-source research project and an alternative for teams that want a Redis-compatible cache without the license complications of Redis OSS or the cost of Azure Cache for Redis. For Azure-native deployments, you would run Garnet on Azure VMs or AKS yourself.
The strategic takeaway: Azure's first-party Redis offerings will keep working regardless of how the Redis license drama evolves, because the commercial relationship insulates Azure from the upstream license terms. The pricing might shift if the underlying licensing economics change, but the service availability will not. For Azure customers this is good news: pick the Azure tier that fits your workload and do not worry about the broader Redis-vs-Valkey landscape unless you need the Valkey BSD posture specifically.
Running Memcached on Azure if you really want to
If your workload specifically needs Memcached on Azure, the path is to run it yourself on Azure VMs (Linux VMs, install Memcached from the distribution package), on AKS (a Memcached StatefulSet with appropriate node-affinity and resource limits), or in Azure Container Apps. None of these are managed services; you handle patching, capacity, monitoring, alerts, backup-or-not decisions, and HA strategy yourself.
For most workloads that thought "we want Memcached on Azure," the better question is what specifically you need from Memcached. If it is multi-threaded throughput for ephemeral cache, both Azure Cache for Redis Premium (with I/O threading enabled) and Azure Managed Redis hit competitive throughput on the same node sizes. If it is operational simplicity, the managed Redis offering is simpler than running your own Memcached. If it is the BSD license posture, you would run Memcached yourself or wait for any future Azure announcement of managed Valkey (none announced as of May 2026).
The realistic recommendation for Azure customers in 2026 is: use Azure Managed Redis for new workloads, stay on Azure Cache for Redis Premium for existing stable production, and consider Garnet only if you have a specific reason (license, throughput experiment, multi-tenant isolation) that justifies operating it yourself.
FAQ
Why does Azure not have a managed Memcached?
Azure's strategic bet on Redis as the canonical in-memory layer goes back to the 2015 acquisition-adjacent partnership with Redis Labs (now Redis Inc.). Azure Cache for Redis launched as a first-party service, and the company has continued to invest in the Redis Enterprise tier rather than diversify. For Memcached on Azure you run it yourself on VMs or AKS, or you use Azure Managed Redis instead.
Basic vs Standard vs Premium vs Enterprise?
Basic is a single VM with no SLA; for development only. Standard is a primary-replica pair (HA, 99.9% SLA). Premium adds clustering, persistence, VNet integration, geo-replication, and bigger instance sizes. Enterprise (powered by Redis Enterprise from Redis Inc.) adds active-active geo-replication and the Redis modules (Search, JSON, TimeSeries, Bloom). Enterprise Flash extends to NVMe-backed memory for very large datasets at lower cost per GB.
What is active-active geo-replication?
Multiple Redis Enterprise clusters in different Azure regions accept writes simultaneously, with conflict-free replicated data types (CRDTs) resolving conflicts. Powered by Redis Inc.'s Redis Enterprise CRDB technology. Only available on the Enterprise SKU. Used by global apps needing sub-millisecond reads from every region with full write availability.
Azure Managed Redis vs Azure Cache for Redis?
Azure Managed Redis launched May 2025 as the next-generation Azure offering. Built on Redis Enterprise codebase, simpler pricing, sub-millisecond latency targets, integrated with Azure compute services. Azure Cache for Redis remains supported but new workloads are guided to Managed Redis. Both expose the Redis protocol; client code is unchanged.
What about Garnet, the Microsoft fork?
Garnet is Microsoft Research's RESP-compatible cache server, open-sourced March 2024 (MIT licensed). It is a research project and an alternative implementation, not a replacement for Azure Cache for Redis. Garnet's selling points are multi-threaded throughput and storage tiering. Not a managed service; you run it yourself on Azure VMs or AKS.