Azure Local Has Two SDN Operating Models: Arc-Managed Networking Versus Full On-Premises SDN

Introduction

Azure Local networking becomes confusing when the same words appear in several different product contexts. Logical network, virtual network, network security group, load balancer, gateway, and Network Controller all sound familiar to anyone who has worked with Azure or VMware NSX. The names create an understandable expectation that the underlying capabilities and operating models will also be familiar.

That expectation is dangerous.

Microsoft now documents two distinct ways to operate software-defined networking on Azure Local: SDN enabled by Azure Arc and SDN managed through on-premises tools. These are not two interfaces controlling the same complete resource model. They have different Network Controller deployment models, different supported resources, different VM scopes, different management tools, and different operational dependencies. Microsoft explicitly identifies mixed management between the two as unsupported [1].

The architectural decision therefore cannot begin with a question such as, “Do we want to use the Azure portal or Windows Admin Center?” The correct starting question is, “Which networking services must the platform deliver, and which management plane is the organization prepared to operate?”

TL;DR

Azure Local offers two materially different SDN operating models.

SDN enabled by Azure Arc is designed for Azure Local VMs managed through Azure Resource Manager. It provides Azure-managed logical networks, VM network interfaces, and network security groups. Its Network Controller runs as a Failover Cluster service integrated into Azure Local lifecycle management. It does not provide virtual networks, Software Load Balancers, or VPN, GRE, and L3 gateways in the hyperconverged operating model covered here.

SDN managed by on-premises tools uses dedicated Network Controller VMs and can optionally add Software Load Balancer and gateway infrastructure. It supports logical networks, virtual networks, NSGs, load balancing, and VPN, GRE, or L3 gateway connections. It is managed through Windows Admin Center, PowerShell, SDN Express, and potentially System Center Virtual Machine Manager.

Choose Arc-managed SDN when VLAN-backed networks, Azure-managed VM resources, and basic NSG enforcement are sufficient. Choose on-premises SDN when the platform itself must provide overlays, tenant virtual networks, distributed network services, load balancing, or software gateways.

Neither model should be described as complete Azure networking on-premises. Azure-like names do not guarantee Azure-equivalent capabilities, APIs, service integrations, scale characteristics, or operational tooling.

Scope and Version Guardrails

This article focuses primarily on the hyperconverged Azure Local operating model represented in Microsoft’s core SDN comparison documentation.

The current support baselines are important:

• SDN enabled by Azure Arc requires Azure Local 2506 or later with operating-system build 26100.xxxx or later [1].
• SDN managed by on-premises tools is available for Azure Local 2311.2 or later [1].
• Arc-managed SDN is enabled through a PowerShell lifecycle action and cannot currently be rolled back or disabled after enablement [2].
• Multi-rack Azure Local 2511 and later introduces additional network-fabric and virtual-network resource paths. Those capabilities have their own requirements and should not be assumed to apply to every hyperconverged Azure Local deployment.
• The term full on-premises SDN in this article means the Network Controller, SLB, and gateway-based Windows SDN stack. It does not mean full feature parity with Microsoft Azure or VMware NSX.

The last distinction matters. A resource called a virtual network on Azure Local is not automatically equivalent to an Azure VNet in service integration, routing, security, observability, or lifecycle behavior.

The Core Mental Model: Two Owners of Network State

The most useful way to understand the choice is to identify which control plane owns the authoritative network state.

The left side treats supported network objects as Azure-managed resources. The right side treats SDN as an on-premises infrastructure service.

That difference affects far more than where an administrator clicks. It determines resource scope, automation interfaces, lifecycle ownership, break-glass procedures, monitoring, support boundaries, and the skills the platform team must retain.

VLAN-Backed Logical Networks Are the Common Foundation

Both models support logical networks, but the term must be interpreted correctly.

A logical network is a logical representation of a physical network on which VMs can be provisioned. It carries information such as:

• Address prefix
• IP-allocation method
• IP pool
• Default gateway
• DNS servers
• VLAN ID
• External virtual-switch association

In the common hyperconverged deployment pattern, a logical network projects an existing Layer 2 or Layer 3 network into the Azure Local VM-consumption layer. It does not automatically create an overlay, a tenant routing domain, a distributed router, a NAT service, or a software-defined edge [7][8].

Logical Network Versus Virtual Network

The distinction can be summarized this way:

Property	Logical network	Virtual network
Primary purpose	Represent an existing physical or VLAN-backed network	Create a software-defined tenant network
Underlay dependency	Directly associated with physical VLAN and subnet design	Uses an HNV provider network as its underlay
Default gateway	Usually exists in the physical network	Can use SDN gateway and routing constructs
Address isolation	VLAN and subnet based	Overlay-based tenant address space
Overlapping tenant addresses	Generally not a logical-network function	An overlay use case where supported
Arc-managed hyperconverged support	Yes	No
On-premises SDN support	Yes	Yes
Equivalent to Azure VNet	No	No, despite similar naming

