How Azure Local, Foundry Local, AKS, and disconnected operations point to a new model for cloud architecture.
It started with a joke. When AKS on bare metal went into public preview at Build 2026, a colleague commented: “We’ve gone full circle - we’re deploying Kubernetes on our own servers again.”
The joke works because it reflects something real. Looking back through the Microsoft Build 2026 announcement list, I kept seeing the same pattern: Azure capabilities moving closer to the places where control matters — local infrastructure, disconnected environments, edge locations, and sovereign boundaries.
The signals were consistent:
The Build announcements made the pattern easier to see, but the direction predates Build. Earlier milestones already pointed in the same direction:
Together, these milestones point in the same direction: Azure is extending beyond centralized regions into local, sovereign, and disconnected environments.
Adaptive Cloud is the operating model behind that shift.
A useful way to approach sovereignty is through two complementary views.
In Looking at Sovereignty Requirements with Azure, John Savill frames sovereignty as a set of considerations across the system: legal, identity, control plane, data, and infrastructure.
That framing is useful because it addresses where sovereignty applies. It helps identify the parts of the architecture involved in control: who can access systems, where operations are executed, how keys are managed, where data is processed, and who owns or operates the underlying environment.
Each layer introduces a different dimension:
Microsoft's Digital Sovereignty documentation complements that view by describing what kind of control is required through three pillars:
Together, these views create the lens for the rest of the article.
Sovereignty is a set of control decisions distributed across layers.
That is why deployment posture matters.
Adaptive Cloud is the model that lets Azure capabilities be placed across different control boundaries.
Microsoft uses Adaptive Cloud to describe a common platform model across cloud, edge, hybrid, multicloud, and distributed environments. Azure Arc is central to that direction because it extends Azure management and governance beyond Azure regions.
For sovereignty, this matters because control is distributed across layers: data, identity, control plane, operations, compute, and infrastructure.
A useful way to visualize this is as a deployment continuum:
I use this as an architectural lens to interpret the direction we are seeing, rather than as a formal Microsoft product taxonomy.
The continuum represents posture, not hierarchy. Each posture is valid for different requirements. Global Cloud optimizes for hyperscale and managed operations; Local and Disconnected Cloud optimize for proximity, autonomy, and control.
It turns governance and policy concerns into technical placement decisions:
Adaptive Cloud provides the operating model for making those decisions consistently.
The same architectural layers remain in play across the continuum. What changes is where each layer runs, who operates it, and how much independence it requires.
This is the bridge between sovereignty as a requirement and Azure as a deployable cloud platform.
The capabilities below are at different levels of maturity and availability. Some are generally available, some are in preview, and some apply only to specific geographies, hardware configurations, licensing models, partner deployments, or eligible customer scenarios.
Taken together, these capabilities show the platform direction, while their availability, maturity, and applicability vary by scenario.
Azure Local shifts the infrastructure boundary by bringing Azure capabilities into customer-owned environments.
Use Azure Local documentation for the full documentation set, What is Azure Local? for the general overview, and Sovereign Cloud Azure Local overview for sovereignty-specific scenarios.
Disconnected operations shift the control-plane boundary by allowing Azure Local environments to be deployed and managed without a dependency on the Azure public cloud.
Disconnected operations for Azure Local enable Azure Local instances to be deployed and managed without a connection to the Azure public cloud, using selected Azure Arc-enabled services from a local control plane.
For readers evaluating implementation, Microsoft also documents how to deploy disconnected operations for Azure Local and how to plan the dedicated management cluster for the disconnected control plane.
Azure Arc shifts the management boundary by extending Azure governance to resources running outside Azure, including on-premises, multicloud, and edge environments.
Azure Arc is the connective layer that helps keep distributed environments manageable as Azure capabilities move closer to customer-controlled infrastructure.
AKS shifts the platform boundary by extending a consistent Kubernetes operating model beyond Azure regions.
AKS enabled by Azure Arc extends Azure Kubernetes Service to on-premises environments, including Azure Local, Windows Server, Windows IoT, and Windows 11 Enterprise/Pro.
AKS on bare metal runs Kubernetes clusters directly on physical hardware without a hypervisor layer, while preserving Azure management plane, APIs, and tooling consistency.
Foundry Local shifts the AI execution boundary by bringing inference closer to where data, latency, and control requirements exist.
Foundry Local on Azure Local is the enterprise-scale option for running AI inference on Azure Local infrastructure, using Arc-enabled Kubernetes and Kubernetes-native operations.
Foundry Local documentation covers the device-level option for building AI applications that run locally on user hardware, with data staying on the device and offline operation.
The distinction matters: one targets sovereign/private cloud infrastructure; the other targets on-device AI application scenarios.
Customer-controlled encryption shifts part of the access boundary by giving organizations more control over key ownership and protection.
Azure supports BYOK patterns for importing HSM-protected keys into Azure Key Vault Premium or Azure Key Vault Managed HSM, giving organizations entry points to evaluate HSM-backed key ownership in Azure.
GitHub Enterprise Local and Microsoft 365 Local shift parts of the operational boundary by allowing development and productivity workflows to run inside customer-controlled environments.
GitHub Enterprise Local enables GitHub Enterprise Server to run on Azure Local infrastructure for organizations that require data sovereignty, disconnected operations, and control over source code, CI/CD pipelines, and developer workflows.
Microsoft 365 Local enables Exchange Server, SharePoint Server, and Skype for Business Server to run on Azure Local infrastructure that is customer-owned and managed.
This shift is happening in a broader context. Cloud and AI adoption continue to accelerate, while legal, regulatory, and geopolitical expectations around controlare becoming more visible—especially in Europe.
Frameworks such as GDPR, the EU Data Act, and the EU AI Act are part of that environment. So are questions around cross-border jurisdiction, operational resilience, and dependency on globally operated platforms.
Consider a European public-sector agency adopting AI over sensitive operational data. Some workloads may continue to run in regional cloud services. Some data may need to remain within European boundaries. Some inference workloads may need to run locally. Some environments may need to keep operating during connectivity loss or geopolitical disruption. Source code, CI/CD workflows, identity, and encryption keys may also need to align with the same control boundary.
That scenario requires architectural placement decisions across data, compute, operations, identity, and connectivity. When evaluating the right posture, architects should ask:
Adaptive Cloud provides a technical model for applying cloud capabilities across global, sovereign, local, and disconnected environments—with control treated as part of the architecture.
Azure is evolving into a platform that can be deployed across environments — with different levels of control, connectivity, and responsibility.
Sovereignty is one of the forces making that evolution more visible. It brings legal, operational, and geopolitical considerations into architecture decisions.
Adaptive Cloud provides the model for that shift: a consistent platform approach across global, sovereign, local, and disconnected environments.
The important takeaway is this: sovereignty is becoming an architectural placement concern, not only a legal or compliance topic.
There is more to explore than fits within a single view of the topic. Azure Local, AKS across environments, Foundry Local, Azure Arc, disconnected operations, identity, and key management each open deeper technical considerations for how systems are built in practice.
