TL;DR / Quick Summary:
Compare how NSX and Azure Local SDN manage north-south traffic, edge VM architecture, Tier-0 routing, and software-defined load balancing with minimal downtime.
Now that we’ve covered the brains of both solutions, it’s time to look at how traffic flows in and out — the Edge. Each solution has a unique method for handling ingress and egress traffic.
We’ll compare NSX Edge with the Azure Gateway and Software Defined Load Balancer, with helpful visuals and reference links for your research.
Feel free to check in on this series:
Youtube videos you will find useful:
NSX Edge

This is the NSX Edge Virtual Machine architecture.
At a high level, the Tier-0 router (responsible for North/South traffic) runs on an NSX Edge VM, using an embedded N-VDS logical switch on an ESXi host.
What is the Tier-0 Router?
- 1:1 mapping with an Edge VM
- Requires 2x Edge VMs for ECMP and High Availability
- Connects to physical network via BGP
- Interfaces are tied to VLAN-backed segments that connect to the core
The Tier-0 receives tenant routing info from Tier-1 and pushes default routes downward. It’s a virtual construct distributed across all transport nodes.
Service Router (SR)
Activated when any of the following services are used:
- North-South Routing
- NAT
- DHCP
- Load Balancing
- VPN
- Gateway Firewall
- Bridging
Each SR lives within the Tier-0 routing construct on the Edge VM.
What is a N-VDS Switch?
A software-defined logical switch responsible for forwarding services on a transport node.
vNIC 2/3: Data path modules (fp-ethX)
Owned by: NSX Manager
vNIC 1: Management traffic
For more information on the NSX Edges and Components, please see the below links:
https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-FBFD577B-745C-4658-B713-A3016D18CB9A.html
https://nsx.techzone.vmware.com/api/checkuseraccess?referer=/sites/default/files/NSX-T%20Reference%20Design%20Guide%203-0.pdf
Azure Gateway + Software Defined Load Balancer
Azure Local handles north-south traffic using a combination of:
- Virtual Network Gateway (for routing and hybrid connectivity)
- Azure Load Balancer (Basic and Standard tiers)
- SDN Gateway Role (for Azure Stack edge translation)
- Software Defined Load Balancer (SLB) in Azure Stack SDN
This solution separates routing, NAT, and load balancing into modular services across host infrastructure.
The Software Defined Load Balancer (SLB)

Ingress/Egress Flow
Azure SDN edge logic is defined by:
- Gateway VMs or host roles managed via Network Controller
- Interfaces mapped to logical networks and subnets
- SLB policies and NAT rules pushed down via OVSDB from controller
- Public IP mapping and floating IPs for northbound connectivity
While NSX uses Tier-0 as a unified construct, Azure distributes services across gateway pools and roles.
Software Load Balancer includes the following capabilities:
- Layer 4 (L4) load balancing services for north/south and east/west TCP/UDP traffic.
- Public network and Internal network traffic load balancing.
- Dynamic IP addresses (DIPs) support on virtual Local Area Networks (VLANs) and on virtual networks that you create by using Hyper-V Network Virtualization.
- Health probe support.
- Ready for cloud scale, including scale-out capability and scale-up capability for multiplexers and host agents.
Software Load Balancer works by mapping virtual IP addresses (VIPs) to DIPs that are part of a cloud service se
Load Balancing
Azure Stack SDN SLB operates in two modes:
- Dynamic Load Balancer (DIP): for east-west or internal services
- Frontend NAT Gateway (VIP): public access + port NAT mappings
SLB policy is applied by the Host Agent on Hyper-V, ensuring traffic flows with minimal latency.
⚖️ Comparison Summary
| Feature | NSX Edge | Azure Local SDN Gateway |
|---|---|---|
| Core Router | Tier-0 on Edge VM | VNet Gateway + SLB roles |
| North/South Routing | Tier-0 + SR with BGP | SLB with NAT + routing policies |
| Load Balancing | NSX Distributed or SR-based | SLB w/ Host Agent + OVSDB |
| Service Separation | Combined (SR) | Modular (Gateway roles + SLB) |
| API/Automation Access | NSX Manager API | Network Controller + PowerShell/REST |
For more information on the Azure SDN SLB and Components, please see the below links:
https://learn.microsoft.com/en-us/azure-stack/hci/concepts/software-load-balancer#how-software-load-balancer-works
https://learn.microsoft.com/en-us/azure-stack/hci/deploy/sdn-wizard#deploy-sdn-software-load-balancer
The SDN Gateway (GW)

SDN Gateway in Azure Local – Bridging the Hybrid Edge
In Azure Local SDN (previously Azure Stack HCI SDN), the SDN Gateway plays a critical role in enabling hybrid connectivity and north-south traffic routing. It’s the functional counterpart to NSX Edge when configured for:
- GRE/IPSec/VPN
- BGP peering
- Border traffic handling
- Hybrid cloud extension (to Azure or other DCs)
Unlike NSX, where Tier-0 and Edge VM functions are tightly coupled, Azure Local’s SDN Gateway is a dedicated role that can be scaled horizontally across hosts and integrated with Software Load Balancer (SLB) and Network Controller.
Key Functions of the SDN Gateway Role
- Site-to-site VPN tunneling
- GRE encapsulation for multi-tenant traffic isolation
- BGP support for dynamic route advertisement
- Overlay-to-underlay traffic translation
- HA deployment model with 2+ gateway VMs
Each SDN Gateway is managed by Network Controller, and configuration is delivered using PowerShell, Windows Admin Center, or REST APIs.
Architecture Notes
- Deployed as VMs or as gateway pools (similar to NSX Edge Clusters)
- Requires dedicated VLANs and IP pools per gateway pool
- NAT, load balancing, and VPN config handled through policy objects
For more information on the Azure SDN GW and Components, please see the below links:
Summary:
Whether you’re deploying NSX or Azure Local SDN, ingress/egress design is critical. Understanding how Tier-0 Gateways and Azure Gateway/SLB components handle external traffic, load balancing, and NAT will guide your SDN architecture strategy.
Each platform has unique strengths:
Azure modularizes roles for flexibility and scalability
NSX centralizes edge functions via Edge VMs
*The thoughts and opinions in this article are mine and hold no reflect on my employer*
Feel free to check in on this series: What is a Virtual Network? In Azure Stack HCI SDN and Azure Cloud you...