Skip to main content
Configure Azure Application Gateway to manage and secure incoming web traffic for your applications. This guide walks through the core components, how traffic flows through the gateway, and the recommended configuration sequence for deployment and troubleshooting. On the left are the building blocks — front-end IP and listeners, routing rules, backend pools, Web Application Firewall (WAF), HTTP settings, and health probes — and on the right a flowchart showing how traffic travels from the front-end to the back ends. Understanding this flow helps when designing and troubleshooting your gateway.
A slide titled "Configure Application Gateway" showing the gateway components (Frontend IP, Listeners, Routing rules, Backend pools, Web Application Firewall, Health probes) on the left and a flowchart on the right mapping Frontend IP → Listener → Port/Certificate → Rule → Backend Pool/HTTP settings and Custom Probe.

​
High-level component responsibilities

Use this table to quickly understand each component’s purpose when designing or documenting an Application Gateway deployment.
ComponentResponsibilityTypical configuration notes
Front-end IPReceives client traffic (Public or Private)Assign a Public IP for internet-facing apps or a Private IP for internal-only access
ListenerEntry point binding (frontend IP + port + optional TLS cert)Use port 80 for HTTP, 443 for HTTPS; SNI/host headers supported for multi-site routing
Routing ruleRoutes request from listener to backend pool + HTTP settingsChoose basic, path-based, or host-based rules to direct traffic
Backend poolCollection of backend targets (VMs, VMSS, IPs, App Services)Backend targets are referenced by NIC, IP, or App Service resource
HTTP settingsHow gateway communicates with backends (port, protocol, timeouts, affinity)Attach health probes and configure cookie affinity or connection draining as needed
Health probeVerifies backend health before sending trafficUse default or custom probes (path, host header, intervals, match criteria)
Web Application Firewall (WAF)Optional protection from common web vulnerabilitiesAvailable on WAF SKU (WAF_v2), apply managed or custom rules
WAF is optional — deploy Application Gateway with the Standard_v2 SKU if WAF features are not required. Choose WAF_v2 when you need built-in OWASP protections and custom rule support.

​
Front-end IP and listeners

The front-end IP and listeners define how clients connect to the gateway and initiate requests that the gateway will route.
  • Front-end IP: Exposes either a Public IP (internet-facing) or a Private IP (internal) to receive traffic.
  • Listener: Binds a front-end IP, port, and optionally a TLS/SSL certificate. It is the match target for incoming requests.
    • Use port 80 for HTTP and port 443 for HTTPS.
    • For HTTPS, upload the TLS certificate to the listener for SSL/TLS termination (offload), or configure end-to-end encryption (re-encryption) if the backend requires TLS.
  • Listener types:
    • Single-site (basic) listener — serves one site or host.
    • Multi-site listener — uses host headers (SNI) to host multiple domains on the same frontend.
  • Listener processing: The gateway matches incoming requests to listeners by front-end IP, port, and host name. When multiple listeners could match, the most specific match is selected (for example, a listener that specifies a host name). URL path maps and routing rules then determine the backend selection.
A presentation slide titled "Configure Listeners" with five blue rounded buttons listing listener settings (Single Site or Multi-Site; Listener Processing Order; Frontend IP Address; Frontend Port; Protocol Selection (HTTP/HTTPS)). On the right is a screenshot of an Azure Application Gateway "appGatewayHttpListener" configuration pane showing frontend IP/port, protocol, certificate selection and custom error pages.

​
Listeners connect to backends via routing rules

Routing rules are the bridge between what the gateway receives and where it forwards requests.
  • A routing rule ties a listener to:
    • A backend pool (the targets that will receive traffic)
    • HTTP settings (how the gateway communicates with those targets)
  • Routing rule types:
    • Basic rule — maps one listener to one backend pool.
    • Path-based rule (URL path map) — routes different URL paths (for example /images, /api) to different backend pools.
    • Host-based routing — used with multi-site listeners to route based on host headers.

​
Health probes

Health probes ensure the gateway only sends traffic to healthy backend endpoints.
  • Use either the default probe or create a custom probe tuned to your application’s health endpoint.
  • Custom probe options:
    • Protocol: HTTP or HTTPS
    • Host header: specify the host to send in the probe request
    • Path: the URL path to check (for example /health or /status)
    • Interval: time between probes
    • Timeout: probe response timeout
    • Unhealthy threshold: number of failed probes before marking unhealthy
    • Match criteria: status codes or response body match conditions considered healthy
  • Associate probes with HTTP settings that are used by your routing rules to ensure probe logic matches actual application behavior.
A presentation slide titled "Configure Health Probes" showing three teal buttons on the left ("Default Health Probe", "Custom Health Probe", "Probe Matching") and, on the right, an "Add health probe" configuration form with fields for name, protocol, host, path, interval, timeout and unhealthy threshold.
Properly configured probes prevent requests from being routed to unhealthy or offline servers, improving application availability and user experience. Follow this sequence when creating or updating an Application Gateway to ensure a predictable, testable deployment:
  1. Create or select the front-end IP (Public for internet-facing, Private for internal).
  2. Add listeners; upload TLS certificates if terminating TLS at the gateway.
  3. Create backend pools and reference your targets (VMs, VMSS, App Services, or IPs).
  4. Configure HTTP settings and associate a health probe that matches your application endpoints.
  5. Create routing rules (basic, path-based, or multi-site) to map listeners to backend pools and HTTP settings.
  6. Optionally enable WAF and attach WAF policies if web protection is required.
  7. Validate with health probe status, gateway diagnostic logs, and end-to-end functional tests.
Traffic flow summary: Front-end IP → Listener → Routing Rule → Backend Pool (via HTTP settings + Health Probe) → (optional) WAF processing Use these references for deeper technical steps, ARM/Bicep examples, and troubleshooting guidance when deploying Application Gateway in production.

Watch Video