Bird
Raised Fist0
Azurecloud~5 mins

Backend pools and health probes in Azure - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

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 run an app on multiple servers, you need a way to send user requests to healthy servers only. Backend pools group these servers, and health probes check if each server is working well. This keeps your app reliable and fast.
When you want to balance user traffic across several servers to avoid overload.
When you need to automatically stop sending requests to servers that are down or slow.
When you want to improve app availability by detecting and bypassing unhealthy servers.
When you deploy a web app behind an Azure Load Balancer or Application Gateway.
When you want to monitor server health without manual checks.
Config File - backendpool-healthprobe.json
backendpool-healthprobe.json
{
  "type": "Microsoft.Network/applicationGateways",
  "apiVersion": "2023-02-01",
  "name": "myAppGateway",
  "location": "eastus",
  "properties": {
    "backendAddressPools": [
      {
        "name": "myBackendPool",
        "properties": {
          "backendAddresses": [
            { "ipAddress": "10.0.1.4" },
            { "ipAddress": "10.0.1.5" }
          ]
        }
      }
    ],
    "probes": [
      {
        "name": "myHealthProbe",
        "properties": {
          "protocol": "Http",
          "host": "localhost",
          "path": "/health",
          "interval": 15,
          "timeout": 5,
          "unhealthyThreshold": 3,
          "match": {
            "statusCodes": ["200-399"]
          }
        }
      }
    ],
    "httpListeners": [
      {
        "name": "myListener",
        "properties": {
          "frontendIPConfiguration": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGateway/frontendIPConfigurations/myFrontendIP" },
          "frontendPort": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGateway/frontendPorts/myFrontendPort" },
          "protocol": "Http"
        }
      }
    ],
    "requestRoutingRules": [
      {
        "name": "rule1",
        "properties": {
          "ruleType": "Basic",
          "httpListener": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGateway/httpListeners/myListener" },
          "backendAddressPool": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGateway/backendAddressPools/myBackendPool" },
          "backendHttpSettings": {
            "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGateway/backendHttpSettingsCollection/myBackendHttpSettings"
          }
        }
      }
    ],
    "backendHttpSettingsCollection": [
      {
        "name": "myBackendHttpSettings",
        "properties": {
          "port": 80,
          "protocol": "Http",
          "probe": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGateway/probes/myHealthProbe" }
        }
      }
    ]
  }
}

This JSON defines an Azure Application Gateway with:

  • backendAddressPools: Groups two servers by their IPs to receive traffic.
  • probes: A health probe that checks the path '/health' on each server every 15 seconds.
  • httpListeners: Listens for incoming HTTP requests.
  • requestRoutingRules: Routes requests from the listener to the backend pool using the health probe.
  • backendHttpSettingsCollection: Connects the health probe to the backend pool on port 80.

This setup ensures traffic only goes to healthy servers.

