What Fails When Azure Local Loses Azure? Arc Resource Bridge, Connectivity, Updates, and Recovery Boundaries

Introduction

Azure Local is frequently described with one of two incomplete labels. One camp calls it cloud-managed infrastructure, implying that an Azure outage should stop the platform. The other calls it on-premises infrastructure, implying that Azure connectivity is optional once deployment is complete. Neither description is precise enough for architecture, operations, or incident response.

Azure Local has a local workload and infrastructure data plane, but it also has cloud-connected management, reconciliation, governance, lifecycle, billing, and identity dependencies. A running virtual machine does not ask Azure Resource Manager for permission to execute every CPU instruction. However, creating a new Azure Local VM, changing an Arc-managed VM resource, managing an AKS cluster lifecycle, applying an extension, reporting telemetry, renewing certain credentials, and completing some lifecycle operations depend on functioning control paths that reach Azure.

The operational mistake is treating every loss of Azure as the same incident. A public Azure service interruption, a blocked enterprise proxy, an expired Arc credential, an offline Azure Arc resource bridge, a deleted bridge projection, and a missing on-premises bridge appliance have different blast radii and different recovery boundaries. The correct response begins by identifying which plane failed, not by assuming the entire platform is either online or offline.

This article creates that dependency model. It explains which functions continue, degrade, stop, or move into a Microsoft support boundary when Azure Local loses Azure connectivity or when the Azure Arc resource bridge becomes unavailable.

TL;DR

Azure Local does not stop running workloads simply because its connection to Azure is interrupted. Microsoft documents that host infrastructure and existing VMs continue to run during a temporary control-plane disconnection. However, cloud-dependent management becomes stale or unavailable immediately, and a connected deployment must successfully synchronize with Azure at least once every 30 consecutive days. After that boundary, the instance becomes out of policy, enters reduced functionality, and cannot create new VMs until synchronization is restored [1], [2].

The Azure Arc resource bridge is a separate dependency from general Azure connectivity. It is the local appliance that hosts the Arc-enabled Kubernetes management cluster and extensions used to project and operate Azure Local VMs and associated resources through Azure Resource Manager. If the bridge is offline, cloud-driven VM and AKS lifecycle operations stop. If the on-premises bridge VM is missing, existing workloads can remain accessible locally, but bridge recovery is a Microsoft support-guided operation [3]-[5].

AKS has a stricter operational clock than many VM workloads. Temporary disconnection is supported for up to 30 days because certificates managed by AKS on Azure Local have a 30-day validity period. Cluster create, update, upgrade, delete, and manual scale operations are unavailable while disconnected. Beyond 30 days, the cluster may cease to function and may require deletion and redeployment [11], [12].

The design conclusion is straightforward: Azure Local has a resilient local data plane, but the connected management model is not indefinitely autonomous. Enterprises need dual-channel monitoring, tested local emergency access, a 30-day countdown runbook, bridge-health detection, and a firm rule against improvised recovery of Azure Arc resource bridge, Microsoft On-Premises Cloud (MOC), lifecycle, or Cluster-Aware Updating (CAU) state.

The Dependency Model Azure Local Actually Uses

The most useful mental model separates Azure Local into four planes rather than forcing it into a cloud-versus-on-premises binary.

Local workload data plane

This is where application execution occurs. It includes:

• Hyper-V virtual machines and their guest operating systems.
• AKS control-plane and worker-node VMs running on Azure Local.
• Kubernetes pods, services, and locally reachable load-balancing paths.
• Application data stored on local or supported attached storage.
• East-west and north-south workload network traffic.

The local workload data plane can continue during many management-plane failures. That does not guarantee application availability, because an application may independently depend on Azure-hosted identity, databases, registries, APIs, DNS, licensing, or other external services.

Local infrastructure and fabric plane

This plane includes the Azure Local failover cluster, Hyper-V, Storage Spaces Direct or supported external storage integration, cluster networking, quorum, health services, lifecycle services, and local administrative access. It maintains workload placement and infrastructure availability independently of an interactive Azure portal session.

Microsoft states that during a temporary control-plane connection loss, host infrastructure and existing VMs continue to run normally [1]. That statement is important, but it does not mean every management or lifecycle function remains available.

Bridge and reconciliation plane

The Azure Arc resource bridge runs as a prepackaged appliance VM on the Azure Local cluster. Inside it is an Arc-enabled Kubernetes management cluster and the extensions that translate Azure Resource Manager requests into local fabric operations. The bridge projects local resources such as VMs, logical networks, network interfaces, disks, images, and related objects into Azure [3].

This plane is where many operators incorrectly place the workload runtime. The bridge does not execute the application workload. It executes and reconciles management intent for Arc-enabled resources. Its failure can leave running workloads intact while stopping the supported lifecycle path used to manage them.

Azure service and governance plane

This plane contains the public Azure services and Azure resources used for:

