Microsoft Azure — Azure Load Balancer

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure load balancer with production-ready configurations, best practices, and hands-on examples.

Azure Load Balancer: The Stateless Workhorse

Azure Load Balancer (ALB) operates at Layer 4 of the OSI model, distributing TCP/UDP traffic across healthy backend instances. Unlike Application Gateway (Layer 7), ALB is stateless—it doesn't inspect payloads. This makes it ideal for high-throughput, low-latency scenarios like database replicas, DNS servers, or any workload where you need raw packet forwarding. ALB supports both public (inbound internet) and internal (private VNet) load balancing. It uses a five-tuple hash (source IP, source port, destination IP, destination port, protocol) to maintain session affinity when configured with 'Client IP' persistence. Crucially, ALB does not terminate TLS; that's a job for a reverse proxy or Application Gateway. In production, you'll often pair ALB with a TLS terminator behind it. ALB's health probes are configurable: HTTP, HTTPS, or TCP. For TCP, a simple SYN-ACK check suffices; for HTTP, you can probe a specific endpoint like /health. Always set a short probe interval (5s) and low unhealthy threshold (2) to detect failures fast. ALB's backend pools can be VMs, VMSS, or IP addresses (including on-prem via VPN). Standard SKU is mandatory for production—Basic SKU lacks availability zones and SLA.

az network lb create \
  --resource-group prod-rg \
  --name prod-lb \
  --sku Standard \
  --public-ip-address prod-pip \
  --frontend-ip-name frontend \
  --backend-pool-name backend-pool

az network lb probe create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name tcp-probe \
  --protocol Tcp \
  --port 80 \
  --interval 5 \
  --threshold 2

az network lb rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name http-rule \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name frontend \
  --backend-pool-name backend-pool \
  --probe-name tcp-probe

Backend Pools: Choosing the Right Membership Type

Azure Load Balancer supports three backend pool membership types: Virtual Machines, Virtual Machine Scale Sets (VMSS), and IP addresses (including on-premises). For production, VMSS is the recommended approach because it integrates with autoscaling and rolling upgrades. When using VMs, you must manually add/remove them from the backend pool—error-prone during scaling events. IP-based pools allow you to target any IP, including on-prem servers via VPN or ExpressRoute, but you lose automatic health probe integration with Azure VMs. For VMSS, ALB automatically adds new instances and removes terminated ones. However, note that ALB does not wait for connection draining before removing an instance—it stops sending new connections immediately. To avoid dropped connections, configure connection draining (idle timeout) on the load balancing rule. The default idle timeout is 4 minutes; set it to match your application's longest request. When using VMSS with a custom image, ensure the health probe endpoint is responsive before the instance is marked healthy. A common pitfall: the application starts listening on port 80 before it's ready to serve traffic, causing 502 errors. Use a startup script that delays health probe response until the app is fully initialized.

# Add VMSS to backend pool
az network lb address-pool create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name backend-pool

az network lb address-pool vmss add \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name backend-pool \
  --vmss-name prod-vmss \
  --backend-addresses '[{"ipAddress":"10.0.1.4"},{"ipAddress":"10.0.1.5"}]'

# For IP-based pool (on-prem)
az network lb address-pool address add \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --pool-name backend-pool \
  --name onprem-1 \
  --ip-address 192.168.1.10 \
  --subnet /subscriptions/.../subnets/onprem-subnet

Health Probes: The Canary in the Coal Mine

