Tag: Azure Local

Microsoft’s Sovereign Cloud Strategy: is it really “Disconnected”?

Image Credit: Microsoft

Microsoft have just announced the General Availability of Disconnected Operations for Azure Local, M365 Local and Foundry Local.

Reading between the lines of the announcement seems to be aimed less at about “offline cloud” and more about Microsoft defining a clearer Sovereign Cloud architecture. While the headline is Azure Local disconnected operations + Microsoft 365 Local + Foundry Local, the bigger story is this:

Microsoft is trying to give customers a sovereign stack that spans infrastructure, productivity, and AI — and lets them choose where on the connectivity spectrum each workload sits.

Lets dig a bit deeper into this.

This is a Sovereign Private Cloud story

The Microsoft Learn page for Sovereign Private Cloud also makes the architecture intent more explicit, and positions that front and center as supporting locally hosted, hybrid, and fully disconnected environments. :

  • Azure Local for infrastructure
  • Microsoft 365 Local for productivity
  • Unified control and lifecycle management
  • Workload mobility between Azure and on-premises
  • Support for hybrid and disconnected deployment models

Announcing Azure Local, M365 Local, and Foundry Local together isn’t just about a bundling of product releases, it’s a shift to a full-stack sovereign operating model:

  • Infrastructure stays local,
  • Productivity stays local,
  • AI inferencing can stay local,
  • Control Plane can be cloud-hosted or on-premises depending on mode.

Azure Local is the foundation — but M365 Local and Foundry Local are the interesting parts

Most people immediately focus on Azure Local (understandably). We now get a local control plane (which is managed by the management appliance) that provides a Azure portal and ARM experience similar to the Azure Portal.

Flipping to disconnected mode means you do lose Azure Virtual Desktop (understandably), but still get options such as VMs, Kubernetes, Container Registry, Key Vault and Azure Policy.

Image Credit: Microsoft/Douglas Phillips

But the more important signal is that Microsoft is extending the same sovereign/disconnected pattern up the stack:

  • Microsoft 365 Local = productivity continuity inside the sovereign boundary
  • Foundry Local = AI inferencing/model capability inside the sovereign boundary

That matters because “sovereign” projects usually fail at one of these layers:

  • Infra is fine, but productivity still leaks to cloud services
  • Infra and productivity are local, but AI requires cloud inference
  • Everything is local, but operations become unmanageable

Microsoft is clearly trying to close those gaps. But are they?

Microsoft 365 Local: what it is, and what cloud use cases it’s trying to replace

What Microsoft 365 Local actually is

Image Credit: Microsoft

The Microsoft Learn page is direct in the positioning of M365 Local:

Microsoft 365 Local runs Exchange Server, SharePoint Server, and Skype for Business Server on customer-owned Azure Local infrastructure with Azure-consistent management, and it supports hybrid and fully disconnected deployments.

It also emphasizes:

  • customer-owned and customer-managed environment
  • data residency / access / compliance control
  • validated reference architecture and hardened baseline
  • certified hardware / partner-led deployment paths

What cloud use cases it’s potentially replacing

Microsoft 365 Local is not a like-for-like replacement for the entire modern Microsoft 365 cloud suite. The cloud use cases it appears to target (email, document collaboration, unified comms) are the ones where organizations would otherwise be pushed toward:

  • Exchange Online (email/calendar)
  • SharePoint Online (document collaboration/intranet)
  • Teams Online (cloud-first collaboration and video/audio conferencing)

Microsoft 365 Local does this using their stack of traditional on-premises server products:

  • Exchange Server
  • SharePoint Server
  • Skype of Business Server

Foundry Local: what it is, and what cloud AI use cases it’s trying to replace

In the sovereign announcement, Microsoft says Foundry Local now supports bringing large multimodal models into fully disconnected sovereign environments, using partner infrastructure (for example NVIDIA-based platforms) so customers can run local AI inferencing within their own boundaries.

What cloud use cases Foundry Local is trying to replace

Microsoft Foundry (cloud) is positioned as the place to design and operate AI apps/agents at scale, with:

  • a large model catalog
  • managed compute deployments
  • serverless API deployments
  • prompt flow orchestration
  • Azure-hosted endpoints/APIs

That means Foundry Local is potentially replacing cloud-hosted AI patterns like:

  • Serverless model APIs hosted by Microsoft
  • Managed compute model hosting in Azure
  • cloud-based prompt/app development pipelines for the inference/runtime side when data cannot leave the operational boundary

Foundry Local is effectively Microsoft’s answer for customers who need:

“Foundry-style AI capabilities, but the model runtime and data path must stay on-prem / inside the sovereign boundary.”

That’s a big gap in the market, and Microsoft is trying to close it.

What this stack is replacing, architecturally

If you zoom out, the trio maps cleanly to three cloud categories:

1) Azure Local disconnected

Potentially replacing: cloud-managed hybrid infrastructure patterns where WAN dependency is still too high
With: local control plane + Azure-consistent management for infra and some Arc-enabled services.

2) Microsoft 365 Local

Potentially replacing: reliance on Microsoft 365 SaaS for core productivity in environments that can’t support that connectivity/risk model
With: on-prem productivity server workloads on Azure Local under customer control.

