NCache Cloud vs. Azure Managed Redis

Comparison for .NET Teams

Both are fully managed caching services on Azure. Neither asks you to provision servers, apply patches, or watch for failures. The difference that matters is where the cache runs. Azure Managed Redis runs in Microsoft's estate. NCache Cloud runs in your own subscription, on your own network.

Most of what follows comes from that one difference.

At a glance

Fully managed

Everything you'd expect from a managed service - on both products.

This section opens on parity deliberately. NCache Cloud provisions in one click, patches automatically, replaces unhealthy servers, scales at runtime, and delivers telemetry to Azure Monitor. So does AMR.

The differences start with where it all runs.

Runs 100% inside your Azure Subscription

Your subscription, your VNET, your resource group. Nothing about NCache Cloud lives outside it.

• Your network - cache servers deploy into a virtual network you choose, in a dedicated subnet isolated by your own security rules, in a managed resource group you can inspect
• Your data, logs and telemetry - all of it stays in your environment; telemetry travels Azure's private network and never leaves your subscription
• No sub-processors - no third party is introduced into the handling of your data
• No external environment to audit - certifications attest to controls a vendor operates over your data in the vendor's environment, and there is no such environment here

AMR runs in Microsoft's estate. That's what a hosted service is, and for most workloads it's entirely fine. For regulated, government, defense and financial workloads it becomes a question you answer in procurement.

Management tools inside Azure with integrated security

The NCache Cloud Portal and the NCache Management Center run on your own deployed servers, secured by your own identity provider.

• NCache Cloud Portal - the environment: scaling, maintenance window, upgrades, support access approval
• NCache Management Center - two parts. Cache management for configuring and administering your caches, and real-time monitoring dashboards refreshing every second: requests per second, hit ratio, evictions, per-server load, as they happen. That's the resolution you want during an incident, when the question is what's happening right now rather than a minute ago.
• Both run inside your network on port 9900 - so there's no vendor-hosted control plane with a path into your environment
• Secured by Entra ID, with authorisation through Azure RBAC on the managed resource group. No separate NCache permission system, and no local administrator account on the servers.

AMR is managed through the Azure portal, which is a good experience your team already knows. The difference isn't usability - it's whose management plane it is, and whose identity system secures it.

Azure Monitor integration

NCache appears in Azure Monitor as a first-class citizen, not through a bridge or an exporter you maintain.

• Metrics, logs and traces in your own workspace - queryable in Log Analytics alongside your application logs, correlatable against your application traces
• Alerts through the rules you already have - your existing routing, escalation and retention policies apply automatically
• Telemetry never leaves your subscription - it travels Azure's private network over Azure Monitor Private Link Scope
• Agent installed on every server at deployment and configured then - nothing to install, no collector to run, no exporter to maintain

Your on-call engineer doesn't learn a new tool to be paged about the cache.

NCache Support has no access until you grant it temporarily

No standing access. When support needs to look inside, you approve it - for a fixed number of hours, and it expires on its own.

• No credential outside your environment reaches into it - the control plane runs on your servers, so there's nothing external to grant access from
• Granted per incident, for one, two or four hours, revocable early and declinable entirely
• Supervised, not unattended - sessions run as a live meeting with your staff, while your administrator drives the Cloud Portal and Management Center
• No SSH - diagnostic commands run through Azure's control plane, so no port is opened, no inbound path exists, and no keys need managing

AMR is operated by Microsoft, which entails operational access to the service. That's how a hosted service works.

How security and access control work →

Support is from the people who wrote the cache

One company builds NCache, operates NCache Cloud, and answers when it breaks.

Premium 24x7 answers routine issues the same or next business day, and commits to a one-hour response on a production outage. A hard problem reaches the engineers who wrote the code.

With AMR the software and the service have different owners - Microsoft operates it, Redis builds it. Azure support is good, and for most issues that separation never surfaces. But a problem in the engine itself becomes an escalation between two companies, one you can't see into or influence.

Upgrades happen on your schedule, when you're ready

Security patches automatically. Versions when you're ready.

If you operate under formal change control, this is the difference. A change ticket has to exist, with an approver, before software moves. AMR will upgrade a major version automatically when it reaches general availability; you can defer, but for no more than 90 days. NCache Cloud waits until you decide, for as long as you need.

Microsoft's default keeps customers current, which is the right choice for most workloads. It's the wrong fit for some.

Minor upgrades are live on NCache Cloud - the cache keeps serving and nothing needs recompiling. Major versions are a planned maintenance window on both products.

Scaling at runtime

Add or remove cache servers while the cache is serving.

• Add or remove servers at runtime - data redistributes as capacity changes
• No cache or client application downtime - private DNS picks up the new membership
• Admin initiated - scaling is yours to start, not something that happens under load

Changing server profile is a migration rather than an in-place operation - a reason to size with headroom.

99.99% uptime

NCache Cloud is built to run through the failures that take a cache down - a server, a rack, a datacenter, or an entire region.

• 99.99% uptime with multi-site - two sites in separate availability zones or separate regions, synchronised by Bridge, both serving
• Partition-Replica and Replicated caches - a second copy of every item on another server
• Unhealthy servers restart automatically - NCache runs as the main process in its container under a restart policy, so a process failure recovers in seconds; if the VM is unhealthy, VMSS replaces it
• Rolling patches, no downtime - one server at a time, each verified healthy before the next

AMR offers a contractual uptime SLA and NCache Cloud does not - up to 99.99%, and up to 99.999% across three or more regions with active geo-replication. We don't offer one because NCache Cloud runs in your subscription, where your own changes can reach it.