Health probes are ALB's mechanism to determine backend instance health. Three protocols: TCP, HTTP, HTTPS. TCP probe checks if the port is listening—fast but shallow. HTTP/HTTPS probes check a specific endpoint (e.g., /health) and expect a 200 OK. Always prefer HTTP probes for application-level health. Design your /health endpoint to verify dependencies: database connectivity, cache, disk space. A common mistake is a health endpoint that returns 200 even when the app is broken (e.g., stuck in a deadlock). Implement a liveness check that fails fast. Probe configuration: interval (default 15s), unhealthy threshold (default 2), healthy threshold (default 2). For production, set interval to 5s, unhealthy threshold to 2, healthy threshold to 1. This gives ~10s detection of failure. Be careful with probe port—it must match the backend port unless you use a separate health port. ALB probes originate from Azure's infrastructure IP range (168.63.129.16). Ensure your NSG allows inbound traffic from this IP on the probe port. If you block it, all instances will be marked unhealthy. Also, probes are sent from all Azure regions where the LB is deployed; for cross-region, you need to allow broader ranges.

from flask import Flask, jsonify
import psycopg2
import os

app = Flask(__name__)

def check_db():
    try:
        conn = psycopg2.connect(
            host=os.getenv('DB_HOST'),
            port=5432,
            dbname=os.getenv('DB_NAME'),
            user=os.getenv('DB_USER'),
            password=os.getenv('DB_PASS'),
            connect_timeout=2
        )
        conn.close()
        return True
    except Exception:
        return False

@app.route('/health')
def health():
    if not check_db():
        return jsonify({"status": "unhealthy", "reason": "database down"}), 503
    return jsonify({"status": "healthy"}), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Load Balancing Rules and Session Persistence

Load balancing rules define how traffic is distributed. Each rule binds a frontend IP:port to a backend pool:port. You can have multiple rules for different protocols (e.g., TCP 80, TCP 443). Session persistence (affinity) is optional: None, Client IP, or Client IP and Protocol. For stateless apps, use None. For stateful apps (e.g., shopping cart), use Client IP. However, Client IP persistence can cause uneven distribution if many users share the same IP (NAT). For better distribution, use Client IP and Protocol, which adds the protocol to the hash. ALB uses a five-tuple hash by default; session persistence modifies the hash to include only the specified fields. Important: session persistence is not sticky sessions in the traditional sense—it's based on the hash, not a cookie. If a backend goes down, the hash is recalculated, and traffic may go to a different backend. For true sticky sessions, use Application Gateway with cookie-based affinity. Also, note that session persistence is per rule, not per backend. If you have multiple rules, each can have its own persistence setting. In production, avoid session persistence for high-availability; design your app to be stateless or use a distributed cache (Redis) for session state.

az network lb rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name http-rule \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name frontend \
  --backend-pool-name backend-pool \
  --probe-name http-probe \
  --idle-timeout 4 \
  --enable-tcp-reset true \
  --load-distribution SourceIPProtocol

Outbound Rules: SNAT and Source NAT

Azure Load Balancer provides outbound connectivity for backend instances via Source Network Address Translation (SNAT). When a VM in the backend pool initiates outbound traffic, ALB translates the source IP to the frontend public IP. This is critical for VMs that need to reach the internet (e.g., for updates, external APIs). Outbound rules are configured on the load balancer. You define which frontend IP to use, which backend pool, and the port allocation strategy. The default SNAT port allocation is 1024 ports per VM, but you can adjust with 'Manual' or 'Use Default'. For production, use 'Manual' and allocate based on expected concurrent connections. A common failure: SNAT port exhaustion. Each outbound connection consumes a port; when all ports are used, new connections fail. Symptoms: intermittent connectivity, timeouts. To mitigate, use multiple frontend IPs (up to 16) to increase port pool. Also, consider using Azure NAT Gateway for larger scale—it provides 64,512 ports per IP and scales better. Outbound rules are only available on Standard SKU. Basic SKU uses default outbound access (no control). Always configure explicit outbound rules to avoid relying on default behavior, which can change.

# Create outbound rule
az network lb outbound-rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name outbound-rule \
  --frontend-ip-configs frontend \
  --backend-pool-name backend-pool \
  --protocol All \
  --idle-timeout 4 \
  --outbound-ports 10000

# Add additional frontend IP for more SNAT ports
az network lb frontend-ip create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name frontend2 \
  --public-ip-address prod-pip2

