Introduction
As hybrid cloud continues to dominate IT strategy, many enterprises are turning to Microsoft Azure Local SDN (formerly Azure Stack HCI) to extend cloud-native networking into their datacenters. One key capability is Layer 4 load balancing, delivered via Software Load Balancer (SLB) services. But not all SLBs are created equal—understanding the distinction between Internal and External SLBs is vital for proper network design.
This blog post dives into how Azure Local SDN handles Layer 4 load balancing, highlights the key differences between Internal and External SLB configurations, and outlines when to use each. If you’re designing tenant-isolated services, scaling internal applications, or publishing workloads to the internet, this article is for you.
TL;DR – Quick Summary
| Feature | Internal SLB | External SLB |
|---|---|---|
| Visibility | Private IP only | Public IP + NAT |
| Use Case | East-West traffic | North-South traffic |
| Listener Type | Internal endpoints | Internet-facing endpoints |
| NSG Integration | Required | Required |
| Common Apps | Microservices, SQL, App Tiers | Web apps, VPN gateways, public APIs |
Azure Local SLB enables highly available, software-defined load balancing for both internal and internet-facing workloads—directly within your datacenter.
What is Layer 4 Load Balancing?
Layer 4 (Transport Layer) load balancing distributes TCP/UDP traffic based on IP address and port information. In Azure Local SDN, the SLB component handles this distribution dynamically, offering high throughput and minimal latency.
Azure Local’s SLB is:
- Fully integrated with Network Controller
- Configurable via SDN Express, PowerShell, or Windows Admin Center
- Compatible with Network Security Groups (NSGs)
- Highly scalable, with support for HA and NAT
Azure Local SDN SLB Architecture Overview
Microsoft’s Azure Local SDN platform abstracts network functions and allows centralized policy control. SLB is deployed as a virtualized network function (VNF), embedded in the SDN stack.
Key Components:
- Software Load Balancer (SLB):
- Distributes incoming TCP/UDP traffic
- Applies rules defined at the network controller level
- MUX (Multiplexer):
- Serves as the entry point for external (North-South) traffic
- Handles Public IP bindings for External SLBs
- Virtual Network:
- Provides logical subnet isolation
- Enables tenant-aware segmentation within SDN fabrics
- Distributed Router (DR):
- Performs internal East-West routing
- Manages gateway flows and static routes for VMs
Internal SLB: Use Cases and Configuration
What It Does
Internal SLBs are designed to handle East-West traffic between workloads inside the same Virtual Network (VNet).
Common Use Cases
- Load balancing traffic between App Service tiers
- Directing requests between SQL AlwaysOn nodes
- Supporting multi-tier application architectures
How to Deploy
- Create Internal Frontend IP (private)
- Define backend pool with target VMs
- Configure Health Probes (TCP/HTTP)
- Set up load balancing rules (L4 TCP/UDP)
Advantages
- No external exposure
- Simplifies microservices discovery
- Supports HA without Public IPs
External SLB: Use Cases and Configuration
What It Does
External SLBs enable North-South traffic, allowing workloads to be published to external clients.
Common Use Cases
- Publishing web applications
- Hosting VPN gateways
- Internet-facing APIs or portals
How to Deploy
- Assign Public IP to MUX via Virtual IP (VIP)
- Define NAT rules or LB rules for traffic redirection
- Bind to a backend pool and probe configuration
Advantages
- Public accessibility with secure NAT
- Centralized traffic control
- Firewall/NAT can coexist with NSGs
Internal vs External SLB: Comparison Table
| Feature | Internal SLB | External SLB |
| Traffic Type | East-West | North-South |
| IP Exposure | Private | Public |
| Use Case | Internal service communication | External client access |
| Protocol Support | TCP, UDP | TCP, UDP |
| Load Balancing Rules | Private VIP | NAT + Public VIP |
| Integration | VNet-only | Internet via MUX |
Best Practices for Layer 4 Load Balancing in Azure Local
- Use NSGs with SLB Rules: Always control flow with Network Security Groups
- Implement Health Probes: Define realistic probes to avoid false health detections
- Scale Out Backends: Add backend members as stateless workloads grow
- Monitor via WAC: Use Windows Admin Center for SLB health and config
- Document Public IP Usage: Avoid conflicts across tenants and networks
- Secure NAT Rules: Explicitly limit source/destination in external SLB
- Avoid Overlapping Ports: Internal and External rules must be isolated
- Tag Resources: Clearly label SLB-related resources per tenant or zone
Real-World Scenario: Azure Local SLB in Action
A regional healthcare provider deployed Azure Local SDN to improve failover and load balancing for their EMR web frontend. By leveraging External SLB with NAT rules and NSG tagging, they achieved seamless internet access without compromising patient data zones. Their internal App and DB tiers ran under Internal SLB policies.
Source: Microsoft Customer Case Studies – Azure Stack HCI in Healthcare
Common Misconfigurations to Avoid
- Binding internal SLB to a public IP (unsupported)
- Omitting health probes (causes false drop)
- Unsecured NAT rules for External SLB
- Using overlapping frontend ports in same VNet
Final Thoughts
Azure Local SDN delivers a powerful and scalable Layer 4 load balancing framework that can handle both internal microservice traffic and public application exposure. By understanding the right use cases for Internal vs External SLB, IT architects can optimize performance, security, and scalability within hybrid environments.
Whether you’re building tenant-aware services, publishing remote access endpoints, or scaling internal databases, Azure Local SLB is a powerful ally in your SDN toolkit.