What we commit to contractually is response: with Premium 24x7, same or next business day for routine issues and one hour for a production outage.

If a vendor uptime SLA is a hard requirement, AMR meets it and NCache Cloud doesn't.

Multi-region deployment with WAN replication

Deploy two regions from the same wizard, and NCache Bridge keeps them synchronised across the WAN.

• One click, two regions - deployed from the same wizard as a single site, running in 20 minutes
• Both sites active, synchronised by NCache Bridge. Conflicts resolved by last-update-wins or a handler you write, and each site persists independently.
• What you provide - a second virtual network in the target region, with peering created at deployment. Cross-region replication traffic is billed to you by Azure and scales with write volume.

AMR offers active geo-replication. Comparable capability on both sides.

Your own code on the cache servers

Because the servers are in your subscription, they can run your code - .NET assemblies deployed through the Management Center.

• Read-through, write-through, write-behind - a cache miss loads from your database without a round trip back to your application, and updates write back either synchronously or with your application returning immediately
• Loader, refresher - warm the cache at startup so the first user after a deployment doesn't pay for a cold cache, and keep it current against its source
• Bridge conflict handler - your own rule when two sites write the same key

AMR has no equivalent, and structurally can't: no hosted multi-tenant service can execute customer code on its own infrastructure. These aren't patterns that are harder on a hosted cache - they're patterns you can't implement on one.

Assemblies target .NET rather than .NET Framework, since the cache servers run Linux.

Plans and multi-cloud

Hourly, a 30-day trial, or bring your own license - and the same license works on AWS.

• Hourly - pay-as-you-go through Azure Marketplace, with no licensing to manage. One-year committed pricing through a private offer.
• Free Trial - 30 days, complete product, no size limit, extendible on request
• BYOL - use an NCache license you already own. AMR is Azure-only, so a multi-cloud estate runs one cache from one license pool.

Software and infrastructure bill separately. You pay Microsoft directly for the VMs at your own negotiated rate, and your own Reserved Instances apply to them - pay-as-you-go software on three-year reserved hardware.

AMR offers reservations for the AMR service and bills networking separately, so neither model is a single number. The difference is which components you can see and negotiate.

Advanced .NET caching

Built for .NET, not adapted for it. The cache servers are 100% native .NET.

Client Cache keeps a near-cache inside your application process, synchronised with the distributed cache. Full Data Client Cache preloads an entire reference dataset next to your application and lets you query it with SQL or LINQ - data served from your own process never crosses the network. AMR has no equivalent.

• SQL and LINQ queries - search cached objects by their properties, not just by key
• Tags and Named Tags - organise and retrieve related data as a group
• EF Core caching - cache query results and entities through extension methods
• IDistributedCache and ASP.NET Core - a drop-in with no code change, plus sessions with multi-site support and intelligent locking
• SignalR backplane, Pub/Sub messaging with item-level and cache-level events
• Clients - .NET 8+, .NET Framework 4.8, Java, Node.js and Python

Redis has excellent .NET clients and millions of applications use them successfully. The difference isn't client quality - it's that these capabilities exist at all.

Where AMR is the better choice

Stated plainly, because the rest of this page isn't worth much without it.

• You need a vendor uptime SLA - AMR has one, NCache Cloud doesn't
• You want zero infrastructure in your subscription - some teams deliberately want no VMs, no subnets, nothing in their account
• You're already on Redis and migration cost outweighs the differences
• Your team knows Redis and doesn't want a second thing to learn
• You need Redis-specific modules or ecosystem tooling
• Vector search and semantic caching - AMR ships these today
• Community corpus - more Stack Overflow answers, more blog posts, more third-party examples

Migrating from Azure Cache for Redis

Azure Cache for Redis is being retired - Enterprise and Enterprise Flash on 31 March 2027, Basic, Standard and Premium on 30 September 2028. Microsoft's recommended path is Azure Managed Redis.

If you're on one of those tiers, you're migrating either way.

The switching cost that normally keeps you where you are - the testing, the rollout, the risk - has to be paid regardless. Which makes this the one moment when evaluating an alternative costs no more than the migration you've already committed to.

Two things make a move to NCache Cloud less work than it might look. If your application uses IDistributedCache, it's a configuration change rather than a code change. If it uses Redis APIs directly, the Redis Wrapper API covers most of the surface.

Frequently Asked Questions (FAQ)

Is NCache Cloud as managed as Azure Managed Redis?

Yes. Provisioning, patching, monitoring, health-based server replacement, scaling and high availability are all handled. The difference is where it runs, not how much you have to do.

Does NCache Cloud support the Redis protocol?

There's a Redis Wrapper API to reduce migration effort, but NCache Cloud is not a Redis-protocol server.

Which is faster?

Both are in-memory distributed caches, and real-world performance depends far more on your topology, serialisation and access patterns than on the product. The structural difference worth knowing is Client Cache — data served from your application's own process doesn't cross the network at all.

Can I use my Azure commitment?

Yes, for the infrastructure. The VMs bill directly to your Azure agreement.

What happens to my data if I stop using NCache Cloud?

Delete the managed application and the environment leaves your subscription. There's nothing to retrieve, because nothing of yours was ever held anywhere else.

Does NCache Cloud run on AWS?

Yes, with the same BYOL license.

Can Microsoft engineers see my cache data in Azure Managed Redis?

AMR is operated by Microsoft, which entails operational access to the service. Microsoft's documentation is the right source for the specifics.