az network lb outbound-rule update \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name outbound-rule \
  --frontend-ip-configs frontend frontend2

High Availability: Availability Zones and Cross-Region

Standard SKU ALB supports availability zones. You can deploy a zone-redundant frontend (spans all zones) or zonal (pinned to one zone). Zone-redundant is recommended for production—it survives a zone outage. Backend VMs should also be distributed across zones. For cross-region load balancing, Azure offers Cross-Region Load Balancer (preview). It distributes traffic across regional ALBs using a global frontend IP. This is useful for active-passive or active-active multi-region deployments. Cross-region LB uses a health probe on the regional LB's frontend. If a region fails, traffic is redirected to the next healthy region. However, cross-region LB does not support session persistence—each request may go to a different region. For stateful apps, use Traffic Manager or Front Door instead. In production, always deploy ALB in a zone-redundant configuration. Also, ensure backend VMs are in the same zones as the frontend to avoid cross-zone latency. For critical workloads, combine ALB with Azure Front Door for global load balancing and DDoS protection.

# Create zone-redundant public IP
az network public-ip create \
  --resource-group prod-rg \
  --name prod-pip \
  --sku Standard \
  --zone 1 2 3

# Create zone-redundant frontend
az network lb frontend-ip create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name frontend \
  --public-ip-address prod-pip \
  --zone 1 2 3

# Create backend VMs in each zone
for zone in 1 2 3; do
  az vm create \
    --resource-group prod-rg \
    --name vm-zone-$zone \
    --zone $zone \
    --vnet-name prod-vnet \
    --subnet backend-subnet \
    --image UbuntuLTS \
    --admin-username azureuser \
    --generate-ssh-keys
done

Monitoring and Diagnostics: Logs, Metrics, Alerts

Azure Load Balancer integrates with Azure Monitor for metrics and logs. Key metrics: Packet Count, Byte Count, SNAT Connection Count, Health Probe Status, Data Path Availability. Set alerts on Health Probe Status (if backend count drops below threshold) and SNAT Connection Count (if >80% utilized). For deep diagnostics, enable NSG flow logs and LB logs. LB logs include load balancer rule events and health probe events. However, LB logs are verbose; enable only for troubleshooting. Use Azure Monitor Workbooks to create dashboards. A common issue: data path availability metric shows 0 when the LB frontend is unreachable (e.g., NSG blocking). Always monitor this metric. For proactive monitoring, set up action groups to notify on alert triggers. Also, use Azure Resource Health to check LB health. In production, we recommend a minimum of 90% data path availability alert. For SNAT, set a warning at 70% and critical at 90%. Additionally, log backend instance health changes to detect flapping instances (rapidly toggling healthy/unhealthy). Flapping can indicate misconfigured health probes or application instability.

# Create metric alert for health probe status
az monitor metrics alert create \
  --resource-group prod-rg \
  --name "HealthProbeAlert" \
  --scopes /subscriptions/.../loadBalancers/prod-lb \
  --condition "avg HealthProbeStatus < 1" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-groups /subscriptions/.../actionGroups/prod-ag

# Create alert for SNAT port usage
az monitor metrics alert create \
  --resource-group prod-rg \
  --name "SNATAlert" \
  --scopes /subscriptions/.../loadBalancers/prod-lb \
  --condition "avg SnatConnectionCount > 8000" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-groups /subscriptions/.../actionGroups/prod-ag

Troubleshooting Common Failures

