Study Guide: Azure Load Balancer (AZ-104)

Azure Load Balancer is Microsoft’s Layer 4 (TCP/UDP) load-balancing service. It distributes traffic across multiple back-end resources (typically VMs, VM Scale Sets, or IP-based endpoints) to improve availability, resilience, and scale.

If you want Layer 7 (HTTP/HTTPS) features like URL routing, WAF, cookie-based affinity, and SSL offload, that’s usually Application Gateway. If you want global anycast entry with edge routing, that’s Front Door.

---

1) Where Azure Load Balancer fits

OSI layer mapping

• Azure Load Balancer: Layer 4 (Transport)
  Works with TCP/UDP, ports, and IPs. Does not inspect HTTP headers or paths.

• Azure Application Gateway: Layer 7 (Application)
  HTTP/HTTPS-aware, supports path-based routing and WAF.

• Azure Front Door: Global edge, Layer 7 routing and acceleration.

• Traffic Manager: DNS-based global routing (not a proxy; returns DNS answers).

Exam cue: If the question says “TCP/UDP”, “high throughput”, “low latency”, “non-HTTP”, think Azure Load Balancer.

---

2) Load Balancer types

Public Load Balancer

• Has a public frontend IP

• Receives traffic from the internet

• Sends to back-end pool (VMs/VMSS) over private IPs

Use cases

• Public-facing apps (TCP 443 to web tier)

• Public NAT to a specific VM (RDP/SSH inbound NAT rules)

Internal Load Balancer (ILB)

• Has a private frontend IP

• Only accessible inside the VNet (or connected networks)

• Commonly used in hub/spoke or multi-tier apps

Use cases

• Front-end tier to back-end tier traffic

• Internal line-of-business apps

• Private services exposed to peered VNets or on-prem via VPN/ER

---

3) SKU: Basic vs Standard (this shows up in AZ-104)

Standard Load Balancer (recommended)

• Secure by default (you must explicitly allow traffic via NSG)

• Better availability and features

• Supports Availability Zones and zone-redundant frontends (region dependent)

• Works well with production patterns

Basic Load Balancer (legacy)

• More limited; older patterns

• Often appears in “you must upgrade/migrate” scenarios

Exam cue: When you see “production”, “zone redundant”, “secure by default”, “recommended”, choose Standard.

---

4) Core building blocks (must memorize)

An Azure Load Balancer configuration is built from these parts:

A) Frontend IP configuration

This is the IP that clients connect to:

• Public IP (Public LB)

• Private IP in a subnet (Internal LB)

B) Backend pool

Group of targets that receive traffic:

• VM NICs

• VMSS instances

• IP addresses (in some scenarios)

C) Health probe

How the LB decides which back-end instances are healthy:

• TCP probe (port open)

• HTTP/HTTPS probe (expects a valid HTTP response from a path)

Key settings:

• Port

• Protocol

• Interval

• Unhealthy threshold (how many failures before marking down)

Exam cue: If one VM is down but still receiving traffic, suspect probe misconfiguration.

D) Load balancing rule

Defines how traffic flows from frontend to backends:

• Protocol (TCP/UDP)

• Frontend port → Backend port

• Backend pool

• Probe

• Optional settings like session persistence and idle timeout

E) Inbound NAT rules (common for admin access)

Map a specific frontend port to a specific VM and port:

• Example: PublicIP:50001 → VM1:3389 (RDP)

• Example: PublicIP:50002 → VM2:3389

F) Outbound rules (SNAT)

Controls outbound internet connectivity for the back-end instances:

• Useful when instances need predictable outbound behavior

• Helps manage SNAT port exhaustion in high-scale environments

---

5) How Azure Load Balancer decides “which VM gets the packet”

Load Balancer uses a hashing algorithm based on tuples. You’ll see this described as:

• 2-tuple: Source IP + Destination IP

• 3-tuple: Source IP + Destination IP + Protocol

• 5-tuple: Source IP + Source Port + Destination IP + Destination Port + Protocol

What this means practically

• Different client connections can land on different backends.

• A single client connection typically stays pinned to one backend for that connection.

---

6) Session persistence (sticky sessions at Layer 4)

Azure Load Balancer can keep a client “stuck” to the same backend based on:

• None (default distribution)

• Client IP

• Client IP and Protocol

Exam cue

• If an app “breaks” when requests jump between servers and it’s not Layer 7-aware, enabling session persistence can help.

---

7) Floating IP and HA Ports (advanced but testable)

Floating IP

Used for certain high-availability scenarios (often with NVAs or failover clustering) where you need to preserve the destination IP. It’s common in:

• SQL Always On patterns (depending on design)

• NVA HA pairs

• Specialized cluster designs

HA Ports

Allows load balancing of all ports for a given protocol (commonly used for NVA scenarios).

Exam cue: If the question says “all ports” or “NVA high availability”, look for HA Ports.

---

8) NSGs and “secure by default” behavior

With Standard Load Balancer, traffic is not automatically allowed just because the LB rule exists.

You usually need:

• NSG inbound allow rule on the backend subnet or NICs

• Allow from the AzureLoadBalancer service tag (common requirement for probes/traffic depending on pattern)

Typical troubleshooting trap

• LB looks correct, probe looks correct, but traffic still fails: NSG denies.