3) Foundry Local

Potentially replacing: Azure-hosted model inference/serverless AI endpoints for sensitive AI use cases
With: local inferencing and APIs inside the same sovereign boundary.

That’s why this announcement matters: it’s not just infra resilience. It’s a stack-level sovereignty story.

The hard question: what if you need truly fully disconnected?

Microsoft’s wording now includes “fully disconnected” for Sovereign Private Cloud, and the Azure Local disconnected docs are a genuine step forward. But many organizations still need to define “fully disconnected” much more strictly than a marketing phrase ever can.

In practice, “fully disconnected” usually means:

  • no internet path
  • no cloud control plane dependency
  • no cloud identity dependency
  • no cloud telemetry path
  • updates and artifacts moved through approved transfer processes

If that’s your requirement, you need to compare options honestly and look at some alternatives that already fit that narrative.

Fully disconnected alternative 1: Azure Stack Hub

If you want the most explicit Microsoft-native air-gapped model, Azure Stack Hub is still the reference point.

Diagram showing Azure Stack Hub job roles
Image Credit: Microsoft

Microsoft’s Azure Stack Hub docs are very clear:

  • you can deploy and use it without internet connectivity
  • disconnected mode requires AD FS
  • multitenancy is not supported in disconnected mode because it would require Microsoft Entra ID
  • Microsoft describes this as a scenario for use in “factory floors, cruise ships, and mine shafts”

If you were to look at this really closely, that is about as explicit as Microsoft gets to stating that something is “fully disconnected”.

Why it’s still relevant

Azure Stack Hub is often the better fit when the requirement is:

  • pure private cloud
  • internal-only identity
  • no usage data sent to Azure
  • no hybrid dependency as a baseline design

The trade-off

Microsoft also documents the operational compromises in disconnected mode:

  • impaired marketplace flow (manual syndication)
  • no telemetry
  • some extension/tooling limitations
  • constraints around service principals/identity workflows, etc.

That’s the normal cost of real isolation.

Fully disconnected alternative 2: Red Hat OpenShift

If the center of gravity is containers/Kubernetes, OpenShift is one of the strongest mature options for disconnected environments.

Image Credit: Red Hat

Red Hat’s docs are excellent here because they define terms clearly:

  • Disconnected environment = no full internet access
  • Air-gapped network = completely isolated external network
  • Restricted network = limited connectivity (proxies/firewalls, etc.)

That taxonomy is exactly what more cloud vendors should be using.

Red Hat also documents:

  • extra setup is required because OpenShift automates many internet-dependent functions by default
  • preferred disconnected practices (image mirroring, local update service, etc.)
  • a wide range of disconnected install patterns, including on-prem and vSphere-based deployments

What OpenShift is replacing

OpenShift disconnected is often replacing:

  • managed Kubernetes services in public cloud
  • cloud-native CI/CD and image delivery assumptions
  • internet-dependent operator/update workflows

It’s a great fit if your target state is platform engineering and Kubernetes-first operations — but it absolutely requires discipline around mirroring, registries, and update lifecycle.

So where do M365 Local and Foundry Local fit versus these alternatives?

This is the key architecture question that can be answered in a number of ways.

If you want a Microsoft-centric sovereign stack (infra + productivity + AI)

Azure Local + M365 Local + Foundry Local is very compelling, because Microsoft is finally addressing all three layers together:

  • infra continuity
  • productivity continuity
  • AI continuity
    inside one sovereign/private-cloud framing.

That’s the strongest part of the announcement.

If you need “hard air gap” with minimal cloud relationship

Azure Stack Hub is still the clearer Microsoft answer, because the disconnected mode assumptions are explicitly documented (AD FS, no multitenancy, no Azure dependency during operation).

If you need broad private-cloud or Kubernetes-first flexibility

Red Hat OpenShift is a serious alternative, especially when:

  • you already run those stacks
  • your ops teams are built around them
  • your security model is based on internal depots, mirrors, and transfer controls rather than cloud-integrated management

Conclusion

Microsoft is not just shipping “offline features.”, they’re building a Sovereign Private Cloud narrative where:

  • Azure Local covers infrastructure,
  • Microsoft 365 Local covers productivity,
  • Foundry Local covers AI,
  • and customers can choose connected, hybrid, or fully disconnected modes based on mission and risk.

But “fully disconnected” still needs precise architecture definitions in every real project. Because in practice, the right question is never:

“Can this run disconnected?”

It’s:

“Which layer is disconnected, which layer isn’t, and who owns the operational overhead?”

Hope you found this post useful – see you next time

Top Highlights from Microsoft Ignite 2024: Key Azure Announcements

This year, Microsoft Ignite was held in Chigaco for in-person attendees as well as virtually with key sessions live streamed. As usual, the Book of News was released to show the key announcements and you can find that at this link.

From a personal standpoint, the Book of News was disappointing as at first glance there seemed to be very few key annoucements and enhancements being provided for core Azure Infrastructure and Networking.

However, there were some really great reveals that were announced at various sessions throughout Ignite, and I’ve picked out some of the ones that impressed me.