Even with proper configuration, things go wrong. Here are common failure modes and how to diagnose them. 1) Backend marked unhealthy: Check NSG rules—ensure 168.63.129.16 is allowed on probe port. Verify the health endpoint returns 200. Use az network lb probe show to see probe status. 2) No traffic to backend: Check load balancing rule mapping. Verify backend pool has instances. Use az network lb list-backend-address-pool to list addresses. 3) Intermittent timeouts: Likely SNAT port exhaustion. Check SnatConnectionCount metric. Increase frontend IPs or reduce idle timeout. 4) Connection resets: TCP reset enabled? If idle timeout is too low, connections may be reset prematurely. Increase idle timeout or disable TCP reset if not needed. 5) Uneven traffic distribution: Session persistence causing imbalance. Check load distribution setting. Use SourceIPProtocol for better distribution. 6) Cross-region issues: Ensure regional LBs are healthy. Cross-region LB uses health probes on regional frontends. If a regional LB is down, traffic fails over. Test failover by stopping a regional LB. Always have a troubleshooting runbook with these steps. Use Azure Network Watcher's IP flow verify to test connectivity. Also, enable diagnostic logs for the LB to capture rule hits.

# Check health probe status
az network lb probe show \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name http-probe \
  --query "loadBalancingRules[].{name:name, provisioningState:provisioningState}"

# List backend pool addresses
az network lb address-pool list \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name backend-pool \
  --query "loadBalancerBackendAddresses[].ipAddress"

# Verify NSG allows probe
az network nsg rule list \
  --resource-group prod-rg \
  --nsg-name backend-nsg \
  --query "[?destinationPortRange=='80']"

# Check SNAT metrics
az monitor metrics list \
  --resource /subscriptions/.../loadBalancers/prod-lb \
  --metric SnatConnectionCount \
  --interval PT1H \
  --output table

Production Deployment with Infrastructure as Code

Manual creation of ALB is error-prone. Use Infrastructure as Code (IaC) with Terraform or ARM/Bicep. Below is a Terraform example for a production-grade ALB with zone redundancy, health probes, and outbound rules. Key practices: parameterize everything, use remote state, and implement CI/CD pipelines. In the Terraform config, note the use of for_each to create multiple frontend IPs for SNAT. Also, the health probe depends on the backend pool. Always set depends_on explicitly to avoid race conditions. For production, use modules to encapsulate LB configuration. Test changes in a staging environment first. Use Terraform workspaces for environment separation. Also, enable prevent_destroy on critical resources like the LB itself. For secrets (e.g., health endpoint passwords), use Azure Key Vault. Finally, integrate with Azure Policy to enforce SKU Standard and zone-redundancy. This ensures compliance across all subscriptions.

resource "azurerm_lb" "prod" {
  name                = "prod-lb"
  location            = azurerm_resource_group.prod.location
  resource_group_name = azurerm_resource_group.prod.name
  sku                 = "Standard"
}

resource "azurerm_lb_frontend_ip_configuration" "frontend" {
  name                 = "frontend"
  loadbalancer_id      = azurerm_lb.prod.id
  public_ip_address_id = azurerm_public_ip.prod.id
  zones                = ["1", "2", "3"]
}

resource "azurerm_lb_backend_address_pool" "backend" {
  loadbalancer_id = azurerm_lb.prod.id
  name            = "backend-pool"
}

resource "azurerm_lb_probe" "http" {
  loadbalancer_id = azurerm_lb.prod.id
  name            = "http-probe"
  protocol        = "Http"
  port            = 80
  request_path    = "/health"
  interval_in_seconds = 5
  number_of_probes     = 2
}

resource "azurerm_lb_rule" "http" {
  loadbalancer_id                = azurerm_lb.prod.id
  name                           = "http-rule"
  protocol                       = "Tcp"
  frontend_port                  = 80
  backend_port                   = 80
  frontend_ip_configuration_name = azurerm_lb_frontend_ip_configuration.frontend.name
  backend_address_pool_ids       = [azurerm_lb_backend_address_pool.backend.id]
  probe_id                       = azurerm_lb_probe.http.id
  idle_timeout_in_minutes        = 4
  enable_tcp_reset               = true
}

resource "azurerm_lb_outbound_rule" "outbound" {
  loadbalancer_id = azurerm_lb.prod.id
  name            = "outbound-rule"
  protocol        = "All"
  allocated_outbound_ports = 10000
  frontend_ip_configurations {
    name = azurerm_lb_frontend_ip_configuration.frontend.name
  }
  backend_address_pool_id = azurerm_lb_backend_address_pool.backend.id
}

