Skip to main content
This guide walks through the core steps to configure an Azure Application Gateway, describes each major component, and explains how they connect to route traffic from clients to backend targets. Follow the sequence below to design an Application Gateway that reliably terminates TLS (when required), applies routing and security rules, and sends traffic only to healthy backend instances. Key building blocks you will configure:
  • Frontend IP (public or private)
  • Listener (binds IP, port, protocol, and certificate for HTTPS)
  • Routing rules (basic or path-based)
  • Backend pool (VMs, VMSS, App Services, IPs)
  • HTTP settings (backend protocol, port, affinity, probes)
  • Health probes (default or custom)
  • Optional Web Application Firewall (WAF)
The request flow: client -> frontend IP -> listener -> routing rules evaluation -> HTTP settings (including probe association) -> healthy backend instances in the backend pool. Components and purpose Detailed component descriptions Frontend IP
  • The frontend IP configuration is the gateway’s external or internal address. Choose a Public IP for internet-facing services; use a Private IP in a virtual network for internal applications.
Listener
  • A listener binds the selected frontend IP, frontend port (commonly 80 or 443), and protocol (HTTP/HTTPS). For HTTPS listeners, upload or reference an SSL certificate to perform TLS termination (SSL offloading) at the gateway. If you need end-to-end TLS, use HTTPS in the HTTP settings and deploy the necessary trust certificates on the gateway so it can validate backend TLS.
Routing rules
  • Routing rules map a listener to backend pools and HTTP settings. Rules can be:
    • Basic: all traffic from the listener forwards to a single backend pool.
    • Path-based: route requests to different backend pools based on URL path segments (for example, /api -> API pool, /static -> CDN or storage fronting).
Backend pool
  • Backend pools contain the endpoints that will serve requests: VM NICs, VM scale set instances, public/private IP addresses, or App Services. Use health probes to ensure only healthy endpoints receive traffic.
HTTP settings
  • HTTP settings determine how Application Gateway communicates with backend endpoints. Key fields include:
    • Backend protocol: HTTP or HTTPS
    • Backend port: e.g., 80 or 443
    • Cookie-based affinity: enable if session stickiness is required
    • Connection draining: allow existing requests to complete during scale down or maintenance
    • Probe association: reference a custom probe if your application requires a specific health endpoint
Web Application Firewall (WAF)
  • WAF is optional. Select the WAF-enabled SKU to enable OWASP-based protection and managed rule sets. If WAF is not required, use the Standard_v2 SKU for features such as autoscaling and zone redundancy without the application-layer protection.
Health probes
  • Health probes keep track of backend instance health. You can use:
    • Default probe: built-in checks suitable for simple backends
    • Custom probe: define HTTP/HTTPS, host header, path (for example /health), interval, timeout, and unhealthy threshold
  • After creating a custom probe, associate it with the HTTP settings that your routing rules use. Only backends that pass the probe will receive traffic.
Listener configuration details When creating listeners and routing rules, consider:
  • Listener type:
    • Basic (single-site) listener – for single domain scenarios.
    • Multi-site (host-based) listener – supports multiple host names (domains) on the same frontend IP and port.
  • Frontend IP: pick the Public/Private IP configuration the listener should bind to.
  • Frontend port: commonly 80 (HTTP) or 443 (HTTPS).
  • Protocol: HTTP or HTTPS. For HTTPS, upload or attach an SSL certificate to terminate TLS at the gateway.
  • End-to-end TLS: if required, set HTTP settings to use HTTPS and supply backend trust certificates so the gateway can validate backend certificates.
  • Rule priority and processing order: ensure path-based rules and multiple listeners are ordered correctly so requests match the intended rule. Explicit path rules should be more specific than catch-all rules.
The image displays a configuration interface for setting up listeners with options like site type, processing order, IP address, and protocol selection (HTTP/HTTPS). On the right, there's a form for editing an HTTP listener with settings for frontend IP configuration, port, protocol, and custom error pages.
Health probe configuration Health probes are critical to prevent routing traffic to unhealthy backends. In the Azure portal you can:
  • Use the default built-in probe behavior for simple backends.
  • Create a custom probe to specify:
    • Protocol: HTTP or HTTPS
    • Host name or host header
    • Request path (for example, /health or /status/ready)
    • Probe interval and timeout
    • Unhealthy threshold (how many failures before marking an instance unhealthy)
    • Expected status codes or match criteria (for advanced matching in v2 SKUs)
After creating a custom probe, associate it with the HTTP settings used by the routing rule so the Application Gateway uses that probe for marking backend health. Correct probe configuration prevents user requests from being sent to failing instances and improves overall availability.
When creating custom probes, remember to match the probe’s host header and path to something the backend understands (for example, a dedicated health endpoint). Then reference that probe from the HTTP settings used by the routing rule.
References and further reading Use these docs as authoritative references while designing production-ready Application Gateway deployments.

Watch Video