• Azure Resource Manager operations.
• Azure RBAC and delegated self-service.
• Azure Arc resource state and agent services.
• Azure Policy and Machine Configuration.
• Azure Monitor, Log Analytics, Insights, and alerting.
• Azure Update Manager presentation and orchestration entry points.
• Billing, registration, verification, and benefit synchronization.
• Microsoft Entra-based access paths and managed identities.
• Resource Health and support workflows.

The following diagram shows why a cloud outage, an egress outage, and a missing bridge appliance produce different outcomes.

Control, Bridge, and Workload Planes at a Glance

The diagram should change the incident question from “Is Azure Local down?” to “Which plane is unavailable, and which functions cross that boundary?”

Scope, Assumptions, and Status Vocabulary

This analysis applies to a normally connected, hyperconverged Azure Local deployment. It does not treat Disconnected operations for Azure Local as an automatic fallback mode. Disconnected operations is a separately acquired and designed architecture with an on-premises control plane, a dedicated management cluster, additional capacity requirements, and its own supported-service matrix [22].

The status terms used throughout this article mean:

• Continue: The primary function remains available locally without requiring the failed dependency for its normal runtime path.
• Degrade: The function partially operates, but visibility, control, freshness, governance, automation, or supportability is reduced.
• Stop: The function cannot be initiated, completed, or supported through its normal management path.
• Support required: The environment has crossed a documented recovery boundary where improvised self-service repair can create backend inconsistency or irrecoverable damage.

These classifications assume the local cluster, storage, network, DNS, time, and workload dependencies remain healthy. Losing Azure connectivity does not protect an application from a simultaneous local hardware, network, certificate, or dependency failure.

Five Incidents That Must Not Be Treated as One

Azure public service interruption

Azure services can be unavailable even when the enterprise internet path is healthy. In this case, local Azure Local infrastructure can continue while portal operations, ARM requests, Arc services, monitoring ingestion, policy updates, identity flows, or update workflows fail depending on the affected Azure service.

The correct response is to correlate Azure Service Health with local evidence. Restarting local infrastructure because a public control-plane service is unavailable can turn a remote service incident into a local availability incident.

Enterprise egress, DNS, firewall, or proxy failure

Azure Local hosts, Azure Arc resource bridge, Arc-enabled servers, and AKS components have outbound connectivity requirements. Azure Local generally uses outbound HTTP and HTTPS connectivity, and the required destination set spans more than a single Azure endpoint [15], [16].

A proxy or firewall change can therefore create a selective failure. Host agents might connect while the bridge cannot. The bridge might connect while AKS nodes cannot reach required services. Azure Arc gateway can reduce the number of required endpoints for supported scenarios, but it does not turn a connected deployment into an air-gapped deployment, does not carry every endpoint, and is enabled only for supported new-deployment scenarios [17].

Required Outbound Connectivity Is a Set of Paths, Not One Firewall Rule

Azure Local requires outbound connectivity from multiple source domains. A successful test from an administrator workstation or one host does not prove that the complete platform can reach Azure. Microsoft documents outbound ports 80 and 443 for Azure Local, requires the Azure Local, Azure Arc-enabled servers, Azure Arc resource bridge, and AKS endpoint sets, and states that HTTPS inspection is unsupported on the Azure Local management path [15], [16]. Azure Arc Private Link Scope is also not supported for Azure Local management endpoints [16].

Azure Arc gateway can consolidate much of the HTTPS traffic for supported new deployments, but it is not a universal tunnel. It does not support HTTP traffic, unsupported endpoints still require direct or enterprise-proxy paths, and AKS support remains subject to the current feature status and endpoint requirements [17].

The design implication is to monitor reachability as a matrix of source, destination class, protocol, and proxy path. A single internet-up test is not meaningful evidence of Azure Local control-plane health.

Azure Arc resource bridge connectivity or health failure

In this scenario, the appliance VM exists, but it is offline, unhealthy, unable to reach Azure, unable to reach the local fabric, or unable to reconcile extensions and custom-location state. Azure resources can remain visible while operations fail or remain pending.

Microsoft documents that the bridge should not remain offline for longer than 45 days because a security key in the appliance can expire. Resource Health alerts are recommended so the failure is detected before that boundary [5], [29].

Azure Arc resource bridge projection deletion

If the Azure projection of the bridge is deleted while the on-premises appliance remains, Microsoft documents a procedure to restore the Azure projection. This is not the same as deleting the appliance VM [4].

Operators must verify that the local appliance still exists and is healthy before choosing any recovery path. An Azure-side object deletion and an on-premises VM deletion can look similar in the portal but have very different recovery boundaries.

Missing or damaged on-premises bridge appliance

If the appliance VM itself is missing, Azure can still contain an Arc resource that claims the bridge exists. This creates a split state: the Azure control plane has an object, but the local execution component is absent.