Security: NSGs, DDoS, and Private Endpoints

Azure Load Balancer itself is not a security appliance—it's a traffic distributor. Security must be implemented at the network and application layers. First, Network Security Groups (NSGs) on backend subnets: allow only traffic from the LB frontend IP (or VNet) and health probe source IP (168.63.129.16). Deny all other inbound. For public ALB, enable Azure DDoS Protection Standard on the VNet. This protects against volumetric attacks. ALB does not have built-in WAF; use Azure Application Gateway or Front Door for Layer 7 filtering. For internal ALB, use Private Endpoints to expose services privately. ALB can be placed behind a firewall (e.g., Azure Firewall) for traffic inspection. However, this adds latency. For compliance, enable diagnostic logs and send to Log Analytics. Use Azure Policy to enforce that ALBs are Standard SKU and have NSGs attached. Also, restrict outbound traffic from backend VMs using NSGs or Azure Firewall. Never allow unrestricted outbound. Finally, use Managed Identities for VMs to access Azure resources securely, avoiding connection strings in code.

# Allow LB health probe
az network nsg rule create \
  --resource-group prod-rg \
  --nsg-name backend-nsg \
  --name AllowLBProbe \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 168.63.129.16 \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80

# Allow traffic from LB frontend
az network nsg rule create \
  --resource-group prod-rg \
  --nsg-name backend-nsg \
  --name AllowLBTraffic \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.0.0.4/32 \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80

# Deny all other inbound
az network nsg rule create \
  --resource-group prod-rg \
  --nsg-name backend-nsg \
  --name DenyAllInbound \
  --priority 4096 \
  --direction Inbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'

Cost Optimization and Performance Tuning

Azure Load Balancer pricing is based on rules and data processed. Standard SKU has a fixed hourly cost plus per-GB data processing. To optimize: consolidate rules—each rule adds cost. Use a single rule for multiple ports if possible (e.g., TCP 80-443). For outbound, use NAT Gateway instead of LB outbound rules for better port scalability and lower cost at high volumes. NAT Gateway costs ~$0.045/hour plus data processing, but provides 64,512 ports per IP. For performance, ALB can handle millions of flows. However, ensure backend VMs are sized appropriately. Use accelerated networking on VMs for higher throughput. Also, enable TCP segmentation offload (TSO) on the OS. Monitor latency metrics: ALB adds <1ms latency. If you see higher, check backend response times. For global performance, use cross-region LB or Front Door. In production, right-size your backend pool: too few instances cause overload; too many waste cost. Use autoscaling based on CPU or request count. Finally, consider reserved instances for predictable workloads to save up to 72% on VM costs.

# Estimate monthly cost
az consumption prices list \
  --query "[?contains(productName, 'Load Balancer')].{name: productName, price: unitPrice}" \
  --output table

# Example: Standard LB with 1 rule, 10GB data
# Hourly: $0.025/hr * 730 = $18.25
# Data: $0.008/GB * 10 = $0.08
# Total: ~$18.33/month

# Compare with NAT Gateway
# Hourly: $0.045/hr * 730 = $32.85
# Data: $0.045/GB * 10 = $0.45
# Total: ~$33.30/month

Migration from Basic to Standard SKU

If you're still on Basic SKU, migrate to Standard. Basic SKU is being deprecated and lacks features. Migration steps: 1) Create a new Standard SKU ALB in the same region. 2) Configure frontend IP, backend pool, probes, and rules matching the Basic LB. 3) Update DNS to point to the new LB's public IP. 4) Gradually shift traffic by updating application configurations. 5) Delete the old Basic LB. Important: Standard SKU requires explicit outbound rules; Basic had default outbound. Ensure you configure outbound rules before cutting over. Also, Standard SKU has different NSG requirements—it doesn't allow inbound traffic from the internet unless explicitly allowed. Test in a staging environment first. Use Azure Traffic Manager to perform a blue-green migration. During migration, monitor metrics to ensure no impact. Rollback plan: keep the Basic LB running until traffic is fully migrated. Note that Basic LB does not support availability zones, so if you need HA, you must redeploy backends across zones.

