πŸ”’ Guided

Pre-launch preview. Authorised access only.

Incorrect code

Guided by A Guide to Cloud
Explore AB-900 AI-901
Guided AZ-700 Domain 3
Domain 3 β€” Module 1 of 5 20%
14 of 26 overall

AZ-700 Study Guide

Domain 1: Core Networking Infrastructure

  • Virtual Networks: Your Cloud Foundation Free
  • IP Addressing: Public, Private & Prefixes Free
  • Name Resolution: Azure DNS Free
  • Routing: UDRs, Route Server & NAT Gateway Free
  • VNet Peering and Connectivity
  • Network Monitoring and Diagnostics
  • DDoS Protection and Security Posture

Domain 2: Connectivity Services

  • Site-to-Site VPN: Connecting On-Premises
  • Point-to-Site VPN: Remote Access
  • ExpressRoute Fundamentals
  • ExpressRoute: Advanced Features
  • Azure Virtual WAN
  • Choosing Your Hybrid Connection

Domain 3: Application Delivery Services

  • Azure Load Balancer: Layer 4
  • Traffic Manager: DNS-Based Routing
  • Application Gateway: Layer 7
  • Azure Front Door: Global Delivery
  • Choosing the Right Load Balancer

Domain 4: Private Access to Azure Services

  • Private Link and Private Endpoints
  • Private Endpoint DNS
  • Service Endpoints: When and How

Domain 5: Network Security Services

  • NSGs and Application Security Groups
  • Flow Logs, IP Flow Verify & Network Manager Security
  • Azure Firewall: SKUs and Deployment
  • Azure Firewall Manager and Policies
  • Web Application Firewall (WAF)

AZ-700 Study Guide

Domain 1: Core Networking Infrastructure

  • Virtual Networks: Your Cloud Foundation Free
  • IP Addressing: Public, Private & Prefixes Free
  • Name Resolution: Azure DNS Free
  • Routing: UDRs, Route Server & NAT Gateway Free
  • VNet Peering and Connectivity
  • Network Monitoring and Diagnostics
  • DDoS Protection and Security Posture

Domain 2: Connectivity Services

  • Site-to-Site VPN: Connecting On-Premises
  • Point-to-Site VPN: Remote Access
  • ExpressRoute Fundamentals
  • ExpressRoute: Advanced Features
  • Azure Virtual WAN
  • Choosing Your Hybrid Connection

Domain 3: Application Delivery Services

  • Azure Load Balancer: Layer 4
  • Traffic Manager: DNS-Based Routing
  • Application Gateway: Layer 7
  • Azure Front Door: Global Delivery
  • Choosing the Right Load Balancer

Domain 4: Private Access to Azure Services

  • Private Link and Private Endpoints
  • Private Endpoint DNS
  • Service Endpoints: When and How

Domain 5: Network Security Services

  • NSGs and Application Security Groups
  • Flow Logs, IP Flow Verify & Network Manager Security
  • Azure Firewall: SKUs and Deployment
  • Azure Firewall Manager and Policies
  • Web Application Firewall (WAF)
Domain 3: Application Delivery Services Premium ⏱ ~14 min read

Azure Load Balancer: Layer 4

Master Azure Load Balancer β€” SKU comparison, public vs internal, components, SNAT port exhaustion, cross-region load balancing, and Gateway Load Balancer.

Azure Load Balancer: Layer 4

Azure Load Balancer distributes traffic at Layer 4 (TCP/UDP). It doesn’t inspect HTTP headers or URLs β€” it routes packets based on IP address, port, and protocol. Fast, efficient, and the foundation of Azure’s load balancing story.

🎬 Video coming soon

Azure Load Balancer Deep Dive

Azure Load Balancer Deep Dive

~14:00
β˜• Simple explanation