Microsoft explicitly warns Azure Local customers not to delete or independently recover the bridge without Microsoft guidance. Generic recovery instructions for Arc-enabled VMware or Arc-enabled System Center Virtual Machine Manager do not apply to Azure Local [5]. The community case supplied for this article demonstrates the operational pattern: AKS workloads remained running, but VM and AKS management were blocked and the update failed at the bridge stage [26].

What Continues When Azure Connectivity Is Lost

Existing virtual machine execution

Existing VMs continue to execute on Hyper-V when Azure connectivity is interrupted. Cluster placement, local CPU and memory scheduling, storage I/O, virtual switching, and guest execution do not require a successful ARM transaction for every runtime operation [1].

Local high availability also remains a local cluster function. If a node fails while Azure is disconnected, failover behavior depends on the health and capacity of the Azure Local cluster, not on whether an administrator can currently open the Azure portal.

This does not mean all VM-related services continue. Azure portal lifecycle operations, guest extensions, policy refresh, Azure Monitor ingestion, Azure-hosted backup control paths, Azure verification, and external application dependencies can fail while the VM process remains running.

Local infrastructure services

The failover cluster, storage services, local networking, local health data, Windows event logs, and supported local administrative tools remain available as long as the infrastructure itself is healthy. Azure Local records local system and lifecycle activity, and local cluster health can be examined through supported PowerShell and Health Service interfaces even when cloud dashboards are stale [30].

Supported local emergency operations

Local access is a legitimate emergency control, but it is not a blanket substitute for Azure Resource Manager. Microsoft maintains a specific supported-operations matrix for Azure Local VMs. Some actions are supported through local tools, while many Arc-managed lifecycle operations must be performed only through the Azure portal or Azure CLI [6].

A safe emergency posture prioritizes:

• Console access to the guest.
• Guest operating-system remediation.
• Only local VM operations that Microsoft explicitly lists as supported for the deployed release. Do not assume that start, stop, restart, pause, save, or other power-state changes are safe locally merely because the Azure control path is unavailable.
• Live migration and local failover operations.
• Capacity protection and containment.
• Read-only inventory and health collection.

It avoids creating, deleting, resizing, rewiring, or re-registering Arc-managed resources through local tools merely because Azure is unavailable.

AKS workload execution during a short disconnection

Kubernetes workloads can continue during a temporary Azure disconnection because the control-plane and worker-node VMs run locally. Local services, pods, and load-balancing components can remain functional [11].

The important qualifier is that AKS management is already degraded. Cluster create, update, upgrade, and delete operations stop. Manual node-pool scaling stops. Microsoft Entra access and connected-cluster proxy access stop. Azure portal status and ARM status become unavailable or stale. Container Insights and Azure-based diagnostic configuration are unavailable [11].

What Degrades Immediately

Azure portal state and Azure Resource Manager operations

The portal can continue to display Azure resource objects, but the data can become stale. A visible VM resource does not prove that the local VM exists, is healthy, or still matches the Azure object. Likewise, a local VM can be running even when the Azure-side operation remains failed or pending [1], [3].

Create, update, delete, disk, NIC, image, network, and other ARM-driven lifecycle operations depend on the bridge path and Azure services. When the control path is broken, operators should freeze new cloud-driven changes rather than repeatedly submitting operations that cannot reconcile.

Host and guest Azure Arc agents

The Connected Machine agent changes a machine to disconnected after Azure stops receiving heartbeats for more than 15 minutes. The local agent services can continue running, but they cannot obtain new Microsoft Entra tokens or metadata while disconnected [13].

Existing extensions can continue running, but install, uninstall, and update operations stop. Microsoft queues extension operations for only a limited period. Azure Policy guest assignments continue from local state for a limited time, but the disconnected-behavior documentation identifies a 14-day local retention boundary for guest assignments [13].

The agent managed-identity certificate is valid for up to 90 days and normally begins renewal when 45 or fewer days remain. A sufficiently long disconnection can expire the identity and require the agent to be disconnected and reconnected with an onboarding credential [14]. That recovery must be planned carefully on Azure Local because disconnecting an Arc resource can also affect its Azure representation and attached capabilities.

Guest management

Every VM created through Azure Local VM management receives the local guest agent. Enabling guest management causes that agent to install the Azure Connected Machine agent, which then provides extension management and other Arc-enabled guest capabilities [19].

The guest operating system keeps running during Azure loss, but new guest-management actions, extension changes, policy updates, managed-identity token requests, and Azure-based monitoring depend on the Arc path. “The VM is up” and “guest management is healthy” are therefore separate status checks.

Monitoring, policy, and audit freshness

Azure Monitor Agent can continue running locally during disconnection, but Microsoft documents only a short local log cache and no transmission to Azure while offline [13]. Azure Local Insights depends on data reaching a Log Analytics workspace, so its dashboards and alerts become stale when ingestion stops [18].