Commands
This command creates an Azure Application Gateway named 'myAppGateway' with a backend pool of two servers and a health probe checking '/health' every 15 seconds. It sets up the frontend and backend ports and protocols.
Terminal
az network application-gateway create --name myAppGateway --resource-group myResourceGroup --location eastus --sku Standard_v2 --capacity 2 --frontend-port 80 --http-settings-port 80 --http-settings-protocol Http --probe-name myHealthProbe --probe-path /health --probe-interval 15 --probe-timeout 5 --probe-unhealthy-threshold 3 --backend-pool-name myBackendPool --backend-addresses 10.0.1.4 10.0.1.5
Expected OutputExpected
{ "provisioningState": "Succeeded", "resourceGroup": "myResourceGroup", "name": "myAppGateway", "location": "eastus", "sku": { "name": "Standard_v2", "tier": "Standard_v2" }, "capacity": 2 }
→
--probe-path - Sets the URL path the health probe checks
→
--backend-addresses - Specifies the IP addresses in the backend pool
→
--probe-unhealthy-threshold - Number of failed probes before marking backend as unhealthy
This command shows the current configuration of the Application Gateway to verify the backend pool and health probe are set correctly.
Terminal
az network application-gateway show --name myAppGateway --resource-group myResourceGroup
Expected OutputExpected
{ "name": "myAppGateway", "resourceGroup": "myResourceGroup", "location": "eastus", "provisioningState": "Succeeded", "backendAddressPools": [ { "name": "myBackendPool", "backendAddresses": [ { "ipAddress": "10.0.1.4" }, { "ipAddress": "10.0.1.5" } ] } ], "probes": [ { "name": "myHealthProbe", "properties": { "protocol": "Http", "path": "/health", "interval": 15 } } ] }
This command checks the health status of each server in the backend pool using the configured health probe.
Terminal
az network application-gateway backend-health show --name myAppGateway --resource-group myResourceGroup
Expected OutputExpected
{ "backendAddressPools": [ { "name": "myBackendPool", "backendHttpSettingsCollection": [ { "servers": [ { "address": "10.0.1.4", "health": "Healthy" }, { "address": "10.0.1.5", "health": "Healthy" } ] } ] } ] }
Key Concept

If you remember nothing else from this pattern, remember: backend pools group your servers and health probes check their status to send traffic only to healthy ones.

Common Mistakes
Not configuring the health probe path correctly or leaving it empty.
The probe won't correctly check server health, causing traffic to be sent to unhealthy servers.
Set the probe path to a valid URL on your servers that returns a success status when healthy, like '/health'.
Forgetting to add backend server IPs to the backend pool.
No servers receive traffic, so your app won't respond to users.
Always specify the IP addresses or FQDNs of your backend servers in the backend pool configuration.
Setting the unhealthy threshold too low, causing servers to be marked unhealthy too quickly.
Temporary glitches can cause servers to be wrongly marked unhealthy, reducing availability.
Use a reasonable threshold like 3 failed probes before marking a server unhealthy.
Summary
Create an Application Gateway with backend pools grouping your servers.
Configure health probes to check server health regularly on a specific path.
Use commands to verify the gateway configuration and backend server health.

Practice

(1/5)
1. What is the main purpose of a backend pool in Azure Load Balancer?
easy
A. To create virtual networks
B. To monitor the health of servers
C. To store user data securely
D. To group servers that will share incoming user requests

Solution

  1. Step 1: Understand backend pool role

    A backend pool groups multiple servers to distribute incoming traffic among them.

  2. Step 2: Differentiate from health probes

    Health probes check server status, but backend pools organize servers for load balancing.

  3. Final Answer:

    To group servers that will share incoming user requests -> Option D

  4. Quick Check:

    Backend pool = group servers for requests [OK]
Hint: Backend pools group servers; health probes check server status [OK]
Common Mistakes:
  • Confusing backend pools with health probes
  • Thinking backend pools store data
  • Mixing backend pools with network creation
2. Which of the following is the correct way to define a health probe in Azure Load Balancer configuration?
easy
A. healthProbe: { protocol: 'TCP', port: 80, intervalInSeconds: 15, numberOfProbes: 2 }
B. healthProbe: { protocol: 'FTP', port: 21, intervalInSeconds: 10, numberOfProbes: 3 }
C. healthProbe: { protocol: 'HTTP', port: 8080, intervalInSeconds: 5, numberOfProbes: 1 }
D. healthProbe: { protocol: 'UDP', port: 53, intervalInSeconds: 20, numberOfProbes: 4 }

Solution

  1. Step 1: Identify valid protocols for health probes

    Azure Load Balancer supports TCP and HTTP probes; FTP and UDP are invalid.

  2. Step 2: Check probe parameters

    healthProbe: { protocol: 'TCP', port: 80, intervalInSeconds: 15, numberOfProbes: 2 } uses TCP on port 80 with reasonable intervals and probe counts, matching best practices.

  3. Final Answer:

    healthProbe: { protocol: 'TCP', port: 80, intervalInSeconds: 15, numberOfProbes: 2 } -> Option A

  4. Quick Check:

    Valid protocol and settings = healthProbe: { protocol: 'TCP', port: 80, intervalInSeconds: 15, numberOfProbes: 2 } [OK]