# Create Standard LB
az network lb create --resource-group prod-rg --name prod-lb-std --sku Standard --public-ip-address prod-pip-std

# Copy configuration from Basic LB
az network lb rule list --resource-group prod-rg --lb-name prod-lb-basic --query "[].{name:name, protocol:protocol, frontendPort:frontendPort, backendPort:backendPort}" -o json > rules.json

# Apply rules to Standard LB
for rule in $(cat rules.json | jq -c '.[]'); do
  name=$(echo $rule | jq -r '.name')
  protocol=$(echo $rule | jq -r '.protocol')
  frontendPort=$(echo $rule | jq -r '.frontendPort')
  backendPort=$(echo $rule | jq -r '.backendPort')
  az network lb rule create --resource-group prod-rg --lb-name prod-lb-std --name $name --protocol $protocol --frontend-port $frontendPort --backend-port $backendPort --frontend-ip-name frontend --backend-pool-name backend-pool --probe-name http-probe
done

# Update DNS
az network dns record-set a update --resource-group dns-rg --zone-name example.com --name www --set targetResource.id=/subscriptions/.../publicIPAddresses/prod-pip-std

Gateway Load Balancer: Transparent NVA Insertion

Gateway Load Balancer (GWLB) is a specialized SKU of Azure Load Balancer designed for transparent insertion of Network Virtual Appliances (NVAs) into the traffic path. Unlike Standard LB which distributes traffic to backends, GWLB sits between the client and the NVA, forwarding traffic using Geneve tunneling. This enables scenarios like firewall inspection, IDS/IPS, and packet inspection — without complex UDR configurations. GWLB maintains flow stickiness and flow symmetry automatically, eliminating the asymmetric routing issues common with traditional NVA deployments. In production, chain a Gateway Load Balancer to a Standard Public Load Balancer: the public LB receives client traffic and forwards it to the GWLB, which distributes it across NVAs. This provides HA at both the application and NVA layers. Key benefits: no UDRs needed, automatic flow symmetry, and easy NVA scaling (add/remove NVAs without changing routes). GWLB supports up to 100 Gbps throughput. Use it for north-south traffic scenarios with partner NVAs like Palo Alto, Check Point, or Fortinet. Separate trusted and untrusted traffic using different tunnel interfaces (external vs internal). Ensure NVAs have MTU at least 1550 (up to 4000 for jumbo frames) to accommodate VXLAN headers.

#!/bin/bash
# Create Gateway Load Balancer
az network lb create \
  --resource-group prod-rg \
  --name prod-gwlb \
  --sku Gateway \
  --location eastus \
  --frontend-ip-name frontend \
  --backend-pool-name nva-pool \
  --subnet /subscriptions/.../subnets/gwlb-subnet

# Add NVAs to backend pool
az network lb address-pool address add \
  --resource-group prod-rg \
  --lb-name prod-gwlb \
  --pool-name nva-pool \
  --name nva-1 \
  --ip-address 10.0.4.4

az network lb address-pool address add \
  --resource-group prod-rg \
  --lb-name prod-gwlb \
  --pool-name nva-pool \
  --name nva-2 \
  --ip-address 10.0.4.5

# Chain with Standard Public LB
az network lb frontend-ip update \
  --resource-group prod-rg \
  --lb-name prod-public-lb \
  --name frontend \
  --gateway-lb /subscriptions/.../loadBalancers/prod-gwlb \
  --gateway-lb-frontend-ip-name frontend

NAT Gateway vs Load Balancer Outbound: Choosing the Right Strategy

