On September 22, the AKS Engineering Blog announced the public preview of Flex Nodes for AKS: a way to attach customer-managed virtual machines or bare-metal hosts — in another Azure region, at the edge, or fully on-premises — to an existing AKS cluster's control plane as regular node pool capacity. Three use cases anchor the pitch: regional GPU/CPU capacity that's sold out in your primary region, unifying distributed compute under one control plane, and — the one this site cares about — letting "regulated workloads in healthcare, financial services, and the public sector" keep data on specific hardware while still running Kubernetes lifecycle operations from Azure. The docs put it plainly: "Operators can then use node selectors and taints to pin workloads that must remain local to that hardware."
That third use case is the one worth stopping on, because it's a residency claim, and residency claims deserve the same scrutiny as any sovereignty feature that ships from Microsoft. I went through the actual Microsoft Learn documentation set — the overview, the planning guide, the networking walkthrough, and the support policy — instead of stopping at the blog post. It's a very different document set than the announcement.
What was actually announced
Confirmed against Microsoft's own documentation:
- A flex node runs a lightweight agent, not a standard AKS provisioning flow. The agent bootstraps the host, joins it to the cluster inside an isolated environment, and keeps it reconciled against the state AKS requests — without AKS ever provisioning or owning the underlying machine.
- Authentication runs through system/user-assigned managed identity, Azure Arc managed identity for off-Azure hosts, or a service principal — with two separate, narrowly scoped identities per node: one for Azure-side configuration and status, another for Kubernetes-side node lifecycle.
- Linux-only, and both amd64 and arm64 are supported. Windows flex nodes aren't offered.
- There is no managed pod network. Azure's built-in CNI options (Azure CNI, Cilium) don't extend to flex nodes in preview. Microsoft's own walkthrough has you install a third-party overlay — Unbounded-Net — and hand-plan five non-overlapping CIDR ranges across the AKS and flex node networks yourself, or build your own WireGuard gateway if you don't already have Layer 3 reachability.
- The Azure portal doesn't support this feature. Flex node pools are CLI/API only, and a cluster with a flex node pool can't be stopped.
Why it matters for sovereignty-focused shops
The capacity story is legitimately useful on its own — bursting to another region when your GPU SKU is sold out, or running lab hardware as real node capacity, doesn't need any sovereignty framing to be worth adopting. But Microsoft chose to put data residency in the first paragraph of the announcement, next to healthcare and financial services, which puts this squarely in scope for anyone building the case for Azure-managed Kubernetes over regulated on-premises data. If it holds up, it's a genuinely different shape than Azure Local or Arc-enabled Kubernetes: one AKS control plane, one set of lifecycle operations, spanning cloud and regulated on-prem hardware without standing up a second cluster.
The gap the announcement doesn't name: nothing here enforces residency
Here's what the shared-responsibility table in the support policy actually says Microsoft owns versus what you own. Microsoft: the AKS control plane, the flex node agent, the bootstrap workflow, the documented management interfaces. You: host provisioning, capacity, hardware, firmware, and recovery; the entire operating system, including patching and privileged access; all external network connectivity — routing, firewalls, DNS, proxies, VPN or ExpressRoute; installation, configuration, and upgrades of the third-party Unbounded-Net networking layer; and "application deployment, configuration, security, monitoring, backup, **data protection**, and troubleshooting" for every workload you run.
Node selectors and taints — the mechanism the announcement names for pinning regulated workloads — are Kubernetes scheduling hints, not a data-plane control. They tell the scheduler where a pod is allowed to run; they don't stop a pod's traffic from crossing the Unbounded-Net overlay you configured yourself, they don't isolate storage, and they don't get audited the way a platform-enforced residency boundary would be. Compare that to what "data residency" means everywhere else in Microsoft's own sovereignty documentation — the Sovereign Public Cloud control principles describe residency as a platform-level commitment about where a regional service will and won't store data. Flex Nodes ship none of that. What they ship is a scheduling hint, sitting on top of a network you built with a third-party overlay, on a host Microsoft's own docs say it won't touch "without your permission and assistance."
None of that makes Flex Nodes bad engineering — the honesty of the support-policy table is actually refreshing next to some sovereignty marketing. But it does mean the "data residency" line in the launch announcement is doing more rhetorical work than the architecture underneath it supports. If an auditor asks how residency is enforced, "our engineers configured a node selector" is not the same conversation as "the platform guarantees it."
What's not answered yet
- No GA timeline. The announcement calls this "available today in public preview" with no committed date, and the support policy is explicit that preview features "aren't meant for production use" and get best-effort support only.
- No regional availability list in the announcement itself — Microsoft Learn's planning guide points to a regional-availability section instead of stating it inline, so it's clearly still narrow and worth checking per subscription before you plan around it.
- No compliance or audit documentation. Nothing published yet maps Flex Nodes against NIS2, DORA, or any Microsoft Sovereign Cloud control — unsurprising for a two-day-old preview, but it means citing this feature in a compliance narrative today is citing a promise, not an attestation.
- Unbounded-Net's own security posture is undocumented outside the walkthrough. It's the component actually carrying pod traffic between your regulated hardware and Azure, and it isn't a Microsoft-shipped, Microsoft-supported network fabric — it's a customer-installed CLI plugin from a separate GitHub repository.
Who should care
Teams chasing GPU or CPU capacity outside a sold-out region, or unifying scattered edge and on-prem compute under one AKS control plane, should look at this now — that part of the pitch is straightforward and doesn't depend on any residency claim holding up. Anyone about to cite Flex Nodes in a data-residency or regulated-workload proposal should read the support policy before the blog post, and treat node selectors and taints as scheduling convenience, not as the compliance control a regulator will accept.
Flex Nodes can put a workload on the hardware you choose. Whether it stays there, and whether anything actually enforces that, is a responsibility line Microsoft drew squarely on your side of the table.
I'm tracking whether GA brings any platform-level residency enforcement — network policy, storage isolation, an auditable boundary — or whether this stays a scheduling feature wearing a compliance narrative. If you want that the moment it's confirmed, or you're evaluating Flex Nodes against Azure Local or Arc-enabled Kubernetes for a regulated workload right now, subscribe to Sovereign Cloud Watch or find me on LinkedIn.