Skip to main content
GenioCT

Does Your Organisation Need Azure Local? A CIO Decision Guide

By Jeremy Genicot | | 10 min read
Azure Azure Local Hybrid Cloud Strategy

In this article

Three small architectural models on wooden presentation trays on a boardroom table, next to a closed folder, a pen, and reading glasses: three infrastructure options prepared for a decision.

In short: Azure Local makes sense in three circumstances: a workload must remain physically close to a site, the organisation has deliberately chosen to keep operating a private datacenter, or the Azure public control plane itself must not be an operational dependency. Outside those cases, a normal Azure region is usually simpler, more flexible, and less demanding to operate. Buying Azure Local is a decision to remain an infrastructure operator; this guide gives you the six questions that test whether your situation justifies it. The technical companion covers node counts, licensing mechanics, and architecture detail.

At some point recently, someone in your organisation started saying “Azure Local” in meetings. Perhaps it came from your architects, perhaps from a hardware vendor, perhaps from a slide about the VMware contract renewal. It sounds like a technical infrastructure choice. It is actually a long-term operating-model decision, there are only three strong reasons to make it, and this piece exists to test whether yours is one of them.

What Decision Are You Actually Making?

Azure Local brings an Azure-style infrastructure management and operating model to hardware in a site your organisation controls: your building, a colocation facility, or an edge location. Microsoft supplies the software, the release train, and the management tooling your teams already know from Azure. L1 and L2 use Microsoft’s published per-core Azure Local meters, billed to the Azure subscription your finance team already processes; disconnected L3 uses capacity-based annual-term pricing, also billed monthly through Azure, with current pricing and qualification handled through your Microsoft account team. Each option gives you more control over where workloads run, and leaves more of the infrastructure with you: capacity, platform availability, updates and lifecycle, physical security, networking, recovery, and the people who own all of that at three in the morning.

That is the commitment shared by every variant, and it belongs on the table before any discussion of tiers. Whoever signs for Azure Local is signing to remain an infrastructure operator, with a better toolchain and a different vendor relationship. Microsoft does not run the hardware, replace failed disks, or staff a night shift on your behalf.

The Three Business Cases

Microsoft prices the platform in three levels, L1 to L3, but the levels only make sense mapped to the business cases they serve.

Business caseAzure Local levelThe commitment
Operational continuity and local compute at a siteL1Small clusters per site, periodic Azure connectivity required
A strategic private-datacenter platformL2Datacenter-scale hardware and a standing platform team
A locally controlled sovereign environmentL3Microsoft approval to buy, dedicated management hardware, specialist operations

These are commercial and operating levels rather than three mutually exclusive hardware designs: the underlying Azure Local architecture and the connected-versus-disconnected operating mode are separate decisions.

Operational continuity at a site. The local-operations case: a factory line or shop that must keep working through a WAN outage, processing that must sit next to equipment for latency reasons, and workloads whose data volumes make constant transfer to a region impractical. One boundary belongs in the business case: a connected system must synchronise with Azure at least every 30 days, and beyond that it enters reduced functionality: existing VMs continue to run, but new VMs cannot be created until connectivity returns. This is the most established of the three business cases, and usually the easiest one to justify in operational terms.

A strategic private-datacenter platform. VMware licensing has made this newly relevant, but the broader decision is whether your organisation still requires a private datacenter at all. If the deliberate answer is yes, L2 offers datacenter-scale infrastructure, independent growth of computing and storage, supported existing storage that can sometimes be reused, and one management model across your regional and local platforms, with tooling to move existing virtual machines across. The decision is strategic rather than technical: you are choosing to keep operating a datacenter with a different vendor relationship, instead of leaving the datacenter business.

A locally controlled sovereign environment. The third case is a platform that can operate without any runtime dependency on Azure’s public control plane, including in a fully air-gapped configuration. Microsoft deliberately gates it: an approved agreement, a stated business need, specific hardware, and an approval process stand before the purchase. Its fixed costs begin with a separate three-node management cluster that cannot host business workloads, and its operating model absorbs everything a cloud provider’s operations team normally does for you. Procurement, software provenance, support, and imported updates still involve Microsoft; what disappears is the runtime dependency, and only that.

Six Questions Before Anyone Orders Hardware

1. What business process actually requires local compute?

Ask what would materially fail: because of latency, bandwidth, connectivity, or an enforceable regulatory requirement. “Which workloads would we like to keep nearby” produces a different and much longer list than “which processes break”, and only the second list justifies hardware.

2. How long must it operate without Azure?

A site that must survive a WAN outage of hours or days points at the connected first case. A requirement to operate indefinitely with no path to Azure changes the product, the cost structure, and the operating model entirely. Within Azure Local, that means the disconnected L3 path.

3. Are we deliberately staying in the datacenter business?

Azure Local modernises the platform; the datacenter, with its capacity planning, hardware lifecycle, and staffing, remains. If nobody would defend “we are a datacenter operator” as a strategy statement, be suspicious of any proposal that quietly assumes it.

