The last piece I wrote on Azure Local 2608 covered Arc Site Manager, portal-driven scale-out, and GPU management from Azure — the cloud-connected fleet-ops half of that release. There's a fourth item in the same changelog that deserves its own treatment, because it answers a question I hear constantly from sovereignty-minded architects: how do I get high availability for a regulated site without replicating data to a second physical location I don't control?
The answer, as of 2608, is rack aware clustering — now in preview.
What was actually announced
Confirmed against Microsoft's own documentation:
- Two racks, one cluster, one storage pool. Nodes are split across two physical racks — in different rooms or buildings — connected by a high-bandwidth, low-latency link. Each rack functions as its own local availability zone, spanning everything from the OS to Azure Local VM placement.
- Synchronous replication, not backup. Data copies are distributed evenly between the two racks over a dedicated storage network intent. If one rack goes down entirely, the other keeps serving without a failover script or a second site to reach.
- Scale: 1+1 up to 4+4. Supported configurations run from a 2-node cluster (two-way mirror, 50% storage efficiency) up to 8 nodes split 4-and-4 (four-way mirror, 25% efficiency, tolerating three drive/node faults or a full rack loss).
- A hard latency budget. Round-trip latency between racks must be ≤1 ms. Bandwidth requirements scale with node count and NIC speed — an 4+4 cluster on 25 GbE needs roughly 200 Gbps of dedicated storage bandwidth. This is a same-building or same-campus feature, not a metro-DR feature.
- VM placement policy per workload. You assign VMs to a zone and choose strict placement (stays put, no failover) or non-strict (fails over to the other zone) based on how critical the workload is.
Microsoft's own use cases are specific and telling: manufacturing plants, hospitals, airports — sites where the whole point is that the failure domain has to stay inside walls you control.
Why it matters for sovereignty-focused shops
Most HA/DR conversations in Azure default to "put the second copy in another region." For a lot of the workloads this site covers — regulated data under NIS2, DORA, or a national baseline like the Dutch BIO — that default is exactly the problem: the data isn't allowed to leave the facility, let alone the country, just to get resilience. Rack aware clustering reframes the fault domain as a rack, not a region. You get protection against a real, common failure mode — a power distribution unit, a ToR switch stack, a room-level incident — without ever asking the compliance team whether a second location is in scope.
It's also a cleaner sovereignty story than the alternative most sites were stuck with before: either accept a single point of failure at the rack level, or build two entirely separate Azure Local instances and handle replication and failover yourself at the application layer. Rack aware clustering gets both racks under one Azure Local instance, one control plane, one set of Arc-enabled resources.
The tradeoff nobody's flagging: it forces you onto Active Directory
Here's the detail that matters most for this audience and isn't getting airtime. Azure Local supports two identity models: AD-joined, or local identity with Azure Key Vault — the "AD-less" path Microsoft has been pushing specifically for minimal-footprint edge and OT sites that don't want to run or maintain a domain controller on-site.
Rack aware clustering doesn't support local identity with Key Vault. Deploy through the portal and select both options together, and you get an explicit error — Active Directory is the only supported identity model for this release. For a factory floor or a remote site that adopted AD-less deployment precisely to avoid the operational overhead of a domain controller, rack-level resilience currently comes with a requirement to bring AD back into scope. That's a real architectural decision to surface early, not something to discover mid-deployment.
What's not answered yet
- No disconnected-operations statement. Same gap as the rest of the 2608 release: Microsoft's disconnected operations docs don't mention rack aware clustering, and it isn't listed in the narrow disconnected service surface. Whether a fully air-gapped site can use this architecture at all is currently unstated.
- No conversion path. This is new-deployment-only. Existing standard clusters can't be converted to rack aware — so today's decision is a greenfield one, not something you retrofit into a live estate.
- Preview means no GA date and no SLA commitment yet. Worth prototyping now, not worth putting in front of a production regulated workload until it graduates.
Who should care
Architects designing single-site Azure Local deployments for factories, hospitals, government facilities, or any regulated site where a second physical location isn't an option — this is the first Azure Local architecture built specifically for that constraint. If your site already runs AD-less by design, budget time to work through what bringing AD back in means before you commit to rack aware clustering as the resilience answer.
Two racks, one storage pool, zero data leaving the building — but only if you're willing to run Active Directory to get it.
I'm adding this to the lab list alongside the disconnected AI work — specifically to test whether rack aware clustering and disconnected operations can coexist, since neither doc set currently says. If you want that write-up when it's ready, or you're weighing rack aware clustering against a two-site design right now, subscribe to Sovereign Cloud Watch or find me on LinkedIn.