Azure Arc can make servers, Kubernetes clusters, and selected on-premises infrastructure visible in Azure Resource Manager. That creates a common inventory, identity, policy, monitoring, and automation surface—but it does not turn every connected machine or network into an Azure virtual network.
The architectural mistake is to describe Azure Arc as a universal network controller. The more useful model is a layered one: Azure Arc projects supported resources into Azure; Azure services evaluate and manage those resources; guest or cluster agents perform supported work locally; and the underlying platform still owns packet forwarding, firewalls, switching, routing, and workload connectivity.
TL;DR
- Azure Arc gives supported non-Azure resources Azure identities and Resource Manager representations.
- Azure Policy evaluates applicable resource properties at a defined Azure scope.
- Azure Machine Configuration audits or configures supported operating-system and application settings inside Arc-enabled machines.
- Flux-based GitOps applies to AKS and Azure Arc-enabled Kubernetes—not to arbitrary servers or network appliances.
- Azure Local VM management uses Azure Arc resource bridge to project VMs, logical networks, NICs, disks, and images into Azure.
- Arc does not automatically translate NSGs, firewall rules, routes, or SD-WAN policy to every on-premises platform.
First identify the Arc resource type
“Arc-enabled” is not one homogeneous operating model. Governance depends on what has been connected.
| Resource type | What Azure sees | Typical governance surface | What it does not imply |
|---|---|---|---|
| Arc-enabled server | An Azure resource representing a Windows or Linux machine | Tags, Azure Policy where applicable, Machine Configuration, extensions, Azure Monitor, Defender, Update Manager | Azure does not become the server’s hypervisor, switch, or firewall |
| Arc-enabled Kubernetes | An Azure representation of a CNCF-conformant Kubernetes cluster | Inventory, Azure RBAC options, Azure Policy, monitoring, Defender, Flux/Argo CD GitOps | GitOps is not a generic VM or router configuration engine |
| Azure Local VM enabled by Arc | A VM and related resources managed through Azure Local’s Arc resource bridge | Azure RBAC, portal/CLI/PowerShell/ARM/Bicep/Terraform lifecycle operations, supported extensions | It is not the same resource type or lifecycle as a generic Arc-enabled server |
| Third-party network or security appliance | Usually no generic Arc projection of its entire control plane | Vendor manager, API, infrastructure-as-code, configuration management, or a supported Azure integration | Arc does not natively rewrite arbitrary vendor policy |
This distinction should be captured in the architecture inventory before assigning policy.
The four governance layers
1. Resource organization and access
Once a supported resource is represented in Azure, place it in the correct tenant, management-group, subscription, resource-group, region, and tagging structure. Azure role-based access control then determines who can perform supported Azure management actions at each scope.
This is the management plane. It should be designed with least privilege, group-based role assignments, privileged-identity workflows, and activity logging. It does not replace local guest permissions or application authorization.
2. Azure Policy at the resource layer
Azure Policy scope follows Azure Resource Manager scope. A policy evaluates only resources and aliases that are applicable to its definition and mode. Connecting a server to Arc does not make every operating-system, hypervisor, or network attribute available as an Azure Policy alias.
Use policy for questions such as:
- Is the resource in an allowed region or resource group?
- Are required tags present?
- Is a supported extension deployed?
- Is diagnostic configuration attached where the resource provider exposes it?
- Is an applicable security initiative assigned?
Before promising enforcement, verify that the target resource type and property are supported by the exact policy definition.
3. Machine Configuration inside the operating system
Azure Machine Configuration extends governance into supported Windows and Linux operating systems. It can audit—and for supported scenarios configure—OS, application, and environmental settings through machine-configuration packages.
This is the correct layer for many guest-state requirements: service configuration, file or registry state, local security settings, and other declared OS conditions. It still requires a tested package, supported agent path, permissions, connectivity assumptions, and exception process.
Do not represent an OS compliance result as proof that the network fabric enforced a packet-level control.
4. Kubernetes configuration with GitOps
Flux v2 GitOps continuously reconciles declared Kubernetes configuration on AKS and Azure Arc-enabled Kubernetes clusters. Flux runs in the cluster and pulls from configured Git, Helm, bucket, or Azure Blob sources.
Use it for Kubernetes namespaces, workloads, policies, and supporting cluster configuration that the selected distribution and extensions support. Do not say that Flux configures a normal Windows or Linux VM, an ESXi host, a firewall, or an SD-WAN device unless a separate supported automation path performs that work.
Where Azure Local fits
Azure Local VM management uses an Azure Arc resource bridge and custom location to project supported local resources into Azure. Administrators can create and manage Azure Local VMs, disks, images, logical networks, and network interfaces through supported Azure tools.
That is more than basic server inventory, but it is still platform-specific. Azure Local’s resource provider and controllers translate supported Resource Manager operations into local fabric actions. The supported operation list and limitations change by Azure Local release, so automation must be tested against the deployed version.
Do not substitute native Azure VM resource examples such as generic Microsoft.Compute/virtualMachines when documenting Azure Local VM deployment. Use the current Azure Local VM resource provider, CLI extension, portal workflow, or published templates for the target release.
Network governance: draw the boundary explicitly
Azure Arc can contribute identity, inventory, policy assignment, guest configuration, telemetry, and orchestration context. Actual network enforcement remains with the component that processes or controls traffic.
| Requirement | Primary enforcement point | Azure Arc contribution |
|---|---|---|
| Azure Local VM network attachment | Azure Local logical network and NIC resources | Resource projection, Azure RBAC, deployment automation |
| East-west microsegmentation | Azure Local SDN, NSX, Nutanix Flow, host firewall, Kubernetes policy, or another supported fabric | Inventory, policy context, monitoring, or automation trigger where supported |
| Guest firewall configuration | Windows/Linux firewall or endpoint-management tooling | Machine Configuration or extension-based configuration where supported |
| Physical firewall or SD-WAN rule | Vendor controller/API | Azure automation may call the vendor API, but the vendor system enforces the rule |
| Kubernetes network policy | Cluster CNI and Kubernetes policy engine | GitOps or Azure Policy can deliver or evaluate supported cluster configuration |
| Azure NSG | Azure or Azure Local resource type that explicitly supports the NSG | Policy can evaluate exposed resource properties; applicability must be verified |
An architecture diagram should show both the Azure governance path and the local enforcement path. If the lines end at different components, that is expected.
A practical governance workflow
Step 1: inventory by resource type
Record platform, resource provider, operating system, connectivity mode, owner, environment, data classification, and required controls. Separate generic Arc-enabled servers from Azure Local VMs and Kubernetes clusters.
Step 2: define scope and ownership
Choose management groups, subscriptions, resource groups, tags, and Azure RBAC assignments. Document who owns Azure policy, guest configuration, platform networking, identity, and exceptions.
Step 3: map each control to an enforcement point
For every control, record:
- authoritative requirement and version;
- target resource type;
- observed property or evidence source;
- enforcement component;
- expected result;
- exception owner and expiration;
- behavior during disconnection.
This prevents an attractive Azure dashboard from masking a control that is not actually enforced.
Step 4: pilot audit-only policies
Start with a small nonproduction scope. Confirm applicability, false positives, agent health, remediation behavior, and data-residency implications before using deny or deploy effects broadly.
Step 5: test connected and disconnected behavior
Arc agents generally use outbound connectivity, but individual services have different caching, evaluation, reporting, and reconnection behavior. Test the exact policy, extension, GitOps, monitoring, and management operation under the site’s expected WAN conditions.
Step 6: build a control-evidence dashboard
A useful dashboard separates:
- Azure resource inventory and ownership;
- policy applicability and compliance state;
- guest-configuration evidence;
- Kubernetes reconciliation state;
- platform-network enforcement state;
- agent, extension, and connectivity health;
- approved exceptions and expiration dates.
Never collapse “not applicable,” “not assessed,” “disconnected,” and “compliant” into one green status.
What Azure Arc does not do
- It does not discover and configure every on-premises subnet merely because a server on that subnet is connected.
- It does not make Azure Network Manager a universal controller for arbitrary physical or virtual networks.
- It does not apply an NSG to a generic Arc-enabled server unless the specific platform resource and feature explicitly support that operation.
- It does not convert Azure Policy JSON into Palo Alto, Fortinet, NSX, or Nutanix policy by itself.
- It does not make Flux a VM configuration engine.
- It does not guarantee local policy enforcement indefinitely while disconnected; behavior must be checked for each service and version.
Final architecture principle
Azure Arc is most valuable when it creates a governed resource model across environments without pretending those environments are identical. Use Azure for common inventory, access, policy, telemetry, and automation where supported. Keep enforcement with the server, Kubernetes cluster, Azure Local fabric, firewall, or other platform that actually owns the setting.
That boundary produces a hybrid operating model that is both ambitious and technically defensible.