Hint: Use TCP or HTTP protocols for health probes in Azure [OK]
Common Mistakes:
  • Using unsupported protocols like FTP or UDP
  • Setting too few probes causing false negatives
  • Choosing invalid port numbers
3. Given this health probe configuration:
protocol: 'HTTP', port: 8080, intervalInSeconds: 10, numberOfProbes: 3

If the backend server responds successfully on the first two probes but fails on the third, what will Azure Load Balancer do?
medium
A. Mark the server as unhealthy immediately after the first failure
B. Mark the server as unhealthy after three consecutive failures
C. Ignore the probe results and keep the server in the pool
D. Keep the server as healthy because two successful probes passed

Solution

  1. Step 1: Understand numberOfProbes meaning

    numberOfProbes defines how many consecutive failed probes mark a server unhealthy.

  2. Step 2: Analyze probe results

    Only one failure occurred, so the server is still healthy until 3 consecutive failures happen.

  3. Final Answer:

    Mark the server as unhealthy after three consecutive failures -> Option B

  4. Quick Check:

    3 failures needed to mark unhealthy = Mark the server as unhealthy after three consecutive failures [OK]
Hint: Server unhealthy after consecutive failed probes count reached [OK]
Common Mistakes:
  • Marking unhealthy after a single failure
  • Ignoring the numberOfProbes setting
  • Assuming any failure removes server immediately
4. You configured a backend pool with three servers and a health probe. One server is always marked unhealthy even though it is running fine. What is the most likely cause?
medium
A. Backend pool has too many servers
B. Load balancer is not assigned a public IP
C. Health probe is configured with the wrong port or protocol
D. The backend server is overloaded with traffic

Solution

  1. Step 1: Check health probe configuration

    If the probe uses the wrong port or protocol, it will fail to get a healthy response from the server.

  2. Step 2: Rule out other causes

    Too many servers or missing public IP do not cause probe failures; overload affects performance but not probe success directly.

  3. Final Answer:

    Health probe is configured with the wrong port or protocol -> Option C

  4. Quick Check:

    Wrong probe config causes false unhealthy status [OK]
Hint: Check probe port and protocol if server shows unhealthy wrongly [OK]
Common Mistakes:
  • Blaming backend pool size for probe failures
  • Ignoring probe configuration details
  • Assuming public IP affects probe health
5. You want to ensure high availability for your web app using Azure Load Balancer. You have three backend servers and want to configure health probes and backend pools. Which combination best improves reliability and performance?
hard
A. Create a backend pool with all three servers and a TCP health probe on port 80 with 5-second intervals and 2 probes
B. Create separate backend pools for each server and no health probes
C. Create a backend pool with two servers only and an HTTP health probe on port 8080 with 30-second intervals and 5 probes
D. Create a backend pool with all servers and a health probe using unsupported protocol FTP

Solution

  1. Step 1: Use a single backend pool for load distribution

    Grouping all servers in one backend pool balances traffic and improves availability.

  2. Step 2: Configure a valid health probe with appropriate settings

    TCP probe on port 80 with short intervals and few probes quickly detects unhealthy servers.

  3. Step 3: Evaluate other options

    Separate pools reduce load balancing benefits; no probes risk sending traffic to bad servers; unsupported protocols cause failures.

  4. Final Answer:

    Create a backend pool with all three servers and a TCP health probe on port 80 with 5-second intervals and 2 probes -> Option A

  5. Quick Check:

    All servers + valid probe = best reliability [OK]
Hint: Use all servers in one pool with valid health probe for best uptime [OK]
Common Mistakes:
  • Splitting servers into multiple pools unnecessarily
  • Skipping health probes
  • Using unsupported protocols for probes