---

9) Step-by-step: Build a Load Balancer in the Azure portal (classic AZ-104 task)

Step 1: Create the Load Balancer

Azure portal → Load balancers → Create

• SKU: Standard

• Type: Public or Internal

• Frontend IP configuration

  • Public: create/choose a Public IP (usually static)

  • Internal: select VNet/subnet and choose private IP settings

• Review + Create

Step 2: Create Backend Pool

Load balancer → Backend pools → Add

• Name: bp-web

• Add targets:

  • Select VMs or VMSS instances

  • Typically select NIC IP configurations

Step 3: Create Health Probe

Load balancer → Health probes → Add

• Protocol: TCP or HTTP/HTTPS

• Port: (example 80 or 443)

• For HTTP/HTTPS: Path (example /health or /)

• Configure interval and unhealthy threshold

Step 4: Create Load Balancing Rule

Load balancer → Load balancing rules → Add

• Frontend IP: choose the frontend config

• Protocol: TCP/UDP

• Frontend port: 443

• Backend port: 443

• Backend pool: bp-web

• Health probe: your probe

• Session persistence: None (unless app needs stickiness)

• Idle timeout: adjust if long-lived connections are expected

• Create

Step 5 (optional): Inbound NAT rules for admin access

Load balancer → Inbound NAT rules → Add

• Frontend port: 50001 → Backend VM1:3389

• Frontend port: 50002 → Backend VM2:3389

Step 6: NSG validation

Ensure:

• Backend subnet NSG allows the needed ports from expected sources

• Probes are not blocked

• For public traffic, allow inbound 443 as needed

---

10) Common troubleshooting flow (AZ-104 style)

1. Health probe status

   • Are backends showing healthy?

   • Probe port/path correct?

2. NSGs

   • Allow rules in place?

   • Wrong priority causing deny?

3. Backend pool membership

   • Correct NIC/IP config added?

4. Ports and protocol

   • TCP vs UDP mismatch?

   • Frontend port mapping correct?

5. Application listening

   • Service actually listening on expected port on VMs?

6. Outbound connectivity

   • If outbound fails at scale, consider outbound rules and SNAT constraints.

---

Practice Questions (Exam Style) + Answers

Questions

1. (MCQ) Azure Load Balancer operates at which OSI layer?
   A. Layer 2
   B. Layer 3
   C. Layer 4
   D. Layer 7

2. (MCQ) Which service is best for HTTP path-based routing and WAF?
   A. Azure Load Balancer
   B. Azure Application Gateway
   C. Azure VPN Gateway
   D. Azure DNS

3. (Short answer) What’s the difference between a Public Load Balancer and an Internal Load Balancer?

4. (MCQ) Which SKU is typically recommended for production and is “secure by default”?
   A. Basic
   B. Standard
   C. Developer
   D. Consumption

5. (Scenario) You created a Standard Public Load Balancer with a rule for TCP 443 to your backend pool. The health probe shows healthy, but users still cannot connect. What is the most likely cause?

6. (MCQ) Which component determines whether a VM is eligible to receive traffic?
   A. Backend pool name
   B. Health probe
   C. Frontend IP configuration
   D. Load balancing algorithm only

7. (MCQ) You need to RDP to VM1 and VM2 through a single public IP. Which feature should you configure?
   A. Outbound rules
   B. Health probes
   C. Inbound NAT rules
   D. Application rules

8. (Scenario) Your application breaks when requests from the same client bounce between servers. What Load Balancer feature can help at Layer 4?

9. (MCQ) Which tuple option includes source and destination ports and protocol?
   A. 2-tuple
   B. 3-tuple
   C. 5-tuple
   D. 7-tuple

10. (Scenario) One backend VM is down, but it still receives traffic sometimes. Name two likely misconfigurations.

11. (MCQ) For internal-only traffic between tiers in the same VNet, which LB type fits best?
    A. Public Load Balancer
    B. Internal Load Balancer
    C. Traffic Manager
    D. Front Door

12. (Scenario) At high scale, outbound internet connections from back-end VMs intermittently fail. What LB feature helps control outbound behavior and reduce SNAT problems?

---

Answers

1. C. Azure Load Balancer is Layer 4 (TCP/UDP).

2. B. Application Gateway is Layer 7 and supports WAF and path-based routing.

3. Public LB uses a public frontend IP for internet-facing traffic. Internal LB uses a private frontend IP for internal traffic only (VNet/connected networks).

4. B. Standard is recommended and secure by default.

5. Most likely NSG blocking inbound traffic (Standard LB requires explicit NSG allow).

6. B. The health probe determines backend eligibility.

7. C. Use Inbound NAT rules to map unique frontend ports to VM ports.

8. Enable Session persistence (Client IP or Client IP and Protocol).

9. C. 5-tuple includes source IP/port, destination IP/port, and protocol.

10. Likely causes:

• Health probe is incorrect (wrong port/path/protocol) so it doesn’t mark unhealthy correctly

• NSG or app config allows probe but real traffic is going somewhere unexpected

• Backend pool includes the wrong NIC/IP configuration (traffic not targeting the intended instance)

11. B. Internal Load Balancer.

12. Configure Outbound rules (helps manage outbound/SNAT behavior).

---