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 LocalCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/sdn-overview
[2] Microsoft: Enable SDN integration on Azure Local using PowerShellCanonical 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 23H2Canonical 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 LocalCanonical 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 LocalCanonical 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 LocalCanonical 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 ArcCanonical 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 ArcCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-logical-networks
[9] Microsoft: Create network security groups on Azure LocalCanonical 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 LocalCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/sdn-frequently-asked-questions
[11] Microsoft: What is Azure Local VM managementCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/azure-arc-vm-management-overview
[12] Microsoft: Azure Arc resource bridge overviewCanonical URL: https://learn.microsoft.com/en-us/azure/azure-arc/resource-bridge/overview
[13] Microsoft: AKS enabled by Azure Arc network requirementsCanonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/network-system-requirements
[14] Microsoft: Create logical networks for Kubernetes clusters on Azure LocalCanonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/aks-networks
[15] Microsoft: Review requirements for VMware VM migration to Azure LocalCanonical 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 toolsCanonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/load-balancers
Azure Local 2607 Architecture and Upgrade Advisory: Build 12.2607.1003.71, Known Issues, and Production Readiness
TL;DR Azure Local 2607 is an architecture-significant release, but it should not receive blanket production approval. The release baseline changed quickly. Microsoft…
Next PostStay on VMware Cloud Foundation or Replatform? A CIO Decision Framework for Private Cloud ModernizationTL;DR The decision to stay on VMware Cloud Foundation or replatform should not be reduced to a licensing reaction, a hypervisor feature comparison, or a vendor preference. It is a…
The post Azure Local Has Two SDN Operating Models: Arc-Managed Networking Versus Full On-Premises SDN appeared first on Digital Thought Disruption.