Azure Local Disconnected Operations: Sovereign Cloud for Malaysian Regulated Industries

For years, Malaysian regulated industries faced an uncomfortable trade-off: you could have Azure's management model, or you could keep every byte of data inside your own walls — but not both. Azure Local (formerly Azure Stack HCI) ran on your hardware, yet its control plane still reached out to Azure for management, updates, and identity. For a BNM-supervised bank's core systems, a hospital's patient records, or a classified government enclave, that outbound dependency was often a non-starter.

Disconnected operations for Azure Local removes that dependency entirely. The Azure control plane — portal, ARM, Azure Policy, RBAC, Key Vault — now runs as a virtual appliance inside your own data center, with no ongoing connection to Azure or the internet required.

This article explains what actually changed, who in Malaysia should care, what it costs, and where the sharp edges are.

What Disconnected Operations Actually Changes

Before this capability, "Azure on-premises" still meant "Azure-attached." Your VMs ran locally, but the management plane phoned home. Disconnected operations flips that model:

  • Local Azure portal — the familiar Azure portal experience, served from your infrastructure.
  • Azure Resource Manager (ARM) — subscriptions, resource groups, ARM templates, and CLI, all running locally.
  • RBAC and managed identity — the same access control model you use in public Azure.
  • Azure Policy — enforce compliance guardrails at resource creation, on-premises.
  • Azure Key Vault — secrets and certificates managed locally.
  • Arc-enabled servers and AKS (preview) — manage VM guests and Kubernetes clusters without cloud connectivity.

Microsoft positions this as part of a broader sovereign private cloud stack: Azure Local for infrastructure, Microsoft 365 Local for on-premises Exchange, SharePoint, and Skype for Business (Microsoft has committed support for the subscription editions of these server products through at least 2035), and Foundry Local for on-premises AI inference with OpenAI-compatible APIs. For an organization that needs a fully air-gapped environment, all three layers now exist.

Who Should Evaluate This in Malaysia

Not every enterprise needs disconnected operations — and Microsoft makes that explicit. Procurement requires a valid business need for operating disconnected (connectivity limitations or regulatory restrictions), an eligible agreement (standard MOSA subscriptions do not qualify), and an active support plan. This is a sovereign/regulated play, not a general-purpose on-prem refresh.

Banking and financial services (BNM-supervised). Most Malaysian banks run hybrid strategies: core banking and sensitive customer data stay on-premises, less sensitive workloads go to cloud. Disconnected operations gives the on-premises half Azure-native management — same templates, same policies, same skills — while keeping the data boundary physically inside the bank's control.

Healthcare (MOH-regulated). Patient data handling requirements plus the latency needs of clinical systems keep hospital workloads on-premises. Add Foundry Local (currently in preview) and you get local AI inference — for example, running imaging or triage models next to the data that must never leave the hospital network.

Government, defense, and critical infrastructure. Microsoft's own reference scenarios include remote sites like oil rigs, manufacturing plants, and classified environments. The production control plane requires only three physical servers, which makes this feasible for secure facilities and branch data centers, not just national-scale deployments.

The Decision Framework: Malaysia West vs Disconnected Azure Local

The real question is never "cloud or on-prem?" — it is "which workloads go where?"

Consideration Malaysia West (public cloud) Azure Local disconnected
Data location Malaysia West region Your facility
Connectivity Internet required None required after setup
Management Microsoft-operated You operate the control plane
Cost model Pay-as-you-go Flat monthly per physical core, annual term, billed via Azure
Identity Entra ID Local AD DS + ADFS
Updates Microsoft-managed You control timing (offline/staged workflows)
Best for Web, analytics, dev/test, DR target Sovereign workloads, classified data, strict latency

For most Malaysian enterprises, the practical architecture is hybrid: public Malaysia West for web apps, analytics, dev/test, and as a DR target; disconnected Azure Local for core banking, clinical systems, classified workloads, and AI inference over sensitive data. The win is operational — both sides use the same ARM templates, CLI, and policy model, so you are not running two unrelated stacks.

Practical Examples

1. Deploying the control plane (PowerShell)

The control plane runs on a dedicated three-node management cluster (production minimum: 3 nodes, 512 GB RAM, 24 physical cores, and 8 × 2 TB drives per node). Deployment starts on the seed node by staging the appliance files and running the disconnected operations module:

# Stage appliance + certificates on the seed node
$applianceConfigBasePath = 'C:\AzureLocalDisconnectedOperations'
Copy-Item \\fileserver\share\azurelocalfiles\* $applianceConfigBasePath
Expand-Archive "$($applianceConfigBasePath)\AzureLocal.DisconnectedOperations.zip" `
  -DestinationPath $applianceConfigBasePath

Import-Module "$applianceConfigBasePath\OperationsModule\Azure.Local.DisconnectedOperations.psd1" -Force

# Ingress network configuration for the appliance
$ingressNetworkConfigurationParams = @{
    DnsServer               = "192.168.200.150"
    IngressNetworkGateway   = "192.168.200.1"
    IngressIpAddress        = "192.168.200.115"
    IngressNetworkPrefixLength = 24
    ExternalDomainSuffix    = "contoso.my"
}
$ingressNetworkConfiguration = New-ApplianceIngressNetworkConfiguration @ingressNetworkConfigurationParams

# Install the appliance (identity via ADFS, certificates for 23 ingress endpoints)
Install-AzureLocalDisconnectedAppliance @installAzureLocalParams

Note the identity wiring: you configure ADFS as the authority (plus LDAPS if you use it), and you need certificates for 23 ingress endpoints plus 2 management endpoints. Plan your PKI before anything else.

2. Managing resources locally (Azure CLI)

Once deployed, day-2 operations use the Azure CLI you already know — pointed at the local ARM endpoint. Supported CLI version is 2.81.0, and Azure Local nodes require the 32-bit CLI build (64-bit is for client machines):

# Point the CLI at the local ARM endpoint instead of public Azure
az login
az cloud update --profile latest \
  --endpoint-resource-manager "https://management.contoso.my"

# Create a resource group and deploy a VM — same verbs as public Azure
az group create --name rg-core-banking --location "contoso-dc1"

az connectedmachine machine create \
  --resource-group rg-core-banking \
  --name vm-core-app-01 \
  --location "contoso-dc1"

3. ARM/Bicep templates work unchanged

Because the local control plane speaks ARM, your existing Bicep templates deploy against it. A Key Vault for local secrets, for example:

// keyvault.bicep — deploys against the LOCAL ARM endpoint
param location string = resourceGroup().location

resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-sovereign-01'
  location: location
  properties: {
    tenantId: subscription().tenantId
    sku: { family: 'A', name: 'standard' }
    enableRbacAuthorization: true
  }
}

az deployment group create \
  --resource-group rg-core-banking \
  --template-file keyvault.bicep

4. Terraform for hybrid estates

For teams standardized on Terraform, the same pattern applies — register the appliance as a custom cloud and manage Azure Local VM resources through the AzAPI provider. A typical pattern for the connected management side (billing registration, update orchestration staging):

# main.tf — hybrid: Terraform manages the Azure side;
# local resources go through the CLI against the appliance endpoint
terraform {
  required_providers {
    azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
    azapi   = { source = "Azure/azapi",        version = "~> 2.0" }
  }
}

provider "azurerm" {
  features {}
  subscription_id = var.subscription_id
}

resource "azurerm_resource_group" "hub" {
  name     = "rg-sovereign-hub"
  location = "malaysiawest"
}

# Example: track the disconnected cluster as an Arc-connected resource
# once you choose to bridge selected telemetry back to Azure.
resource "azapi_resource" "local_cluster" {
  type      = "Microsoft.AzureStackHCI/clusters@2024-04-01"
  name      = "cluster-contoso-dc1"
  parent_id = azurerm_resource_group.hub.id
  body = jsonencode({
    location = "malaysiawest"
    properties = {
      cloudConnection = "None"
    }
  })
}

5. Local AI inference via Foundry Local (Python)

Foundry Local on Azure Local (preview, request-based access) exposes OpenAI-compatible REST endpoints on an Arc-enabled Kubernetes cluster. Application code barely changes:

from openai import OpenAI

# Endpoint lives inside your network — no internet egress
client = OpenAI(
    base_url="https://foundry.contoso.my/v1",
    api_key="***",  # local API key, not a cloud credential
)

response = client.chat.completions.create(
    model="phi-4",
    messages=[
        {"role": "system", "content": "You are a clinical document summarizer."},
        {"role": "user", "content": "Summarize this discharge note..."},
    ],
)
print(response.choices[0].message.content)

The model weights, the prompts, and the responses never leave your cluster — which is precisely the point for patient data or classified material.

Pitfalls: Where Deployments Go Wrong

  1. Azure Hybrid Benefit does not waive the disconnected core fee. This is the most common misconception. With disconnected operations, you pay the flat per-physical-core fee regardless of Windows Server licensing — AHB is not available for Azure Local in disconnected mode. AHB only applies to the Windows Server VMs running on it (and requires eligible licenses with active Software Assurance). Budget the core fee; do not assume existing Datacenter SA makes it $0.

  2. Eligibility is gated. You need an eligible agreement (MOSA is excluded), an active support plan (Standard or higher), and a demonstrable business need for disconnection. Talk to your Microsoft account team before sizing hardware.

  3. The control plane is not free real estate. Production requires a dedicated 3-node management cluster, isolated from tenant workloads, sized per Microsoft's minimums (512 GB RAM / 24 cores / 8 × 2 TB drives per node). Don't plan to co-locate workloads on it — Microsoft explicitly forbids that.

  4. PKI is the long pole. You need certificates for 23 ingress endpoints and 2 management endpoints, plus ADFS certificate chains. Air-gapped environments also hit a known issue (release 2605) where the Microsoft Code Signing PCA 2011 certificate must be manually downloaded and imported on every node before cloud deployment succeeds. Build your offline certificate workflow early.

  5. Updates are your problem now. Microsoft ships update packages for offline/staged application. The control plane can experience downtime during node reboots and updates — plan maintenance windows the way you did before the cloud existed.

  6. Preview components have sharp edges. Arc-enabled Kubernetes and AKS on Azure Local in disconnected mode are preview; Foundry Local on Azure Local is preview with request-based access. Keep preview components out of your compliance-critical path until GA.

  7. CLI quirks. Supported CLI version is pinned (2.81.0), nodes need the 32-bit build, and clients must trust the appliance root certificate (pip-system-certs or manual PEM import) or every call fails TLS verification.

The VMware Migration Angle

Many Malaysian enterprises are still on VMware and urgently evaluating post-Broadcom options. Azure Local is worth a spot on that shortlist: Azure Migrate supports migration to Azure Local, and the replication stays on-premises — VM data does not leave your network during migration. Combined with the same-management-plane story, you get a path off VMware without being forced into a public cloud move your regulators won't approve.

Conclusion

Disconnected operations turns Azure Local from "cloud-attached infrastructure" into a genuine sovereign private cloud. For Malaysian banks, healthcare providers, and government agencies, it is the first time the Azure operating model has been available with zero data egress — portal, ARM, Policy, RBAC, Key Vault, and even local AI inference, all inside your boundary.

The honest caveats: it is capacity-billed per physical core (AHB does not zero it out), it demands a dedicated management cluster and serious PKI preparation, and eligibility is gated to organizations with a real sovereignty need. But if your regulator owns your architecture decisions, this is the most Azure-native answer that exists today.

Key takeaways:

  1. The Azure control plane now runs on your hardware — portal, ARM, RBAC, Azure Policy, and Key Vault operate locally with no ongoing Azure or internet connection.
  2. Production needs a dedicated 3-node management cluster (512 GB RAM / 24 cores / 8 × 2 TB per node minimum), isolated from tenant workloads.
  3. Budget the per-core fee honestly — disconnected operations is billed monthly per physical core on an annual term via Azure, and Azure Hybrid Benefit for Azure Local is not available in disconnected mode (AHB only covers the Windows Server VMs on top).
  4. Eligibility is gated — eligible agreement, active support plan, and a documented business need to operate disconnected; MOSA subscriptions don't qualify.
  5. Hybrid remains the practical architecture — Malaysia West for non-sensitive workloads and DR, disconnected Azure Local for sovereign-critical systems, both run with the same tools and templates.

Azure Local disconnected operations is not just another on-premises option — it is the first time Azure's management model has been available with zero data egress. For Malaysian regulated industries, that changes what sovereignty can look like.