Azure Activity Log records Azure-side operations, not local actions that occur outside the Azure control plane. Local event logs, lifecycle logs, cluster health, and a third-party or local SIEM path are therefore essential during a cloud-control incident.

A mature design uses two monitoring channels:

1. Azure-side Resource Health, Arc heartbeat, Insights, and Log Analytics alerts.
2. A local or independently hosted monitoring system that watches cluster health, bridge VM presence, egress tests, time since last Azure synchronization, and telemetry freshness.

Without the second channel, the same outage that removes visibility can also suppress the alert intended to report the outage.

Billing, Registration, and Licensing Do Not Fail in the Same Way

A connectivity outage does not automatically suspend Azure Local charges. Microsoft documents that core data can be uploaded in batches after days or weeks of interrupted connectivity, while Azure Local must still connect at least once every 30 days. For solution version 12.2504.1001.20 and later, the usage record is cloud-based. Microsoft also states that shutting down or decommissioning a system without deleting its Azure Local resource can allow billing to continue until the Azure resource has been disconnected for more than 31 days [2].

That creates three separate operational questions:

• Is the local instance registered and in policy? This affects the 30-day reduced-functionality boundary and the ability to create new VMs [1].
• Is usage and billing state current? A network outage can delay synchronization, but it is not a supported decommissioning or cost-control method [2].
• Are host licenses and Azure verification current? Windows Server subscription host licenses and Azure verification depend on periodic synchronization and can show expired or inactive after more than 30 days [23], [24].

The runbook should therefore verify registration, policy, billing, subscription, Automatic VM Activation (AVMA), and Azure verification as separate recovery checks. A green workload status does not prove that any of those control-plane states are current.

The Clocks That Matter During Extended Disconnection

The platform does not have one universal “offline timer.” Different components have different credential, policy, support, and licensing clocks.

The 30-day Azure Local rule is not a promise that all services work normally for 30 days. Portal operations, ARM changes, monitoring ingestion, policy refresh, extension management, AKS lifecycle operations, and Entra-based AKS access can stop immediately. The 30-day boundary is a compliance and reduced-functionality threshold layered on top of those immediate degradations.

What Stops When Azure Arc Resource Bridge Is Unavailable

Portal-based VM lifecycle management

The bridge hosts the management cluster and extensions that receive ARM requests and execute local VM operations. If the bridge is unavailable, Azure Local VM create, update, delete, disk, NIC, GPU, image, and related lifecycle operations cannot complete through the supported Arc control path [3].

Existing VMs can remain accessible locally. Microsoft’s Azure Local VM FAQ explicitly distinguishes deleting the Azure projection from deleting the on-premises appliance and states that workloads remain accessible through local tools if the appliance VM is accidentally deleted [4].

AKS lifecycle management

AKS on Azure Local also depends on the connected management path. Running workloads may continue, but cluster CRUD operations, upgrades, manual scale actions, extension management, GitOps propagation, policy updates, and Azure-based observability stop or degrade [11].

A missing bridge is therefore not equivalent to a Kubernetes worker failure. It is a management-plane failure that can leave the cluster running in an increasingly unmanageable and eventually unsupported state.

Azure Local solution updates

Azure Local updates are full-stack lifecycle operations. Microsoft supports the Azure portal and the Azure Local PowerShell update workflow. Manual Cluster-Aware Updating, Windows Admin Center update interfaces, machine-level Azure Update Manager, SConfig, and third-party update tools are not supported for installing Azure Local solution updates [7].

Limited-connectivity update workflows can import a static solution payload, but Microsoft documents that components required for Azure Arc resource bridge and AKS are not included in that static payload and are downloaded automatically during the update process [8], [9]. Consequently, importing an update package is not proof that an update can complete during a full egress outage or with a missing bridge.

A bridge-related update failure should not be “fixed” by manually clearing CAU resources, deleting tracking files, modifying MOC registrations, or forcing a standalone CAU run. The community update case supplied for this article contains exactly the kind of plausible but unsupported manual CAU advice that conflicts with Microsoft’s official Azure Local update-interface guidance [7], [27].

Microsoft provides the Support.AksArc tool for supported diagnostics and remediation of common Azure Local VM, MOC, bridge, AKS, and solution-update issues. If that supported tool does not resolve the problem, the next step is Microsoft Support, not deeper manual state surgery [10].

Continue, Degrade, Stop, or Support-Required Matrix

The matrix exposes the central design truth: workload continuity is broader than management continuity, but management loss accumulates operational debt. The longer the control plane remains unavailable, the more likely credentials expire, policy state diverges, updates become blocked, portal state becomes misleading, and supportability narrows.

Split State Between Azure and On-Premises Infrastructure

Split state is one of the most dangerous Azure Local failure modes because both sides can present internally consistent but mutually incompatible views.

Names are not identities. Recreating a resource with the same display name does not guarantee that Azure resource IDs, custom-location bindings, extension ownership, MOC records, disks, NICs, or backend references are reconciled. Recovery must preserve or intentionally re-establish those identities.