Azure Local

Azure Stack HCI is no more ….. this is now being renamed to Azure Local. Which makes a lot more sense as Azure managed appliances deployed locally but still managed from Azure via Arc.

So, its just a rename right? Wrong! The previous iteration was tied to specific hardware that had high costs. Azure Local now brings low spec and low cost options to the table. You can also use Azure Local in disconnected mode.

More info can be found in this blog post and in this YouTube video.

Azure Migrate Enhancements

Azure Migrate is product that has badly needed some improvements and enhancements given the capabilities that some of its competitors in the market offer.

The arrival of a Business case option enables customers to create a detailed comparison of the Total Cost of Ownership (TCO) for their on-premises estate versus the TCO on Azure, along with a year-on-year cash flow analysis as they transition their workloads to Azure. More details on that here.

There was also an announcement during the Ignite Session around a tool called “Azure Migrate Explore” which looked like it provides you with a ready-made Business case PPT template generator that can be used to present cases to C-level. Haven’t seen this released yet, but one to look out for.

Finally, one that may hae been missed a few months ago – given the current need for customers to migrate from VMware on-premises deployments to Azure VMware Solution (which is already built in to Azure Migrate via either Appliance or RVTools import), its good to see that there is a preview feature around a direct path from VMware to Azure Stack HCI (or Azure Local – see above). This is a step forward for customers who need to keep their workloads on-premises for things like Data Residency requirements, while also getting the power of Azure Management. More details on that one here.

Azure Network Security Perimeter

I must admit, this one confused me a little bit at first glance but makes sense now.

Network Security Perimeter allows organizations to define a logical network isolation boundary for PaaS resources (for example, Azure Storage acoount and SQL Database server) that are deployed outside your organization’s virtual networks.

So, we’re talking about services that are either deployed outside of a VNET (for whatever reason) or are using SKU’s that do not support VNET integration.

More info can be found here.

Azure Bastion Premium

This has been in preview for a while but is now GA – Azure Bastion Premium offers enhanced security features such as private connectivity and graphical recordings of virtual machines connected through Bastion.

Bastion offers enhanced security features that ensure customer virtual machines are connected securely and to monitor VMs for any anomalies that may arise.

More info can be found here.

Security Copilot integration with Azure Firewall

The intelligence of Security Copilot is being integrated with Azure Firewall, which will help analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions. These capabilities were launched on the Security Copilot portal and now are being integrated even more closely with Azure Firewall.

The following capabilities can now be queried via the Copilot in Azure experience directly on the Azure portal where customers regularly interact with their Azure Firewalls: 

  • Generate recommendations to secure your environment using Azure Firewall’s IDPS feature
  • Retrieve the top IDPS signature hits for an Azure Firewall 
  • Enrich the threat profile of an IDPS signature beyond log information 
  • Look for a given IDPS signature across your tenant, subscription, or resource group 

More details on these features can be found here.

DNSSEC for Azure DNS

I was surprised by this annoucement – maybe I had assumed it was there as it had been available as an AD DNS feature for quite some time. Good to see that its made it up to Azure.

Key benefits are:

  • Enhanced Security: DNSSEC helps prevent attackers from manipulating or poisoning DNS responses, ensuring that users are directed to the correct websites. 
  • Data Integrity: By signing DNS data, DNSSEC ensures that the information received from a DNS query has not been altered in transit. 
  • Trust and Authenticity: DNSSEC provides a chain of trust from the root DNS servers down to your domain, verifying the authenticity of DNS data. 

More info on DNSSEC for Azure DNS can be found here.

Azure Confidential Clean Rooms

Some fella called Mark Russinovich was talking about this. And when that man talks, you listen.

Designed for secure multi-party data collaboration, with Confidential Clean Rooms, you can share privacy sensitive data such as personally identifiable information (PII), protected health information (PHI) and cryptographic secrets confidently, thanks to robust trust guarantees that safeguard your data throughout its lifecycle from other collaborators and from Azure operators.

This secure data sharing is powered by confidential computing, which protects data in-use by performing computations in hardware-based, attested Trusted Execution Environments (TEEs). These TEEs help prevent unauthorized access or modification of application code and data during use. 

More info can be found here.

Azure Extended Zones

Its good to see this feature going into GA and hopefully will provide a pathway for future AEZ’s in other locations.

Azure Extended Zones are small-footprint extensions of Azure placed in metros, industry centers, or a specific jurisdiction to serve low latency and data residency workloads. They support virtual machines (VMs), containers, storage, and a selected set of Azure services and can run latency-sensitive and throughput-intensive applications close to end users and within approved data residency boundaries. More details here.

.NET 9

Final one and slightly cheating here as this was announced at KubeCon the week before – .NET9 has been announced. Note that this is a STS release with an expiry of May 2026. .NET 8 is the current LTS version with an end-of-support date of November 2026 (details on lifecycles for .NET versions here).

Link to the full release announcement for .NET 9 (including a link to the KubeCon keynote) can be found here.

Conclusion

Its good to see that in the firehose of annoucements around AI and Copilot, there there are still some really good enhancements and improvements coming out for Azure services.