Bird
Raised Fist0
Azurecloud~5 mins

Azure Load Balancer (Layer 4) - Commands & Configuration

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
When you have multiple servers running the same app, you want to share the work evenly so no server gets too busy. Azure Load Balancer helps by spreading incoming network traffic across your servers at the basic network level, making your app faster and more reliable.
When you want to distribute incoming internet traffic to multiple virtual machines to avoid overload on one server.
When you need to keep your app available even if one server goes down by automatically sending traffic to healthy servers.
When you want to balance traffic inside your private network between backend servers without exposing them directly to the internet.
When you want a simple, fast way to route TCP or UDP traffic without complex rules or SSL termination.
When you need to improve app performance by spreading user requests evenly across servers.
Config File - loadbalancer.json
loadbalancer.json
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Network/loadBalancers",
      "apiVersion": "2022-05-01",
      "name": "myLoadBalancer",
      "location": "eastus",
      "properties": {
        "frontendIPConfigurations": [
          {
            "name": "LoadBalancerFrontEnd",
            "properties": {
              "publicIPAddress": {
                "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/publicIPAddresses/myPublicIP"
              }
            }
          }
        ],
        "backendAddressPools": [
          {
            "name": "myBackendPool"
          }
        ],
        "loadBalancingRules": [
          {
            "name": "myLoadBalancingRule",
            "properties": {
              "frontendIPConfiguration": {
                "id": "[concat(resourceId('Microsoft.Network/loadBalancers', 'myLoadBalancer'), '/frontendIPConfigurations/LoadBalancerFrontEnd')]"
              },
              "backendAddressPool": {
                "id": "[concat(resourceId('Microsoft.Network/loadBalancers', 'myLoadBalancer'), '/backendAddressPools/myBackendPool')]"
              },
              "protocol": "Tcp",
              "frontendPort": 80,
              "backendPort": 80,
              "enableFloatingIP": false,
              "idleTimeoutInMinutes": 4,
              "loadDistribution": "Default",
              "probe": {
                "id": "[concat(resourceId('Microsoft.Network/loadBalancers', 'myLoadBalancer'), '/probes/myHealthProbe')]"
              }
            }
          }
        ],
        "probes": [
          {
            "name": "myHealthProbe",
            "properties": {
              "protocol": "Tcp",
              "port": 80,
              "intervalInSeconds": 5,
              "numberOfProbes": 2
            }
          }
        ]
      }
    }
  ]
}

This JSON file is an Azure Resource Manager template that creates a Load Balancer named myLoadBalancer in the eastus region.

frontendIPConfigurations defines the public IP address where the Load Balancer listens for incoming traffic.

backendAddressPools lists the group of virtual machines that will receive the traffic.

loadBalancingRules specify how traffic is distributed from the frontend to the backend, here for TCP port 80.

probes check the health of backend servers to send traffic only to healthy ones.