4. Which named team owns it?

Which team patches this platform every month, by name? The same test applies to capacity, hardware support contracts, security, backup, recovery testing, certificate lifecycle, and after-hours incidents. If nobody can name the internal team or managed partner accountable for those responsibilities, the proposal is not ready for approval. Either establish that operating model or reassess whether the workload belongs on infrastructure you own.

5. What is the full set of alternatives?

Compare against a normal Azure region, but also against staying on the current hypervisor, another virtualisation platform, hosted private cloud, colocation, selective modernisation of the applications themselves, and simply decommissioning or replacing with SaaS. A business case that compares Azure Local only with doing nothing is structurally biased toward approving it.

6. What is the exit plan?

If the platform no longer fits in five years, can its workloads move to a region, another hypervisor, or another provider without a second wholesale infrastructure programme? Azure Local changes the vendor relationship; it does not eliminate vendor concentration, and an exit that was never designed is not an exit.

What Azure Local Does Not Solve

A platform decision this visible attracts hopes it cannot carry. Azure Local does not modernise applications; the legacy systems that arrive on it leave it as legacy systems. It does not staff your datacenter or absorb the operating burden; the people line usually decides the business case, and it stays on your side. It does not provide disaster recovery by existing; resilience remains a design you build and test. It does not reduce dependence on a single software vendor; it deepens the Microsoft relationship while changing its shape. It does not bring the full Azure service catalogue on-premises; workloads built heavily around managed Azure services often need redesign against a much narrower local service set. And it does not, by itself, make anything compliant. Compliance comes from the controls you implement, the way you operate them, and the evidence you can produce; the platform confers none of those, and a workload classification exercise decides which requirements genuinely bind which systems. In our experience, most workloads presumed to need local infrastructure survive contact with the actual regulation text.

The Decision at a Glance

SituationLikely directionMain warning
A factory or site must continue through WAN failureConnected Azure Local, usually L1Still requires periodic Azure connectivity
A large VM platform must remain on-premisesEvaluate L2Compare honestly with migration and alternative hypervisors
The Azure public control plane must not be a runtime dependencyEvaluate L3Dedicated management capacity and specialist operations
The requirement is EU data residency, without a disconnected-operation requirementUsually an Azure region firstResidency is not the same as disconnection
Workloads are elastic or heavily PaaS-dependentAzure regionLocal capacity and service limitations work against them
No team owns platform operationsAzure region or a managed alternativeAzure branding does not transfer operational accountability

On cost, three lines make up the bill and they are not the same size. Hardware is capital expenditure from an approved catalogue. Software is the per-core monthly fee plus consumed services; eligible Windows Server Datacenter licensing can remove the L1 host service fee, although guest licensing, support, and the surrounding management services still belong in the business case. People are usually the least visible line and often the one that decides the business case.

Azure Local Terms in One Minute

TermPlain-language meaning
Azure LocalMicrosoft’s platform for running VMs, containers, and selected Azure services on customer-controlled hardware
HyperconvergedServers provide both compute and storage as one cluster
DisaggregatedCompute and external storage grow separately
Multi-rackA larger prescriptive architecture spanning several integrated racks
Connected operationsAzure’s public control plane manages the local platform
Disconnected operationsA local control plane manages the platform without requiring ongoing Azure connectivity
Azure ArcThe Azure technology that makes local resources visible and governable through Azure tooling
Control planeThe management layer used to deploy, configure, and govern workloads
Data planeThe workloads, application traffic, and business data themselves
Air-gappedOperated without a live network path to an external environment
Azure Hybrid BenefitA licensing benefit that can reduce Azure Local host charges when eligible Windows Server licences are used

The Decision Sequence

Run it in this order, because each step makes the next one cheaper. First, classify the workloads: which requirements genuinely bind which systems, in the regulation’s own words. Second, choose the operating model: is your organisation an infrastructure operator by strategy, by accident, or not at all? Third, compare the full cost and risk of the surviving candidates against the complete set of alternatives, with the people line included.

Most organisations that run this sequence honestly end with fewer local workloads than the first meeting assumed, and the ones that remain are the ones with a defensible answer to all six questions. That outcome is a success in both directions: the workloads that stay local have a real reason, and everything else avoids an operating obligation a region would have carried for you.

When the decision on your table is real, the technical companion gives your architects the tier limits, licensing mechanics, and caveats that belong in the business case. Read them together: this piece is the why, that one is the how much and the how.

Looking for Azure architecture guidance?

We design and build Azure foundations that scale - landing zones, networking, identity, and governance tailored to your organisation.

Start with a Platform Health Check - results within 1 week.
Talk to an Azure architect
Share this article

Start with a Governator-powered Azure Health Check

Not sure where to begin? A quick architecture review gives you a clear picture. No obligation.

  • Risk scorecard across identity, network, governance, and security
  • Top 10 issues ranked by impact and effort
  • 30-60-90 day roadmap with quick wins