TL;DR / Quick Summary
Provides best practices for scalable, secure tenant segmentation
Compares NSX-T multitenancy models (Tier-1, Tier-0, VRFs) to Azure Local SDN constructs
Maps NSX gateway architectures to VNets, subnets, and SDN policies in Azure Local
Highlights benefits, trade-offs, and practical design guidance
Introduction: From NSX-T Complexity to Azure SDN Clarity
Multitenancy is a foundational design principle in enterprise cloud networking. NSX-T enables rich multitenant designs through Tiered Gateways and logical segmentation, but translating this model into a cloud-native SDN like Azure Local can be daunting.
Architects must balance security, operational overhead, and performance isolation while adapting to different native constructs. This post offers a practical migration lens — comparing NSX-T’s architecture to Azure Local SDN, with added insights into scalability, routing, and tenant governance.
Feel free to check in on this series:
NSX-T Multitenancy Models: Foundation
Multiple Tier-1 Gateways per Tenant
Each tenant is assigned one or more Tier-1 gateways connected upstream to a Tier-0, managing localized east-west traffic within the tenant’s domain.
Benefits:
- Strong L3 isolation
- Independent NAT, firewall, and load balancing
- Supports distributed routing for performance
Downsides & Challenges:
- Proliferation of Tier-1s can increase configuration drift
- Requires careful route redistribution to Tier-0
- Troubleshooting inter-tenant flows becomes complex
Best Practices:
- Use naming conventions per tenant (e.g.,
t1-dev,t1-finance) - Automate gateway deployment with NSX-T Policy API
- Restrict shared services behind dedicated firewall zones
Dedicated Tier-0 Gateways per Tenant
In this design, each tenant is given a unique Tier-0 gateway, offering complete segmentation down to routing domain and egress control.
Benefits:
- Complete L3 control per tenant
- Enables distinct BGP sessions and upstream route policies
- Suited for tenants requiring unique edge services (e.g., DDoS, IPS)
Downsides & Challenges:
- Routing table complexity increases at physical layer
- Consumes more NSX edge capacity and control-plane resources
- May require VRF support from physical routers
Best Practices:
- Pair with VRF-aware physical switches for clean upstream handoff
- Use tenant-specific route maps to control learned paths
- Limit Tier-0 sprawl by grouping low-risk tenants when possible
Dedicated VRF Lite Gateway per Tenant
VRF Lite enables multiple routing instances (VRFs) on a single Tier-0. A single edge uplink device can serve multiple tenants with logically isolated control planes.
Benefits:
- Consolidated Tier-0 footprint
- Efficient route summarization
- Supports BGP-based MPLS or service provider designs
Downsides & Challenges:
- VRF policies must be meticulously defined to avoid route leaks
- Not every NSX-T version supports full parity of features across VRFs
- Logging and troubleshooting per VRF can be tricky
Best Practices:
- Use route targets and export/import policies
- Validate with upstream provider to support overlapping IPs
- Tag and monitor traffic per VRF using NSX-T Traceflow or Aria Operations
Azure Local SDN: Multitenant Mapping
Azure Local SDN uses Virtual Networks (VNets), subnets, and intent-based routing policies to recreate similar segmentation. While not 1:1 in structure, a well-designed Azure SDN can achieve secure tenant isolation and flexible routing with less complexity.
Azure Local SDN Virtual Subnet per Tenant
This model uses a shared VNet with a unique subnet allocated per tenant, with custom NSGs and route tables per subnet.
Benefits:
- Easier to manage shared services and inter-tenant flows
- Reduced overhead compared to isolated VNets
- Fast to deploy and extend
Downsides & Challenges:
- Risk of misconfigured NSGs leading to tenant bleed
- Harder to enforce per-tenant bandwidth/QoS
- May hit subnet limitations in large environments
Best Practices:
- Enforce deny-all NSGs by default and allow explicitly
- Use Azure Policy to prevent subnet overlap or excessive permissions
- Tag subnets with tenant ID for automated compliance scanning
Azure Stack SDN Virtual network per Tenant
This design maps to the NSX-T “dedicated Tier-0” model. Each tenant receives a separate VNet with their own IP address space and access controls.
Benefits:
- Full L3 isolation
- Better integration with Azure Firewall, VPN, and ExpressRoute
- Allows for per-tenant route tables, policies, and NAT
Downsides & Challenges:
- Cross-VNet communication requires peering or service endpoints
- Increased ARM object count per subscription
- Adds complexity in shared infrastructure access (e.g. monitoring, identity)
Best Practices:
Automate tenant provisioning via Azure Bicep or Terraform
Use Hub-and-Spoke with NVA or Azure Firewall in the hub
Peer VNets with UseRemoteGateways for shared egress
Best Practices for Multitenancy Design
Hybrid Strategy: Consider ExpressRoute or S2S VPN for hybrid NSX ↔ Azure coexistence
Zero Trust by Default: Use NSGs, policies, and route filtering to deny by default
Declarative Networking: Adopt SDN controllers (e.g., Azure WAC SDN extension) for consistent provisioning
Automation-First: Use IaC tools to avoid drift and manual misconfigurations
Audit Routinely: Monitor route propagation and verify tenant data paths with logs or traffic analyzers
Summary:
This article explores how to translate VMware NSX-T multitenancy architectures—such as Tier-1/Tier-0 gateways and VRF Lite—into Azure Local SDN equivalents using VNets, subnets, and intent-based policies. It breaks down the benefits and challenges of each approach, comparing routing, isolation, and scalability models across platforms. Whether you’re migrating workloads or designing greenfield environments, this guide provides actionable insights, diagrams, and best practices to ensure secure, scalable tenant segmentation in Azure Local SDN.
*The thoughts and opinions in this article are mine and hold no reflect on my employer*