3.2 Azure Application Gateway
📘Microsoft Azure Networking Solutions (AZ-700)
What is a Health Probe?
In Azure Application Gateway, a health probe is like a monitor that continuously checks whether the backend servers (like web servers, APIs, or other services) are healthy and ready to handle traffic.
- If a backend server fails a health probe, Application Gateway stops sending traffic to it until it becomes healthy again.
- This ensures users always get responses from servers that are working.
Think of it as automatic monitoring for backend services in your network.
Why Health Probes Are Important
- Availability – Only healthy servers receive traffic.
- Reliability – Prevents failed servers from serving users.
- Performance – Ensures traffic is distributed efficiently across working servers.
- Automation – Reduces manual intervention in identifying failing servers.
How Health Probes Work in Azure Application Gateway
Health probes send requests to your backend servers at a regular interval and check for specific responses.
Key components:
| Component | Description |
|---|---|
| Protocol | Can be HTTP, HTTPS, or TCP depending on the backend service type. |
| Host | The domain name or IP address that the probe targets. This can be your server’s hostname. |
| Path | For HTTP/S probes, the specific URL path to check (e.g., /health or /status). |
| Interval | How often the probe runs (in seconds). Default is usually 30s. |
| Timeout | Maximum time to wait for a response before marking it as failed. |
| Unhealthy threshold | Number of consecutive failed probes before the server is considered unhealthy. |
Configuring Health Probes – Step by Step
- Go to Azure Portal → Your Application Gateway
- Select “Health Probes” under the “Settings” section.
- Click “Add a Health Probe”
- Configure the probe parameters:
- Name: Friendly name for your probe.
- Protocol: HTTP, HTTPS, or TCP.
- Host: Can be backend IP or hostname.
- Path:
/healthor another endpoint your server responds to with 200 OK. - Interval: How often the probe should check the server.
- Timeout: Time before the probe is considered failed.
- Unhealthy threshold: How many failed probes before marking backend as unhealthy.
- Save the probe and associate it with a backend HTTP setting.
✅ Important: Each backend pool can have its own health probe, or multiple backends can share a probe.
Health Probe Responses
- Healthy backend: Responds within the timeout with expected status code (default is HTTP 200).
- Unhealthy backend: Fails to respond in time or returns an unexpected status code (like 500, 404).
- Recovery: After consecutive successful responses equal to the healthy threshold, the backend is marked healthy again.
Exam Tips for Health Probes
- Remember the difference between backend health and probe health:
- Health probe only checks reachability and response, not application logic.
- HTTP vs HTTPS probes:
- HTTPS probes require a valid certificate if you enable trusted root certificate validation.
- Custom path usage:
- Use a lightweight endpoint that only confirms the server is working. Avoid full pages or heavy operations.
- Thresholds matter:
- Too low → may mark servers unhealthy too quickly.
- Too high → may delay traffic rerouting to healthy servers.
- Backend settings association:
- Probes must be linked to backend HTTP settings for Application Gateway to use them.
IT Example Use Case (Without Real-Life Metaphor)
- A company hosts an internal API for HR systems behind an Application Gateway.
- They create a health probe targeting
/api/status. - If a backend server crashes or takes too long to respond, Application Gateway stops sending requests to that server.
- This ensures HR employees can always access the API without errors.
Key Points to Remember for the Exam
- Purpose: Ensure traffic goes only to healthy backend servers.
- Configurable parameters: Protocol, host, path, interval, timeout, unhealthy threshold.
- Association: Health probe must be linked to backend HTTP settings.
- Behavior: Stops sending traffic to servers failing the probe; resumes after recovery.
- Best practice: Use lightweight endpoints for probes and tune thresholds based on backend performance.