A logical network plus an NSG can provide useful segmentation and filtering. It still does not replace a routed virtual-network fabric.

SDN Enabled by Azure Arc

SDN enabled by Azure Arc is the Azure-managed model for network resources associated with Azure Local VMs.

Network Controller Deployment

The Network Controller is deployed as a Failover Cluster service rather than as a set of dedicated VMs. Azure Local’s orchestrator, also described as Lifecycle Manager, deploys and manages the service [2].

The enablement action uses PowerShell:

Add-EceFeature `
    -Name NC `
    -SDNPrefix "edge01" `
    -AcknowledgeMaintenanceWindow `
    -AcknowledgeDNSRecordCreation

The SDNPrefix becomes part of the Network Controller REST endpoint name. The DNS record and reserved address must be prepared correctly before enablement. The action also enables the Azure Virtual Filtering Platform extensions on the relevant virtual switch.

What successful execution should produce:

• Network Controller services running as clustered resources
• A resolvable Network Controller REST endpoint
• VFP extensions enabled on the compute virtual switch
• Existing Azure Local logical networks and NICs hydrated into Network Controller
• Azure-managed network resources remaining visible through the Azure control plane

What can go wrong:

• The prefix violates naming rules.
• The REST endpoint DNS record points to the wrong address.
• The required address is already in use.
• A Network Controller deployed through on-premises tools already exists.
• The operation is attempted without a production maintenance window.
• Unsupported host-network intent combinations are in use.

Microsoft warns that enablement briefly disrupts VM networking while VFP policy is applied. It also states that the operation cannot currently be rolled back or disabled [2].

Supported Resource Scope

For the hyperconverged operating model, Arc-managed SDN supports:

• Logical networks
• Azure Local VM network interfaces
• Network security groups
• Network security rules
• NSG association with logical networks
• NSG association with Azure Local VM NICs

It does not support the following network resources in this operating model:

• Virtual networks
• Software Load Balancers
• VPN gateways
• GRE gateways
• L3 gateways [1]

This is the first major place where Azure-style naming can mislead an architecture team. The presence of Azure Resource Manager, a custom location, logical networks, and NSGs does not mean Azure Load Balancer, Azure Firewall, Azure Virtual Network Gateway, Azure Route Server, Azure Network Manager, or the complete Azure VNet model has been projected into the datacenter.

Azure Local VM Scope

Arc-managed NSGs are scoped to Azure Local VMs. These are VMs created and managed through Azure client interfaces, including:

• Azure portal
• Azure CLI
• Azure Resource Manager
• Supported declarative resource templates

The network interface and logical network are Azure resources associated with the Azure Local custom location.

A VM created locally through Hyper-V Manager, Failover Cluster Manager, Windows Admin Center, or similar tools is an unmanaged VM from the Azure control-plane perspective. The Arc-managed NSG model is not intended to make locally created VMs part of the same policy scope automatically [1][9].

Management Interfaces

Arc-managed SDN has a deliberate management boundary:

Interface	Arc-managed role
Azure portal	Supported creation and management interface
Azure CLI	Supported creation and management interface
ARM templates	Supported declarative interface
Terraform or AzAPI	Available for supported projected resource types where documented
PowerShell	Used to enable the Network Controller integration
Windows Admin Center	Not a supported day-2 interface for Arc-managed SDN objects
SDN Express	Not a supported day-2 interface for Arc-managed SDN objects
Direct Network Controller API changes	Unsupported for Azure Local VM resources

PowerShell therefore has two different meanings in this discussion. It enables the Arc-integrated Network Controller, but the supported day-2 resource interfaces remain the Azure portal, Azure CLI, and Azure Resource Manager templates [1][2].

Example Arc-Managed Logical Network

The following example creates a static logical network using the CLI. The CLI retains stack-hci-vm in the command namespace even though the current product name is Azure Local.

$subscription       = "<subscription-id>"
$resourceGroup      = "rg-azurelocal-prod"
$customLocationId   = "<custom-location-resource-id>"
$location           = "eastus"
$logicalNetwork     = "lnet-app-prod"
$vmSwitchName       = '"ConvergedSwitch(management_compute_storage)"'
$addressPrefix      = "10.40.20.0/24"
$gateway            = "10.40.20.1"
$dnsServers         = "10.40.10.10 10.40.10.11"
$vlan               = "420"