Commands
This command creates a basic Azure Load Balancer named 'myLoadBalancer' in the 'myResourceGroup' resource group. It sets up the frontend IP configuration and backend pool with the specified names and associates a public IP address.
Terminal
az network lb create --resource-group myResourceGroup --name myLoadBalancer --sku Basic --frontend-ip-name LoadBalancerFrontEnd --backend-pool-name myBackendPool --public-ip-address myPublicIP --location eastus
Expected OutputExpected
{ "frontendIpConfigurations": [ { "name": "LoadBalancerFrontEnd", "privateIpAddress": null, "publicIpAddress": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/publicIPAddresses/myPublicIP" } } ], "backendAddressPools": [ { "name": "myBackendPool" } ], "probes": [], "loadBalancingRules": [] }
→
--sku - Specifies the Load Balancer SKU type (Basic or Standard)
→
--frontend-ip-name - Names the frontend IP configuration
→
--backend-pool-name - Names the backend address pool
This command creates a health probe named 'myHealthProbe' for the Load Balancer to check if backend servers are healthy by testing TCP port 80 every 5 seconds, requiring 2 failed probes before marking unhealthy.
Terminal
az network lb probe create --resource-group myResourceGroup --lb-name myLoadBalancer --name myHealthProbe --protocol tcp --port 80 --interval 5 --threshold 2
Expected OutputExpected
{ "name": "myHealthProbe", "protocol": "Tcp", "port": 80, "intervalInSeconds": 5, "numberOfProbes": 2 }
→
--protocol - Specifies the protocol used for the health probe
→
--interval - Sets how often the probe runs in seconds
→
--threshold - Number of failed probes before marking backend unhealthy
This command creates a load balancing rule that forwards TCP traffic on port 80 from the frontend IP to the backend pool, using the health probe to check server health.
Terminal
az network lb rule create --resource-group myResourceGroup --lb-name myLoadBalancer --name myLoadBalancingRule --protocol Tcp --frontend-port 80 --backend-port 80 --frontend-ip-name LoadBalancerFrontEnd --backend-pool-name myBackendPool --probe-name myHealthProbe
Expected OutputExpected
{ "name": "myLoadBalancingRule", "protocol": "Tcp", "frontendPort": 80, "backendPort": 80, "frontendIpConfiguration": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/loadBalancers/myLoadBalancer/frontendIPConfigurations/LoadBalancerFrontEnd" }, "backendAddressPool": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/loadBalancers/myLoadBalancer/backendAddressPools/myBackendPool" }, "probe": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/loadBalancers/myLoadBalancer/probes/myHealthProbe" } }
→
--frontend-port - Port on the frontend IP to listen on
→
--backend-port - Port on backend servers to forward traffic to
→
--probe-name - Associates the health probe with this rule
This command shows the details of the Load Balancer to verify it was created correctly with the frontend IP, backend pool, health probe, and load balancing rule.
Terminal
az network lb show --resource-group myResourceGroup --name myLoadBalancer
Expected OutputExpected
{ "name": "myLoadBalancer", "location": "eastus", "frontendIpConfigurations": [ { "name": "LoadBalancerFrontEnd", "publicIpAddress": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/publicIPAddresses/myPublicIP" } } ], "backendAddressPools": [ { "name": "myBackendPool" } ], "probes": [ { "name": "myHealthProbe", "protocol": "Tcp", "port": 80 } ], "loadBalancingRules": [ { "name": "myLoadBalancingRule", "protocol": "Tcp", "frontendPort": 80, "backendPort": 80 } ] }
Key Concept

If you remember nothing else from this pattern, remember: Azure Load Balancer spreads network traffic evenly across healthy servers at the basic TCP/UDP level to keep your app fast and available.

Common Mistakes
Not creating or associating a health probe with the load balancing rule.
Without a health probe, the Load Balancer cannot detect unhealthy servers and may send traffic to servers that are down, causing failures.
Always create a health probe and link it to your load balancing rule to ensure traffic only goes to healthy servers.
Using the wrong frontend IP name or backend pool name in commands.
If names do not match the existing Load Balancer configuration, commands will fail or create incorrect settings.
Use consistent and exact names for frontend IP configurations and backend pools when creating rules and probes.
Forgetting to assign a public IP address to the frontend configuration when internet access is needed.
Without a public IP, the Load Balancer cannot receive traffic from the internet.
Create and assign a public IP address to the frontend IP configuration if you want to expose your service publicly.
Summary
Create an Azure Load Balancer with frontend IP and backend pool to distribute traffic.
Add a health probe to check backend server health and avoid sending traffic to unhealthy servers.
Create a load balancing rule to forward traffic from frontend to backend using the health probe.
Verify the Load Balancer setup with the show command to confirm all parts are configured correctly.

Practice

(1/5)
1. What is the primary function of the Azure Load Balancer (Layer 4)?
easy
A. Encrypt data at rest in Azure storage
B. Inspect and modify HTTP headers for incoming requests
C. Store and manage user session data
D. Distribute incoming TCP/UDP traffic evenly across multiple servers

Solution

  1. Step 1: Understand Layer 4 Load Balancing

    Azure Load Balancer works at the transport layer (Layer 4) to distribute TCP/UDP traffic.
  2. Step 2: Identify its main role

    It balances traffic across multiple servers to improve availability and scalability without inspecting message content.
  3. Final Answer:

    Distribute incoming TCP/UDP traffic evenly across multiple servers -> Option D
  4. Quick Check:

    Layer 4 Load Balancer = TCP/UDP traffic distribution [OK]
Hint: Layer 4 means TCP/UDP traffic balancing only [OK]
Common Mistakes:
  • Confusing Layer 4 with Layer 7 load balancer features
  • Thinking it inspects HTTP headers
  • Assuming it manages session data
2. Which of the following is the correct way to configure a backend pool in Azure Load Balancer (Layer 4)?
easy
A. Configure SSL certificates in the backend pool
B. Assign virtual machines or VM scale sets to the backend pool
C. Add HTTP routes to the backend pool
D. Set up DNS names in the backend pool

Solution

  1. Step 1: Understand backend pool composition

    Backend pools in Azure Load Balancer contain virtual machines or VM scale sets to receive traffic.
  2. Step 2: Eliminate incorrect options

    HTTP routes, SSL certificates, and DNS names are not configured in backend pools for Layer 4 load balancer.
  3. Final Answer:

    Assign virtual machines or VM scale sets to the backend pool -> Option B
  4. Quick Check:

    Backend pool = VMs or VM scale sets [OK]
Hint: Backend pool holds VMs or VM scale sets only [OK]
Common Mistakes:
  • Trying to add HTTP routes to backend pool
  • Confusing SSL setup with load balancer config
  • Adding DNS names instead of VMs
3. Given an Azure Load Balancer configured with 3 healthy backend VMs, what happens when one VM becomes unhealthy?
medium
A. Traffic is routed only to the 2 healthy VMs
B. Traffic is evenly distributed to all 3 VMs regardless
C. Load balancer stops routing traffic until all VMs are healthy
D. Traffic is routed only to the unhealthy VM

Solution

  1. Step 1: Understand health probe role

    Azure Load Balancer uses health probes to detect unhealthy VMs and stops sending traffic to them.
  2. Step 2: Apply health probe behavior

    When one VM is unhealthy, traffic is routed only to the remaining healthy VMs to maintain availability.
  3. Final Answer:

    Traffic is routed only to the 2 healthy VMs -> Option A
  4. Quick Check:

    Unhealthy VM excluded from traffic [OK]
Hint: Unhealthy VMs do not get traffic [OK]
Common Mistakes:
  • Assuming traffic still goes to unhealthy VMs
  • Thinking load balancer stops all traffic
  • Believing unhealthy VMs get all traffic
4. You configured an Azure Load Balancer but clients report intermittent connection failures. What is a likely cause?
medium
A. Backend VMs have too much CPU capacity
B. Load balancer is inspecting HTTP headers incorrectly
C. Health probes are misconfigured, marking healthy VMs as unhealthy
D. DNS names are missing in the backend pool

Solution

  1. Step 1: Analyze symptoms

    Intermittent connection failures often relate to backend availability issues.
  2. Step 2: Identify misconfiguration impact

    If health probes are misconfigured, healthy VMs may be marked unhealthy, reducing available servers and causing failures.
  3. Final Answer:

    Health probes are misconfigured, marking healthy VMs as unhealthy -> Option C
  4. Quick Check:

    Misconfigured health probes cause connection failures [OK]
Hint: Check health probe settings first for connection issues [OK]
Common Mistakes:
  • Blaming backend VM CPU capacity without evidence
  • Thinking Layer 4 load balancer inspects HTTP headers
  • Assuming DNS names belong in backend pool
5. You want to design a highly available web service using Azure Load Balancer (Layer 4). Which combination ensures scalability and fault tolerance?
hard
A. Use a backend pool with multiple VM scale sets and configure health probes
B. Use a single VM with static IP and no health probes
C. Configure DNS round-robin without load balancer
D. Use Azure Load Balancer with only one backend VM and no health probes

Solution

  1. Step 1: Identify scalability needs

    Multiple VM scale sets allow automatic scaling of backend servers to handle load.
  2. Step 2: Ensure fault tolerance

    Health probes detect unhealthy instances and route traffic only to healthy ones, improving availability.
  3. Step 3: Evaluate other options

    Single VM or no health probes reduce fault tolerance; DNS round-robin lacks health checks and load balancing features.
  4. Final Answer:

    Use a backend pool with multiple VM scale sets and configure health probes -> Option A
  5. Quick Check:

    Scale sets + health probes = scalable, fault tolerant [OK]
Hint: Combine scale sets with health probes for best availability [OK]
Common Mistakes:
  • Using single VM reduces fault tolerance
  • Ignoring health probes causes traffic to unhealthy VMs
  • Relying on DNS round-robin lacks health checks