Unsupported Manual Recovery Actions

The pressure to recover quickly is highest when the workloads are still running but the portal is unusable. That is exactly when operators are most likely to make the incident worse.

The following actions should be treated as prohibited unless current Microsoft documentation or Microsoft Support explicitly directs them for the exact Azure Local release and state:

• Deleting or manually recreating the Azure Arc resource bridge appliance VM.
• Deleting the bridge Azure resource, custom location, or extensions as a troubleshooting experiment.
• Applying Arc-enabled VMware or Arc-enabled System Center Virtual Machine Manager bridge-recovery procedures to Azure Local.
• Removing MOC registrations, infrastructure VHD files, VHD locks, or internal database records by hand.
• Running manual Cluster-Aware Updating or starting a standalone CAU run to bypass the Azure Local update orchestrator.
• Installing Azure Local solution updates through Windows Admin Center, SConfig, machine-level Azure Update Manager, or a third-party patch tool.
• Creating, deleting, resizing, or rewiring Arc-managed VMs through local tools when the operation is designated as portal-only or CLI-only.
• Disconnecting and reconnecting Azure Arc agents without understanding the effect on Azure resources, managed identities, extensions, and workload ownership.
• Reimaging nodes, resetting deployment state, restoring registry state, or deleting cluster resources before logs and support evidence are collected.

The supplied community sources are valuable because they show what real incidents look like. They are not a substitute for current product documentation or a support contract. The missing-bridge discussion contains conflicting recommendations, and the failed-update discussion includes manual CAU steps that conflict with the official list of unsupported Azure Local update interfaces [7], [26], [27]. The failed-deployment discussion similarly demonstrates how quickly recovery advice can become version-specific [28].

Local Emergency Access Must Be Designed Before the Outage

A cloud-connected management model still requires a local break-glass design. Emergency access should be documented, tested, monitored, and narrowly scoped.

Infrastructure access

Maintain and test:

• Vaulted local or domain credentials authorized for Azure Local node access.
• A management workstation with supported PowerShell modules and RSAT tools.
• PowerShell remoting or console access to every node.
• Failover Cluster Manager, Hyper-V Manager, and Windows Admin Center access for the operations Microsoft supports locally.
• Out-of-band hardware management access for each physical server.
• Local DNS, NTP, certificate, proxy, and firewall administration paths.

VM access

Maintain and test:

• Guest console access that does not depend on Azure portal actions.
• RDP or SSH paths through local networks.
• Application-level service accounts and emergency credentials.
• A documented list of which VM actions are safe locally and which must wait for Azure recovery.

AKS access

Maintain and test:

• A protected admin kubeconfig obtained and validated before the incident.
• SSH keys for AKS control-plane and worker troubleshooting where supported.
• Local kubectl access from a hardened management host.
• An on-premises observability path for Kubernetes when Container Insights is unavailable.
• Internal registry and artifact access if workloads must restart while internet access is unavailable.

Microsoft documents that Entra-based access and connected-cluster proxy access do not work during temporary disconnection, while local access through admin kubeconfig can continue [11]. A kubeconfig that exists only as an Azure retrieval workflow is not a tested break-glass control.

Monitoring for Control-Plane Degradation

The goal is to detect the management-plane failure before a user notices a stale portal or before a 30-day or 45-day clock becomes an emergency.

A single “cluster connected” dashboard tile is not enough. The hosts, bridge, AKS management plane, guest agents, monitoring pipeline, and billing synchronization can fail independently.

Operational Runbook for Temporary Connectivity Loss

Detect and classify

1. Confirm whether the local cluster and workloads are healthy.
2. Check Azure Service Health for a relevant service or regional incident.
3. Test DNS, route, proxy, firewall, certificate inspection, and required outbound paths from the Azure Local hosts.
4. Test the bridge appliance path separately from the host-agent path.
5. Test AKS control-plane and worker-node egress separately if AKS is deployed.
6. Record the last successful Azure Local synchronization, Arc heartbeat, bridge health transition, and Log Analytics ingestion timestamp.

The objective is to classify the incident as public Azure, enterprise egress, host agent, bridge, AKS network, or local fabric. Do not change the platform until that classification is credible.

Stabilize the environment

• Freeze nonessential ARM mutations, deployments, extension changes, policy changes, and update operations.
• Do not repeatedly retry failed create, delete, or update requests.
• Preserve local workload availability and capacity headroom.
• Confirm that backup, replication, identity, DNS, certificate, and registry dependencies are not independently affected.
• Notify application teams that Azure portal state and cloud monitoring may be stale even though workloads are running.

Restore connectivity

• Correct DNS, routing, firewall, proxy, or certificate-inspection issues using the current Microsoft endpoint guidance.
• Avoid broad permanent internet access as a shortcut. Restore the documented outbound paths and retest from each management domain.
• If Arc gateway is deployed, verify both the gateway path and required bypass paths. Arc gateway does not carry every required endpoint [17].
• If the bridge remains offline after network restoration, use the supported bridge and Azure Local support diagnostics rather than deleting the appliance.