az stack-hci-vm network lnet create `
    --subscription $subscription `
    --resource-group $resourceGroup `
    --custom-location $customLocationId `
    --location $location `
    --name $logicalNetwork `
    --vm-switch-name $vmSwitchName `
    --ip-allocation-method "Static" `
    --address-prefixes $addressPrefix `
    --gateway $gateway `
    --dns-servers $dnsServers `
    --vlan $vlan

The values must be changed to match the real external virtual switch, VLAN, subnet, DNS, gateway, custom location, and Azure region.

A successful command creates an Azure Resource Manager representation of the logical network and reconciles that resource with Azure Local. It does not configure the upstream switch, create the VLAN on the physical fabric, or add the subnet to an external router.

SDN Managed Through On-Premises Tools

The on-premises model is the broader Windows SDN stack. It uses dedicated infrastructure VMs and can be deployed incrementally.

Network Controller Deployment

Network Controller runs on dedicated VMs rather than as an Azure Local Failover Cluster service. It can be deployed with:

• Windows Admin Center
• SDN Express PowerShell scripts
• System Center Virtual Machine Manager in supported designs

Once Network Controller is present, the organization can add Software Load Balancer and gateway infrastructure according to its service requirements [3][5][6].

This infrastructure has its own lifecycle:

• Operating-system patching
• Certificate maintenance
• VM placement and availability
• Infrastructure IP planning
• Capacity monitoring
• Backup and recovery procedures
• Upgrade sequencing
• Health validation
• Troubleshooting and log collection

The additional capability is real, but so is the additional operational burden.

Network Controller Capabilities

Network Controller can manage:

• Traditional VLAN-backed logical networks
• Virtual networks and subnets
• VM network interfaces
• NSG and ACL policy
• Microsegmentation
• Quality-of-service policy
• Virtual appliances
• User-defined routing
• Virtual-network peering
• Overlay network policy [3][4]

An organization can deploy Network Controller without immediately deploying SLB or gateway VMs. This phased approach is useful when the initial requirement is VLAN-backed NSGs, QoS, or virtual-network policy rather than a complete software-defined edge.

Software Load Balancer

Software Load Balancer adds Layer 4 load-balancing and NAT services. It can support workloads connected to VLAN-backed logical networks and virtual networks [16].

The architecture includes SLB multiplexer VMs and host agents. BGP is used to advertise virtual IP addresses to the physical network.

Common services include:

• Internal load balancing
• External or public VIP load balancing
• Inbound NAT
• Outbound NAT
• Health probes
• TCP and UDP load balancing
• Load balancing across multiple backend VMs

SLB is not an application-delivery controller and should not be treated as an automatic replacement for NSX Advanced Load Balancer, F5 BIG-IP, Citrix NetScaler, NGINX, or another Layer 7 platform.

Gateway Services

Gateway VMs provide connectivity between SDN virtual networks and external networks.

Supported connection types include:

• Site-to-site IPsec VPN
• GRE tunnels
• L3 forwarding [3]

Gateway services depend on careful planning of:

• HNV provider addresses
• Provider VLAN
• Gateway front-end and back-end interfaces
• BGP autonomous-system numbers
• External router peers
• Public and private VIP ranges
• GRE VIP ranges where needed
• Active and redundant gateway capacity

A gateway is not merely a default-gateway field attached to a logical network. It is a stateful infrastructure service with its own VMs, routing state, capacity, redundancy, and external dependencies.

Capability Comparison

The following matrix reflects the hyperconverged operating model discussed in Microsoft’s two-method comparison.

Capability	SDN enabled by Azure Arc	SDN managed on-premises	Architectural implication
VLAN-backed logical networks	Yes	Yes	Both can connect VMs to existing physical networks
Azure Local VM NIC resources	Yes	Not the primary scope	Arc-managed resources belong to Azure Local VM lifecycle
Hyper-V or SCVMM VM NIC management	No	Yes	On-premises tools manage unmanaged VMs
NSGs on logical networks	Yes	Yes	Policy owner and VM scope differ
NSGs on individual NICs	Yes, for Azure Local VMs	Yes, for unmanaged VMs	Do not cross the management boundary
Virtual networks and subnets	No	Yes	Overlay networking requires the on-premises model
Overlapping tenant address spaces	No native Arc-managed overlay	Possible through supported HNV designs	Requires provider-network planning
User-defined routing	No Arc-managed VNet construct	Supported with virtual networks	Not equivalent to an Azure route table
Virtual-network peering	No	Supported	Remains an on-premises SDN function
Software Load Balancer	No	Optional	External ADC or physical load balancer is needed in Arc-only designs
Inbound and outbound NAT	No SDN SLB service	Supported with SLB	External firewall or ADC may supply NAT in Arc-only designs
L3 gateway	No	Optional	Physical routing remains authoritative in Arc-only designs
Site-to-site VPN gateway	No	Optional	Use external firewall/router in Arc-only designs
GRE gateway	No	Optional	Requires on-premises gateway infrastructure
BGP-advertised VIPs	No SDN SLB	Yes	BGP fabric integration is a major design threshold
Azure portal management	Yes	No for full on-premises SDN resources	Portal visibility is not feature parity
Azure CLI management	Yes	Not the primary model	On-premises automation uses PowerShell and controller interfaces
ARM templates	Yes	No equivalent projection for full stack	Different infrastructure-as-code pipelines
Windows Admin Center	Unsupported for Arc-managed SDN changes	Yes	Avoid mixed authority
SDN Express	Unsupported for Arc-managed SDN changes	Yes	Primarily deployment and on-premises operations
SCVMM integration	No	Supported where applicable	Relevant for existing System Center estates
Arc Resource Bridge dependency	Yes for Azure management projection	Not for local SDN object management	Workload operation and cloud management availability differ
AKS on same Azure Local instance	Yes	Requires workload-specific validation	AKS does not gain all SDN services automatically
NSGs on AKS logical networks or AKS NICs	No	Do not assume support	Kubernetes policy remains a separate control domain
Multicast workload support	No	Validate separately	Arc-managed SDN currently facilitates unicast traffic

Arc Resource Bridge Visibility Is Not the Same as Data-Plane Ownership

Azure Arc Resource Bridge provides the projection that allows Azure Resource Manager to manage supported resources on Azure Local. It connects Azure, the custom location, and the local resource providers used for VM and AKS lifecycle management [11][12].

For Arc-managed networking, this means the portal can show and manage supported logical networks, NICs, and NSGs as Azure resources.

For on-premises SDN, the Azure portal may still show the Azure Local instance and its Arc-enabled resources, but the complete Network Controller, SLB, gateway, virtual-network, and policy inventory is not transformed into an equivalent Azure networking resource model. Day-2 operations remain with the local management stack.

What Happens When Arc Resource Bridge Is Unavailable?

Existing workloads should continue to operate when Arc Resource Bridge is unavailable, but Azure can lose visibility and management capability for projected resources [12].

That creates an important operational consequence for Arc-managed SDN:

• Existing VM traffic does not become dependent on every packet traversing Azure.
• New Azure management operations can fail or become unavailable.
• Portal and ARM visibility can become stale.
• Local tools are not an approved alternative control plane for changing Arc-managed SDN resources.
• A break-glass runbook must distinguish guest-network troubleshooting from unsupported control-plane modification.

Arc-managed does not mean that the data path is hairpinned through Azure. It means that Azure is the supported management authority for the projected network resources.

Mixed Management Is an Unsupported Architecture

The most important support rule is also one of the easiest to violate.

If Network Controller was deployed with on-premises tools, do not attempt to enable the Arc-managed model. If Network Controller was deployed through Add-EceFeature, do not attempt to deploy or manage the same SDN environment with Windows Admin Center or SDN Express [1][2].

Do not:

• Enable Arc-managed SDN over an existing on-premises Network Controller.
• Deploy on-premises Network Controller VMs after enabling the Arc-integrated controller.
• Modify Arc-managed Azure Local VM NICs directly through Network Controller APIs.
• Apply an on-premises-managed NSG to an Azure Local VM NIC.
• Modify Arc-managed network objects through Windows Admin Center.
• Treat Azure portal state and Network Controller state as independently editable copies.
• Use a local command merely because it appears technically capable of changing the underlying switch.

The risk is not only configuration drift. Microsoft warns that unsupported direct modifications can place resources into bad or unrecoverable states [10].

A reliable operating model has one authoritative control plane, one supported reconciliation path, and one documented recovery boundary.

Managed and Unmanaged VMs Must Be Separated Deliberately

Azure Local can expose two different VM-management experiences:

Azure Local VMs

• Created through Azure interfaces
• Represented as Azure Resource Manager resources
• Associated with a custom location
• Managed through Azure role-based access control
• In scope for Arc-managed NSGs

Unmanaged VMs

• Created through local Hyper-V-oriented tools
• Managed through Windows Admin Center, Hyper-V Manager, Failover Cluster Manager, PowerShell, or SCVMM
• Not automatically represented by the same Azure VM resource model
• In scope for on-premises SDN policy where supported

The distinction should appear in the platform design, naming standard, automation repositories, support model, and ownership matrix.

A VM should not silently move between management domains. Importing an unmanaged VM into an Azure-managed lifecycle is not equivalent to merely discovering it, and applying network policy from the wrong tool is not a supported shortcut.

IP Pools, DNS, Gateways, and Multiple NICs

Many production issues attributed to SDN are conventional IP-design failures that were hidden by automation.

IP-Pool Design

A logical network must reserve enough addresses for the workload lifecycle, not merely the initial VM count.

Plan for:

• Current VM NICs
• Deployment growth
• Replacement or rolling-upgrade overlap
• AKS control-plane and node addresses
• Load-balancer address pools
• Migration waves
• Temporary coexistence
• Reserved network devices
• Monitoring or recovery appliances

Overlapping IP pools on the same VLAN are not permitted. IP exhaustion can prevent VM or AKS deployment even when compute and storage capacity remain available [7][13].

Immutable Logical-Network Properties

After a logical network is created, several properties cannot be modified in place, including:

• Default gateway
• IP pools
• Address space
• VLAN ID
• Virtual-switch name [7][8]

Treat logical-network creation as a controlled infrastructure change. A typographical error can require creating a replacement network and moving workloads.

DNS

A workload logical network can carry DNS-server configuration. DNS changes may apply only to newly created VMs, depending on the resource and feature state. Existing guests may require manual changes [8].

DNS planning must include:

• Forward and reverse resolution
• Network Controller REST records
• Azure Local management dependencies
• Guest DNS configuration
• AKS name resolution
• Conditional forwarding between zones
• Recovery-site and migration dependencies

DNS should never be treated as an optional text field added after the addressing plan is complete.

Default Gateways

In an Arc-managed logical network, the default gateway normally belongs to the physical network. Creating the logical network does not create that router.

In the on-premises virtual-network model, a software gateway can provide L3 connectivity between the tenant virtual network and external networks. That is a separate service from the logical network’s gateway field.

Multiple NICs

When an Azure Local VM receives multiple static NICs, each NIC can initially receive the logical network’s default gateway. Microsoft instructs administrators to remove the default gateway from secondary NICs to prevent:

• Asymmetric routing
• Packet loss
• Unpredictable reply paths
• Incorrect egress selection [1][10]

The normal enterprise design should provide:

• One default route per guest
• Explicit routes for secondary networks
• Clear management, backup, storage, replication, or application-NIC roles
• Guest-operating-system validation after provisioning
• Firewall policy that recognizes the actual return path

A multi-NIC VM is not complete when all NIC resources show a successful provisioning state. Guest route validation is part of deployment acceptance.

AKS Networking Considerations

AKS on Azure Local adds another network domain. It should not be treated as ordinary VM networking with Kubernetes labels added.

AKS uses Azure Local logical networks to allocate addresses to the VMs that form the Kubernetes control plane and node pools. Static allocation is required because node addresses must remain stable through the cluster lifecycle [13][14].

Plan addresses for:

• One address per control-plane or worker VM
• One control-plane virtual IP per AKS cluster
• Kubernetes service exposure
• MetalLB or another load-balancer implementation
• Cluster upgrades and node-pool growth
• Temporary replacement nodes
• Ingress controllers
• External application endpoints

AKS Does Not Inherit the Full SDN Feature Set

Microsoft documents that AKS can run on an Azure Local instance where SDN enabled by Arc is configured. It also states that NSGs cannot be associated with the logical network used for AKS deployment or with AKS workload VM NICs [1].

The current AKS networking documentation further states that software-defined virtual networks and SDN-related features are not supported for AKS on Azure Local [13].

These statements are compatible when interpreted correctly:

• AKS can coexist with Arc-enabled SDN on the same Azure Local instance.
• AKS still consumes static logical-network addressing.
• The AKS workload network is not brought under the Arc-managed NSG policy model.
• Kubernetes NetworkPolicy, ingress controls, service exposure, and application load balancing remain separate Kubernetes design concerns.
• A legacy guide for AKS on Windows Server should not be assumed to define the current support model for AKS on Azure Local.

Use a dedicated logical network and IP plan for AKS. Do not reuse a general-purpose Azure Local VM logical network merely because the VLAN and subnet appear suitable.

Hub and Spoke L3 Design

A hub-and-spoke design means different things in the two operating models.

Arc-Managed Hub and Spoke

Arc-managed logical networks do not supply native SDN L3 gateways or virtual-network peering. The hub therefore exists outside the Azure Local Arc-managed resource model.

Typical hub functions are supplied by:

• Physical routers
• Datacenter firewalls
• A routed leaf-spine fabric
• External network-virtualization platforms
• Physical or virtual application-delivery controllers
• Cloud connectivity appliances

The Azure Local logical networks become spoke attachment networks. Routing, NAT, VPN, route exchange, service insertion, and advanced firewalling remain external.

This pattern can be highly effective. It is often simpler than deploying full SDN when the enterprise already has a mature physical fabric and firewall platform.

On-Premises SDN Hub and Spoke

The on-premises model can place tenant workloads in virtual networks and use SDN gateways for external connectivity. Virtual-network peering and user-defined routing can participate in a software-defined topology [4].

However, this is not a direct recreation of Azure Virtual WAN or the complete Azure hub-and-spoke operating model. The organization still owns:

• Gateway VM capacity
• BGP sessions
• Route propagation
• Network Controller health
• Provider-network addresses
• Failover behavior
• SLB and gateway certificates
• Infrastructure VM lifecycle
• External-fabric integration

The on-premises model provides more network services, but it also makes the Azure Local platform team responsible for operating those services.

Physical Network and BGP Integration

The physical network remains an architectural dependency in both models.

Arc-Managed Physical Integration

For Arc-managed VLAN-backed logical networks, the physical fabric must provide:

• VLAN availability on every relevant host uplink
• Correct trunk or access behavior
• Subnet gateway
• Inter-VLAN routing
• North-south routing
• MTU consistency
• Redundancy
• Reachability to DNS and required services

Arc-managed SDN does not create BGP peers simply because the network resource is visible in Azure.

On-Premises Full SDN Integration

The on-premises model introduces an HNV provider network for virtual networks. The provider network carries encapsulated tenant traffic and supplies connectivity for SLB and gateway infrastructure [4].

SLB and gateway services can require:

• BGP-capable Layer 3 switches or routers
• ECMP
• Provider-address VLAN and subnet
• SLB MUX provider addresses
• Gateway provider addresses
• Public and private VIP prefixes
• GRE prefixes where used
• Correct autonomous-system-number design
• Sufficient MTU for encapsulated traffic

BGP is not required merely to create a VLAN-backed logical network with Network Controller. It becomes central when SLB, gateways, VIP advertisement, and overlay connectivity enter the design.

Migration from VMware NSX

An NSX migration should begin with service decomposition, not component-name matching.

The question is not, “What is the Azure Local equivalent of an NSX segment?” The better questions are:

• Is the segment VLAN-backed or overlay-backed?
• Does it rely on overlapping tenant addresses?
• Where does its default gateway run?
• Does it use distributed routing?
• Which firewall rules depend on groups, tags, or identity?
• Does it use NAT, load balancing, VPN, DHCP, or service insertion?
• Which operational tools are required for troubleshooting?
• Must the workload preserve its IP address during migration?

Practical NSX Mapping

NSX function	Arc-managed target	On-premises SDN target	Migration warning
VLAN-backed segment	Logical network	Logical network	Validate VLAN presence on all Azure Local hosts
Overlay segment	No direct Arc-managed equivalent	Virtual network	Requires HNV provider-network design
Distributed firewall rule	NSG where supported	NSG or ACL policy	Feature semantics are not identical
Tier-0 routing	External router or firewall	SDN gateway plus physical fabric	Do not map the name alone
Tier-1 routing	External routed VLAN design	Virtual-network routing design	Validate routing and tenancy requirements
NSX Edge VPN	External VPN appliance	SDN VPN gateway	Rebuild tunnels and validate failover
NSX Edge GRE	External router	SDN GRE gateway	Encryption and routing semantics differ
NSX load balancer	External ADC or Kubernetes ingress	SLB for Layer 4 use cases	SLB does not replace Layer 7 services
NAT	External firewall or ADC	SLB or gateway design	Inventory every rule and dependency
NSX groups and tags	Azure resource governance plus NSG rules	Controller ACL model	Dynamic membership may require redesign
Traceflow and flow analytics	External observability stack	SDN diagnostics and local tooling	Troubleshooting workflow changes

Migration Sequence

A controlled migration should use the following phases.

Inventory the NSX service dependency

Export segments, gateways, routes, NAT, VPN, load-balancer pools, firewall policy, address groups, DHCP, DNS dependencies, and physical uplinks.

Classify each network

Place every network into one of four target patterns:

• Existing VLAN mapped to an Arc-managed logical network
• Existing VLAN mapped to an on-premises logical network
• Overlay network redesigned as an on-premises virtual network
• Network service moved to an external firewall, router, ADC, or Kubernetes layer

Select the Azure Local SDN operating model

Do this before deploying Network Controller. The choice is not safely deferred until after workload migration.

Build the physical prerequisites

Create VLANs, trunks, routes, gateway interfaces, DNS records, provider networks, BGP peers, and VIP ranges before moving production VMs.

Translate policy

Rebuild rules according to the target enforcement point. Do not convert an NSX distributed-firewall export into an NSG rule list without validating statefulness, priorities, scope, return traffic, and workload identity.

Test representative applications

Include multi-tier applications, multi-NIC VMs, backup traffic, monitoring, directory services, east-west flows, north-south publishing, and failure scenarios.

Preserve or change IP addresses deliberately

Azure Migrate requires a target logical network on Azure Local. Existing addresses can be preserved only when the target network, VLAN, routing, and policy support them [15].

Remove NSX dependencies only after validation

A VM booting on Azure Local is not evidence that the application has successfully exited NSX.

Operating Patterns

Pattern: Azure-Managed VLAN Consumption

Best fit: Enterprises that want Azure-managed VM lifecycle, familiar VLAN-backed connectivity, and NSG policy without operating a complete SDN edge.

Components:

• Azure Local VMs
• Arc Resource Bridge
• Arc-managed logical networks
• Arc-managed NICs
• NSGs
• Existing physical routers and firewalls
• External load balancer where needed

Strengths:

• Azure portal, CLI, and ARM workflows
• Lower SDN infrastructure-VM overhead
• Clear alignment with Azure Local VM management
• Existing enterprise network services remain reusable

Tradeoffs:

• No Arc-managed virtual networks
• No Arc-managed SLB
• No Arc-managed VPN, GRE, or L3 gateway
• External platform remains responsible for routing and advanced services
• Azure connectivity affects management availability

Pattern: On-Premises SDN Service Fabric

Best fit: Hosting platforms, complex multitenancy, overlay requirements, overlapping addresses, software gateways, and BGP-advertised VIPs.

Components:

• Network Controller VMs
• Optional SLB MUX VMs
• Optional gateway VMs
• HNV provider network
• Logical and virtual networks
• On-premises management tools
• BGP-capable physical fabric

Strengths:

• Broadest Azure Local SDN service set
• Virtual networks and overlays
• Integrated Layer 4 load balancing
• VPN, GRE, and L3 gateway options
• Phased deployment based on required services

Tradeoffs:

• Additional infrastructure VMs
• Separate patch, certificate, backup, and recovery lifecycle
• No Azure portal operating model for the full stack
• Greater BGP, IPAM, routing, and troubleshooting complexity
• Higher skills and support burden

Pattern: Arc-Managed VMs with External Network Services

This is often the most practical enterprise compromise.

Use Arc-managed logical networks, NICs, and NSGs for VM consumption, while retaining a dedicated firewall, router, ADC, or fabric controller for:

• Hub-and-spoke routing
• NAT
• VPN
• Internet publishing
• Layer 7 load balancing
• Advanced firewall policy
• Network telemetry
• Cross-platform connectivity

This pattern avoids operating the full on-premises SDN stack while still preserving Azure-managed VM workflows.

Decision Tree

The decision should then be tested against VM-management scope:

• Azure Local VMs point toward Arc-managed SDN.
• Hyper-V or SCVMM-managed VMs point toward on-premises SDN.
• A mixed estate requires explicit boundaries, not mixed control over the same resource.

Implementation and Validation Checklist

Architecture Decision

• Identify whether the article’s hyperconverged scope matches the intended Azure Local deployment type.
• Record the required Azure Local version and build.
• Decide whether VMs will be Azure managed or locally managed.
• Inventory required virtual-network, SLB, NAT, VPN, GRE, and L3 services.
• Decide which system owns routing and firewalling.
• Document whether overlapping tenant addresses are required.
• Record the management tools the operations team will support.
• Approve one Network Controller deployment method.

Physical Network

• Confirm external virtual-switch names.
• Create required VLANs on all host-facing switch ports.
• Validate trunk and native-VLAN behavior.
• Confirm gateway addresses and subnet routing.
• Reserve logical-network IP pools.
• Exclude DNS, gateway, infrastructure, and network-device addresses.
• Validate MTU end to end.
• Configure BGP and ECMP where SLB or gateways require them.
• Reserve provider, public VIP, private VIP, and GRE ranges where applicable.

DNS and Certificates

• Create or validate the Network Controller REST record.
• Confirm forward and reverse resolution.
• Verify certificate names and trust.
• Document certificate renewal.
• Test name resolution from every Azure Local host and management station.

Arc-Managed Enablement

• Verify no on-premises Network Controller is installed.
• Confirm the deployment uses a supported network-intent pattern.
• Schedule a maintenance window.
• Record existing logical networks and NICs.
• Run the enablement action.
• Validate Network Controller clustered resources.
• Validate VFP extension state.
• Confirm resource hydration.
• Test portal, CLI, and ARM operations.
• Confirm Windows Admin Center and SDN Express are excluded from the change procedure.

On-Premises Deployment

• Decide whether Network Controller alone is sufficient.
• Add SLB only when Layer 4 load balancing or NAT is required.
• Add gateways only when VPN, GRE, or L3 forwarding is required.
• Size and place infrastructure VMs.
• Patch source images and deployed infrastructure VMs.
• Configure backups and recovery procedures.
• Validate Network Controller, SLB, and gateway health.
• Test BGP advertisements and withdrawal.
• Test active and redundant gateway behavior.
• Test VIP health probes and backend removal.

Workload Validation

• Create a representative VM on each logical network.
• Test DNS, gateway, east-west, and north-south connectivity.
• Validate NSG rule order and default behavior.
• Test an empty NSG safely in a lab, since it denies inbound connectivity by default.
• Test multiple NICs and remove secondary default gateways.
• Validate guest routes after provisioning.
• Validate live migration across every host.
• Test Arc Resource Bridge loss without using unsupported local changes.
• Test AKS control-plane, node, service, and load-balancer address allocation.
• Record evidence for support handoff.

Common Misunderstandings

“It Is Managed from Azure, So It Must Have Azure VNet Features”

False. Arc-managed SDN for the hyperconverged model supports logical networks, NICs, and NSGs. Microsoft explicitly lists virtual networks, SLBs, and gateways as unsupported [1].

“An NSG Replaces the NSX Distributed Firewall”

Not by itself. Azure Local NSGs filter according to source and destination addresses, ports, protocols, and direction. An NSX operating model may also rely on groups, tags, identity, service insertion, contextual policy, distributed routing, and a richer troubleshooting ecosystem.

“A Logical Network Is an Overlay”

Usually false. A logical network commonly represents an existing VLAN-backed physical network. Overlay virtual networking is a separate capability.

“We Can Start with Windows Admin Center and Move to Arc Later”

Not by managing the same Network Controller deployment with both methods. The Network Controller deployment method is an architectural commitment, not a temporary UI preference.

“Arc Resource Bridge Is in the Data Path”

False. It is part of the management projection. Workload packets do not traverse Azure merely because the network resource is managed through Azure.

“AKS Can Use the Same NSGs as Azure Local VMs”

Not in the documented Arc-managed model. NSGs are not supported on the logical network used for AKS deployment or on AKS workload VM NICs [1].

“Full On-Premises SDN Recreates NSX”

False. It supplies a broader software-defined network stack, but the component model, APIs, policy semantics, routing design, service integrations, scale boundaries, and operating procedures remain different.

Conclusion

Azure Local does not have one SDN architecture with several interchangeable management interfaces. It has two operating models with different control planes and different capability boundaries.

SDN enabled by Azure Arc is the right choice when the enterprise wants Azure-managed VM consumption, VLAN-backed logical networks, and NSG enforcement without operating a complete software-defined edge. Its simplicity is valuable, but only when the missing virtual-network, load-balancing, NAT, VPN, GRE, and L3 gateway services are either unnecessary or supplied elsewhere.

SDN managed through on-premises tools is appropriate when Azure Local must provide its own overlays, tenant virtual networks, Layer 4 load balancing, NAT, or software gateways. Those capabilities come with infrastructure VMs, BGP integration, certificate management, patching, recovery, and a locally operated control plane.

The decision should therefore be made before Network Controller deployment and before NSX migration waves are designed. Start with the required network services, VM-management domain, physical-fabric integration, and acceptable management plane. Then choose one authoritative operating model and keep its resource ownership unambiguous.

Azure-like names are useful for learning, but they are not evidence of Azure-equivalent behavior. A logical network is not automatically a VNet. An NSG is not automatically an NSX distributed firewall. A Software Load Balancer is not an application-delivery controller. Arc visibility is not complete local network-service parity.

The strongest Azure Local design is not the one that enables the most SDN components. It is the one that assigns every network function to a clear control plane, a supported management path, and an operations team prepared to own it.

External References

[1] Microsoft: Software Defined Networking enabled by Azure Arc on Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/sdn-overview

[2] Microsoft: Enable SDN integration on Azure Local using PowerShell
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/deploy/enable-sdn-integration

[3] Microsoft: Software defined networking managed by on-premises tools in Azure Local, version 23H2
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/software-defined-networking-23h2

[4] Microsoft: Plan a Software Defined Networking infrastructure for Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/plan-software-defined-networking-infrastructure-23h2

[5] Microsoft: Deploy an SDN infrastructure using SDN Express for Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/deploy/sdn-express-23h2

[6] Microsoft: Deploy SDN managed by on-premises tools with Windows Admin Center for Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/deploy/sdn-wizard-23h2

[7] Microsoft: Create logical networks for Azure Local virtual machines enabled by Azure Arc
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/create-logical-networks

[8] Microsoft: Manage logical networks for Azure Local VMs enabled by Azure Arc
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-logical-networks

[9] Microsoft: Create network security groups on Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/create-network-security-groups

[10] Microsoft: FAQ for SDN enabled by Azure Arc on Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/sdn-frequently-asked-questions

[11] Microsoft: What is Azure Local VM management
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/azure-arc-vm-management-overview

[12] Microsoft: Azure Arc resource bridge overview
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/resource-bridge/overview

[13] Microsoft: AKS enabled by Azure Arc network requirements
Canonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/network-system-requirements

[14] Microsoft: Create logical networks for Kubernetes clusters on Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/aks-networks

[15] Microsoft: Review requirements for VMware VM migration to Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-vmware-requirements

[16] Microsoft: Manage Software Load Balancer for SDN managed by on-premises tools
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/load-balancers