Azure provides multiple methods for outbound connectivity, and selecting the right one is critical for production workloads. NAT Gateway is the recommended option: it provides up to 64,512 SNAT ports per IP (vs. 64,000 shared across all backends for LB outbound rules), scales to 100 Gbps, and is zone-redundant. NAT Gateway also takes precedence over all other outbound methods when associated with a subnet. Load Balancer outbound rules are still viable for scenarios where you need both inbound and outbound through the same public IP, but they require manual port allocation to avoid SNAT exhaustion — the default allocation is conservative and insufficient for production. Instance-level public IPs (direct IP on the NIC) are simple but don't scale and add management overhead. Default outbound access retired September 2025 and should never be used. In production, use NAT Gateway for most outbound scenarios, especially when: high SNAT port count needed (>64K), multiple VMs share the same subnet, or you need flow logs (StandardV2). Use LB outbound rules when you must share the same public IP for inbound and outbound. Combine both: NAT Gateway for outbound, LB for inbound. The hierarchy is: NAT Gateway > instance-level PIP > LB outbound rules > default outbound access. Monitor SNAT port utilization with Azure Monitor and set alerts at 70% utilization.

#!/bin/bash
# Method 1: NAT Gateway (recommended)
az network nat gateway create --resource-group prod-rg --name prod-natgw --sku Standard
az network vnet subnet update --resource-group prod-rg --vnet-name prod-vnet --name web-subnet --nat-gateway prod-natgw

# Method 2: LB outbound rules (when sharing IP with inbound)
az network lb outbound-rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name outbound-rule \
  --frontend-ip-configs frontend \
  --backend-pool-name backend-pool \
  --protocol All \
  --outbound-ports 10000  # Manual allocation

# Monitor SNAT usage
az monitor metrics list \
  --resource /subscriptions/.../natGateways/prod-natgw \
  --metric SNATConnectionCount \
  --interval PT1H

az monitor metrics list \
  --resource /subscriptions/.../loadBalancers/prod-lb \
  --metric SnatConnectionCount \
  --interval PT1H

Inbound NAT Rules: Direct VM Access Management

Inbound NAT rules in Azure Load Balancer allow you to map a specific frontend port to a specific backend VM and port. This is commonly used for RDP/SSH access to individual VMs without exposing them directly to the internet — traffic goes through the LB's public IP and is forwarded to the VM. Inbound NAT rules are defined per rule (one frontend port maps to one backend:port). You can also use inbound NAT pools for VMSS — each VM in the scale set gets a unique port mapping automatically. In production, inbound NAT rules are ideal for management access: instead of assigning public IPs to each VM (insecure), you create NAT rules on the LB. For example, map port 50001 to VM-1:22, port 50002 to VM-2:22, etc. Use Azure Bastion as a more secure alternative for management access — it provides RDP/SSH through the browser without any public IP exposure. Inbound NAT rules have limitations: each rule consumes 8 SNAT ports from the frontend IP's available pool, reducing capacity for outbound connections. For large fleets, use a bastion host or Azure Bastion instead of hundreds of NAT rules. Combine inbound NAT rules with NSGs to restrict source IPs (e.g., only allow your corporate VPN IP range).

#!/bin/bash
# Create inbound NAT rule for SSH access to a specific VM
az network lb inbound-nat-rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name ssh-web-vm \
  --protocol Tcp \
  --frontend-port 50001 \
  --backend-port 22 \
  --frontend-ip-name frontend

# Associate with VM's NIC
az network nic ip-config inbound-nat-rule add \
  --resource-group prod-rg \
  --nic-name web-vm-nic \
  --ip-config-name ipconfig1 \
  --inbound-nat-rule ssh-web-vm

# Create inbound NAT pool for VMSS
az network lb inbound-nat-pool create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name ssh-pool \
  --protocol Tcp \
  --frontend-port-range-start 50000 \
  --frontend-port-range-end 50100 \
  --backend-port 22

# Connect to VM via NAT rule
ssh -p 50001 azureuser@20.185.0.1