Validate reconciliation

Do not declare recovery when a single portal blade loads. Validate fresh state and a complete round trip:

• Host Arc agents report connected.
• Azure Local is connected and in policy.
• Bridge Resource Health is available.
• The custom location and required extensions are healthy.
• Portal inventory matches local resource IDs and counts.
• A controlled canary operation completes through ARM and is reflected locally.
• Azure Monitor and Log Analytics receive fresh data.
• Policy state and guest assignments are current.
• AKS cluster status, GitOps, extensions, Entra access, and Container Insights recover.
• Update discovery and readiness checks complete without a stuck action plan.
• Billing, verification, and activation state are synchronized.

Operational Runbook for Extended Disconnection

Start a formal countdown

The incident clock begins at the last successful synchronization, not when the help desk ticket was opened. Track at least four deadlines:

• 14-day Arc guest-policy retention boundary.
• 25-day operational escalation target.
• 30-day Azure Local and AKS boundary.
• 45-day bridge security-key boundary and the start of the Arc identity-expiry risk window.

Reduce change

During an extended outage:

• Do not schedule Azure Local solution updates.
• Do not submit VM or AKS lifecycle changes that cannot reconcile.
• Avoid certificate, identity, network, and proxy changes unrelated to recovery.
• Protect capacity so existing workloads can continue without emergency provisioning.
• Keep local backups and application recovery mechanisms current.

Protect AKS before day 30

• Verify local admin kubeconfig access.
• Verify all nodes, system pods, DNS, ingress, load balancing, persistent volumes, and internal registries.
• Confirm certificate status and supportability with Microsoft if the outage approaches the documented limit.
• Do not plan to “ride through” day 30. Microsoft states that the cluster may cease to function and may require deletion and redeployment [11].

Escalate early

A site that cannot restore Azure connectivity within several days should involve Microsoft and the network, security, identity, and application owners before the environment crosses a credential or support boundary. The recovery problem becomes harder, not easier, as clocks expire.

Operational Runbook for an Offline or Missing Bridge

Determine what still exists

Collect read-only evidence before remediation:

• Does the bridge Azure resource exist?
• Does the on-premises bridge appliance VM exist on any node?
• Is the appliance VM running?
• Is the custom location present?
• Are the VM and AKS extensions present and healthy?
• Can the appliance reach Azure?
• Can the hosts reach the appliance over the required local ports?
• Is host or infrastructure storage full?
• Is an update action plan active or failed at a bridge or MOC stage?

The following commands illustrate an evidence-first snapshot. Run commands only from supported administration contexts and adjust node names and modules for the deployed release.

# Local cluster and node health
Get-ClusterNode
Get-ClusterGroup
Get-ClusterResource

# Confirm the bridge and workload VMs across each Azure Local node
Get-VM -ComputerName <NodeName>

# Azure Local registration and solution-update state
Get-AzureStackHCI
Get-SolutionUpdate

# Run locally on each Azure Local node to inspect its Arc agent
azcmagent show

This block is intentionally read-only. Success means the operator has a time-stamped snapshot of node, cluster-resource, VM, registration, update, and Arc-agent state. It does not authorize deletion, recreation, or cleanup of internal resources.

Use the supported diagnostic path

Microsoft documents the Support.AksArc module for diagnosing and remediating common problems involving Azure Local VMs, MOC, Azure Arc resource bridge, AKS, and solution updates [10]. Run only the documented commands for the installed release and preserve the output.

Collect Azure Local diagnostic logs before destructive changes. If Azure upload is unavailable, retain the logs locally and coordinate an alternate upload path with Microsoft Support [20], [21].

Stop at the support boundary

If the appliance VM is missing, if bridge identity cannot be reconciled, if MOC registrations or VHD locks are orphaned, if the custom location or extensions are inconsistent, or if an update remains blocked after supported diagnostics, open a Microsoft support case.

Provide:

• Azure Local instance resource ID and subscription.
• Cluster name, region, solution version, and OS build.
• Exact time connectivity or bridge health was last known good.
• Bridge Azure resource state and local appliance-VM state.
• Custom-location and extension state.
• Update action-plan ID and failed stage, if applicable.
• Arc-agent state from every node.
• Relevant cluster, bridge, MOC, update, and event logs.
• A list of every manual action already taken.
• Workload impact, including which VMs and AKS clusters still run.

Recovery Validation Checklist

Recovery is complete only after the local and Azure states converge and the platform can perform supported operations again.

Local infrastructure validation

• All Azure Local nodes are online and healthy.
• Cluster quorum, storage pools, volumes, networks, and critical cluster resources are healthy.
• No infrastructure volume is unexpectedly full.
• Existing VMs are running on expected networks and storage.
• Local event logs show no continuing bridge, MOC, lifecycle, or storage faults.