A load balancer is a traffic cop at a busy intersection β€” it directs incoming traffic to different servers so no single server gets overwhelmed. Azure Load Balancer works at Layer 4 (TCP/UDP) β€” it distributes based on IP addresses and ports, not URLs. It doesn’t inspect content β€” it just routes packets to healthy backends.

Azure Load Balancer is a Layer 4 load-balancing service providing inbound distribution, outbound connectivity (SNAT), health probing, port forwarding (inbound NAT), and high-availability ports. Standard SKU is zone-redundant, secure by default, and supports outbound rules and HA ports.

Load Balancer SKUs

Azure Load Balancer SKU Comparison
FeatureBasic (Retiring)StandardGateway
Backend pool size300 instances1,000 instances1,000 instances
Health probesTCP, HTTPTCP, HTTP, HTTPSTCP, HTTP, HTTPS
Availability zonesNot supportedZone-redundant and zonalZone-redundant
HA PortsNoYes (all ports on internal LB)Yes (transparent)
Outbound rulesNo (default SNAT only)Yes (configurable SNAT)N/A
SLANo SLA99.99%99.99%
SecurityOpen by defaultSecure by default (NSG required)Secure by default
StatusRetiring 30 Sept 2025Current β€” use thisSpecialised (NVA chaining)
CostFreePer rule + per GBPer rule + per GB

Exam Tip: Basic LB is retiring on 30 September 2025 (same date as Basic public IPs β€” they’re linked). Always choose Standard for new deployments. Standard LB requires Standard SKU public IPs and is secure by default (inbound traffic blocked until an NSG allows it).

Public vs Internal Load Balancer

TypeFrontend IPUse Case
PublicPublic IP addressInternet-facing workloads (web servers, APIs)
InternalPrivate IP from your subnetInternal workloads (app tiers, databases, internal APIs)

You can have both on the same set of backend VMs β€” a public LB for internet traffic and an internal LB for backend-tier traffic.

The 6 Components

  1. Frontend IP configuration β€” the IP clients connect to (public or private)
  2. Backend pool β€” the VMs or instances that receive traffic
  3. Health probes β€” check if backend instances are healthy
  4. Load balancing rules β€” map frontend IP:port to backend pool (uses 5-tuple hash: source IP, source port, destination IP, destination port, protocol)
  5. Inbound NAT rules β€” port forward specific frontend ports to specific backend instances (e.g., frontend port 50001 to VM1 port 3389)
  6. Outbound rules β€” control SNAT for outbound internet traffic from backend pool members

Distribution modes:

ModeHashBehaviour
Default (5-tuple)Source IP + port + Dest IP + port + ProtocolDifferent connections may go to different backends
Source IP affinity (2-tuple)Source IP + Dest IPSame client IP always goes to same backend
Source IP affinity (3-tuple)Source IP + Dest IP + ProtocolSame client and protocol always goes to same backend
ℹ️ SNAT Port Exhaustion β€” A Common Production Issue

When backend VMs use the load balancer for outbound internet traffic (no public IP, no NAT Gateway), they share SNAT ports from the frontend IP.

The problem: Each frontend IP provides approximately 64,000 SNAT ports. With many VMs making outbound connections (e.g., calling external APIs), ports can be exhausted. Symptoms: intermittent connection failures, timeouts, β€œcannot allocate port” errors.

Solutions (in order of preference):

  1. NAT Gateway β€” best practice. Provides 64,000 ports per IP per destination. Scales with multiple IPs.
  2. Outbound rules β€” explicitly allocate SNAT ports per backend instance. Provides more predictable allocation.
  3. Multiple frontend IPs β€” more frontends = more SNAT ports (64,000 per IP).
  4. Public IP on VMs β€” each VM gets its own 64,000 ports. Doesn’t scale well.

Monitoring: Track the β€œSNAT Connection Count” metric. Alert when approaching limits.

The exam tests that you know NAT Gateway is the recommended solution for SNAT port exhaustion.

Cross-Region Load Balancer

Cross-region LB (global tier) distributes traffic across regional Standard LBs in different Azure regions:

Client (anywhere)
    ↓
Cross-Region LB (Global anycast IP)
    β”œβ”€β”€β†’ Standard LB (Australia East)
    β”‚        └──→ Backend VMs
    └──→ Standard LB (West Europe)
             └──→ Backend VMs

Key features:

  • Anycast IP β€” single IP address that routes to the nearest healthy region
  • Geographic proximity β€” clients connect to the closest regional LB
  • Instant failover β€” if a regional LB becomes unhealthy, traffic shifts to the next closest
  • Layer 4 only β€” still TCP/UDP, not HTTP-aware

Use cross-region LB when you need global Layer 4 distribution with automatic regional failover. For HTTP-aware global distribution, use Azure Front Door instead.

Gateway Load Balancer

Gateway LB enables transparent NVA chaining β€” inserting network virtual appliances (firewalls, packet inspection, DDoS appliances) into the traffic path without changing the application architecture.

How it works:

  1. Gateway LB sits in front of NVAs in a separate VNet
  2. Your Standard LB’s frontend configuration is β€œchained” to the Gateway LB
  3. Traffic flows: Client β†’ Standard LB β†’ Gateway LB β†’ NVA β†’ Gateway LB β†’ Backend VMs
  4. The application and clients see no change β€” it’s transparent

Use case: A third-party security vendor provides a firewall appliance. Instead of re-architecting your application, you chain the Gateway LB to inject the NVA into the existing traffic flow.

Key Takeaways

  • Standard LB is the only production choice (Basic retiring, Gateway is specialised)
  • Standard LB is secure by default β€” NSG required for inbound traffic
  • 5-tuple hash distributes connections; source IP affinity provides session persistence
  • NAT Gateway is the recommended solution for SNAT port exhaustion
  • Cross-region LB uses anycast for global Layer 4 distribution
  • Gateway LB transparently chains NVAs into traffic flows

Test Your Knowledge

Question

What is the default distribution mode for Azure Load Balancer?

Click or press Enter to reveal answer

Answer

5-tuple hash: source IP, source port, destination IP, destination port, and protocol. This means different connections from the same client may go to different backends.

Click to flip back

Question

What is the recommended solution for SNAT port exhaustion?

Click or press Enter to reveal answer

Answer

NAT Gateway. It provides 64,000 ports per IP per destination and scales with multiple IPs. It takes precedence over LB outbound rules when associated with the backend subnet.

Click to flip back

Question

What does the 'HA Ports' feature on Standard Internal LB do?

Click or press Enter to reveal answer

Answer

HA Ports creates a load balancing rule for ALL ports and ALL protocols simultaneously. Used with NVAs so all traffic (every port, every protocol) is forwarded to the NVA without creating individual rules.

Click to flip back

Question

How does Gateway Load Balancer differ from Standard?

Click or press Enter to reveal answer

Answer

Gateway LB enables transparent NVA chaining. It's inserted into the traffic path of a Standard LB without changing the application architecture. Traffic passes through the NVA and returns to the Standard LB's backend.

Click to flip back


Knowledge Check

Sam's backend VMs are experiencing intermittent outbound connection failures. Monitoring shows high SNAT port usage. What's the recommended fix?

Knowledge Check

Ravi needs global Layer 4 load balancing with automatic failover between Australia East and West Europe. What should he deploy?


Next up: Traffic Manager: DNS-Based Routing β€” Route traffic globally using DNS with six different routing methods.

← Previous

Choosing Your Hybrid Connection

Next β†’

Traffic Manager: DNS-Based Routing

Guided

I learn, I simplify, I share.

A Guide to Cloud YouTube Feedback

© 2026 Sutheesh. All rights reserved.

Guided is an independent study resource and is not affiliated with, endorsed by, or officially connected to Microsoft. Microsoft, Azure, and related trademarks are property of Microsoft Corporation. Always verify information against Microsoft Learn.