Bridge and resource projection validation

• The bridge appliance VM exists, runs, and remains stable.
• The bridge Azure resource reports available.
• The custom location is healthy and maps to the expected instance.
• Required VM and AKS extensions are healthy.
• Resource IDs, not only display names, match the intended objects.
• Azure and local inventory counts match.

VM management validation

• Azure portal and Azure CLI read operations return current state.
• A non-production canary VM operation completes through the supported ARM path.
• The resulting local state matches the Azure state.
• Guest management is connected for the canary.
• Extension, policy, monitoring, and managed-identity functions are verified.

AKS validation

• kubectl shows healthy control-plane and worker nodes.
• System namespaces and core add-ons are healthy.
• Workload services, ingress, DNS, load balancing, storage, and internal registries function.
• Azure portal status is current.
• Entra access, connected-cluster access, GitOps, extensions, policy, and Container Insights function.
• Cluster version and support status remain valid.

Lifecycle, billing, and monitoring validation

• Azure Local synchronization completes and the instance returns to in-policy status.
• Billing and core-count synchronization are current.
• Windows Server subscription, AVMA, Azure verification, and eligible VM benefits report the expected status.
• Azure Monitor and Log Analytics show fresh records with no unexplained gap after recovery.
• Azure Local update discovery, readiness assessment, and orchestrator state are healthy.
• Resource Health and independent local alerts return to normal.

Recovery evidence

Retain:

• Before-and-after health snapshots.
• Support case number and approved recovery steps.
• Commands executed and operators involved.
• Resource-ID reconciliation results.
• Telemetry-gap duration.
• AKS certificate and support validation.
• Update and billing synchronization results.
• Root cause, contributing controls, and corrective actions.

Designed Disconnection Is a Different Architecture

Disconnected operations for Azure Local should not be described as the eventual state of a connected deployment after the WAN fails. It is a separately acquired, eligibility-controlled product architecture that deploys a local control plane and dedicated management cluster. It provides local Azure portal, Azure Resource Manager, RBAC, subscriptions, resource groups, and selected Arc-enabled services without continuous public Azure connectivity [22].

That distinction matters for architecture reviews:

• A connected deployment tolerates interruption but retains cloud dependencies and synchronization clocks.
• Disconnected operations relocates selected control-plane capabilities on-premises and changes hardware, identity, PKI, lifecycle, billing, support, and operational requirements.
• Features supported in connected Azure Local are not automatically supported in disconnected operations.
• AKS and other services can have different maturity or preview status in the disconnected product.

If the business requirement is indefinite operation without Azure public-cloud connectivity, the answer is not a larger firewall exception timeout or a promise to repair the bridge later. The answer is to evaluate Disconnected operations as a different target architecture.

Architecture and Governance Recommendations

Treat management continuity as a service objective

Define service objectives for:

• Time to detect host Arc disconnection.
• Time to detect bridge unavailability.
• Maximum portal and telemetry staleness.
• Maximum time since Azure Local synchronization.
• Maximum AKS disconnected duration.
• Time to open a Microsoft support case for bridge or update failures.

Workload uptime alone is an incomplete Azure Local availability measure.

Separate workload, bridge, and Azure incidents

Use separate incident categories and dashboards for:

• Local cluster or storage incident.
• Workload network or application incident.
• Azure service incident.
• Enterprise egress, DNS, firewall, or proxy incident.
• Host Arc-agent incident.
• Azure Arc resource bridge incident.
• AKS management-plane incident.
• Lifecycle or update-orchestrator incident.

This prevents the wrong team from restarting the wrong layer.

Preserve identity and resource IDs

Back up or export inventories containing Azure resource IDs, local VM IDs, disk and NIC relationships, custom-location IDs, cluster names, and bridge identifiers. Display names are insufficient for split-state recovery.

Build a support-ready evidence pipeline

Pre-stage log-collection procedures, remote-support approval, alternate upload paths, and support-contract escalation. Microsoft’s remote-support model is permissioned and time-bound, but it still depends on planning and connectivity [20].

Review this article when Microsoft changes the boundaries

The claims most likely to change are:

• The 30-day Azure Local synchronization and reduced-functionality behavior.
• AKS certificate validity and semi-connected support.
• Azure Arc resource bridge recovery and offline credential limits.
• Supported update interfaces and limited-connectivity package behavior.
• Arc gateway coverage.
• Disconnected operations feature availability and service status.

This article’s publication date and validation baseline are intentionally prominent so future product changes can be evaluated against a known point in time rather than mistaken for an undated permanent guarantee. The current known-issues page is continuously updated and, at this baseline, identifies Azure Local 2607 as solution version 12.2607.1003.69 [25].

Conclusion

Azure Local is neither a cloud service that stops when a portal is unavailable nor an autonomous on-premises platform that can ignore Azure indefinitely. It is a local workload and infrastructure data plane connected to cloud-based management, reconciliation, governance, monitoring, lifecycle, billing, and identity services.

Existing VMs and local infrastructure can continue during a temporary Azure disconnection. AKS workloads can also continue for a limited period. However, ARM lifecycle operations, portal freshness, extension changes, Azure policy reconciliation, Azure Monitor ingestion, AKS management, update workflows, billing synchronization, and credential renewal degrade or stop on different timelines.

The Azure Arc resource bridge is the most important recovery boundary to understand. An offline bridge is a management-plane incident. A missing bridge appliance is a support-guided recovery incident. Neither condition justifies improvised deletion of bridge resources, MOC state, VHD locks, custom locations, or CAU state.

The practical operating model is to detect control-plane degradation early, retain tested local emergency access, freeze unsupported mutations, track the 14-day, 30-day, 45-day, and 90-day clocks, escalate before credentials expire, and validate full reconciliation after connectivity returns. That is the exact dependency model missing from simplistic descriptions of Azure Local as merely cloud-managed or merely on-premises.

External References

• [1] Microsoft: Azure Local FAQ
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/faq?view=azloc-2606
• [2] Microsoft: Azure Local billing and payment
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/billing?view=azloc-2606
• [3] Microsoft: What is Azure Local VM management?
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/azure-arc-vm-management-overview?view=azloc-2606
• [4] Microsoft: Azure Local VMs Enabled by Azure Arc FAQ
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/azure-arc-vms-faq?view=azloc-2606
• [5] Microsoft: Azure Arc resource bridge maintenance
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/resource-bridge/maintenance
• [6] Microsoft: Supported operations for Azure Local VMs enabled by Azure Arc
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/virtual-machine-operations?view=azloc-2606
• [7] Microsoft: About updates for Azure Local, version 23H2
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/update/about-updates-23h2?view=azloc-2607
• [8] Microsoft: Import and discover update packages for limited connectivity
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/update/import-discover-updates-offline-23h2?view=azloc-2607
• [9] Microsoft: Best practices for managing Azure Local updates
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/update/update-best-practices?view=azloc-2607
• [10] Microsoft: Use the Support tool to troubleshoot and fix Azure Local infrastructure problems
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/remediate-support-tool-infrastructure?view=azloc-2606
• [11] Microsoft: Connectivity modes in AKS on Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/connectivity-modes
• [12] Microsoft: Support policies for AKS on Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/aks-on-azure-local-support-policy
• [13] Microsoft: Troubleshoot Azure Arc-enabled servers in disconnected scenarios
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/servers/troubleshoot-connectivity
• [14] Microsoft: Identity and authorization
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/servers/security-identity-authorization
• [15] Microsoft: Connected Machine agent network requirements
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/servers/network-requirements
• [16] Microsoft: Firewall requirements for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/firewall-requirements?view=azloc-2606
• [17] Microsoft: About Azure Arc gateway for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/deploy/deployment-azure-arc-gateway-overview?view=azloc-2606
• [18] Microsoft: Monitor multiple Azure Local systems with Insights
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/monitor-multi-23h2?view=azloc-2606
• [19] Microsoft: Manage Azure Local VMs enabled by Azure Arc
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-arc-virtual-machines?view=azloc-2606
• [20] Microsoft: Get remote support for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/get-remote-support?view=azloc-2606
• [21] Microsoft: Collect diagnostic logs for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/collect-logs?view=azloc-2606
• [22] Microsoft: Disconnected operations for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview?view=azloc-2606
• [23] Microsoft: Activate Windows Server VMs on Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/vm-activate?view=azloc-2606
• [24] Microsoft: Azure verification for VMs on Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/deploy/azure-verification?view=azloc-2606
• [25] Microsoft: Known issues in Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/known-issues?view=azloc-2607
• [26] Microsoft Q&A: Arc Resource Bridge VM is missing
  Canonical URL: https://learn.microsoft.com/en-us/answers/questions/5903812/arc-resource-bridge-vm-is-missing
• [27] Microsoft Q&A: 12.2604.1003.209 update failed at the CAU attempt step and will not retry
  Canonical URL: https://learn.microsoft.com/en-us/answers/questions/5900042/12-2604-1003-209-update-failed-at-the-cau-attempt
• [28] Microsoft Q&A: Azure Local Deployment Failed – How do I recover the nodes to try again?
  Canonical URL: https://learn.microsoft.com/en-us/answers/questions/2277860/azure-local-deployment-failed-how-do-i-recover-the
• [29] Microsoft: Troubleshoot Azure Arc resource bridge issues
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/resource-bridge/troubleshoot-resource-bridge
• [30] Microsoft: Monitor clusters with the Health Service
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/health-service-overview?view=azloc-2606

The post What Fails When Azure Local Loses Azure? Arc Resource Bridge, Connectivity, Updates, and Recovery Boundaries appeared first on Digital Thought Disruption.