Skip to main content
This article explains how Azure Application Gateway implements three core functions for modern web applications: request routing, URL redirection, and rewrite policies. These capabilities let you build secure, scalable, and maintainable HTTP/HTTPS frontends on Azure with centralized traffic control, path-based microservice separation, and header/path transformations.

​
Request routing rules

Request routing rules tell the Application Gateway how to forward incoming HTTP(S) requests to backend pools. Two primary rule types are commonly used:
Rule typeBehaviorTypical use case
BasicAll requests that match the listener are forwarded to a single backend pool.Simple web apps or single-service frontends.
Path-basedRequests are routed to different backend pools based on URL path patterns (for example /api/* → API pool, /images/* → Image pool).Microservices, static assets separated from application logic, multi-tenant sites.
Processing order (v1 and v2 SKUs): path-based rules are evaluated top-to-bottom as they appear in the configuration. The first matching path rule wins. Every routing rule must be linked to a listener — the listener binds a frontend IP/port/protocol combination and selects which routing rule will handle the request.
A presentation slide titled "Application Gateway Request Routing Rules" showing a sidebar of options (Rule Types, Order of Processing, Associated Listener — highlighted, Associated Backend Pool) and a content panel that says "Assigns a listener to each rule."
Each routing rule is associated with a backend pool and backend HTTP settings. For a basic rule all traffic goes to the same pool; for path-based rules different URL paths map to different backend pools — a best practice for separating APIs, static content, and media services.
A slide titled "Application Gateway Request Routing Rules" showing four menu items (Rule Types, Order of Processing, Associated Listener, Associated Backend Pool) and two rule cards: "01 Basic" (all requests go to one backend pool) and "02 Path-based" (different URL paths route to different backend pools). The slide is branded © Copyright KodeKloud.
Example: A path-based routing rule can forward /images/* to an Image Server Pool and /video/* to a Video Server Pool. This separation improves performance, scalability, and operational clarity because each pool can have its own scaling, health probes, and HTTP settings.
A diagram illustrating URL path-based routing: an Application Gateway (with WAF and L7 load balancer) directs requests for /images/* to an Image Server Pool and requests for /video/* to a Video Server Pool. Users hitting kodekloud.com send traffic to the gateway which routes based on the URL path.
Each routing rule must reference a listener. Listeners bind frontend IP/port/protocol combinations to rules, and routing rules reference backend pools and HTTP settings to control how traffic reaches your application instances.

​
Redirection rules

Redirection rules send clients to different URLs, listeners, or external sites. Common uses include upgrading HTTP traffic to HTTPS, consolidating domains, or moving legacy paths to new endpoints. Supported HTTP redirect status codes:
Status codeMeaningTypical scenario
301Permanent RedirectMoved permanently to a new domain/path.
302Found (temporary)Temporary redirect; user-agent may use original method.
303See OtherInstructs client to use GET on the redirected URI.
307Temporary Redirect (preserve method)Temporary redirect while preserving HTTP method (e.g., POST).
A presentation slide titled "Configure Redirection" with a left-side menu listing options like Global Redirection, Path-based Redirection, Redirect to External Site, and Supported Redirection Types. The right side shows an "Application Gateway" diagram and text explaining site-wide redirection (commonly HTTP to HTTPS) between listeners.
Portal redirection options:
  • Global redirection: Redirect all requests from one listener to another (commonly HTTP → HTTPS).
  • Path-based redirection: Redirect only specific path patterns (for example, /cart/* → HTTPS).
  • Redirect to external site: Forward traffic to another domain or an external listener (requires a redirect configuration object).
A presentation slide titled "Configure Redirection" showing a left-side menu with options like "Global Redirection" and the highlighted "Path-based Redirection," plus a diagram and note explaining path-based redirects (e.g., /cart/*) that apply to specific URL paths. The right side explains enabling redirection (such as HTTP to HTTPS) only for certain site sections.
A presentation slide titled "Configure Redirection" showing a left-side menu with options (the "Redirect to External Site" item highlighted) and a right-side diagram plus text explaining redirection to an external site or different listener.
A presentation slide titled "Configure Redirection" showing redirection options on the left and supported HTTP redirect types on the right. The left column lists Global Redirection, Path-based Redirection, Redirect to External Site and a highlighted "Supported Redirection Types" button, while the right panel shows 301 Permanent Redirect, 302 Found, 303 See Other and 307 Temporary Redirect.
Best practice: use 301 when you intend the redirect to be permanent (SEO-friendly), and 307 when you need to preserve the original HTTP method across a temporary redirect.

​
Rewrite policies

Rewrite policies let you modify HTTP request and response attributes before traffic reaches your backend or before responses return to clients. Use rewrite sets (reusable collections of rules) and attach them to routing rules or listeners. Rules support conditions and actions, including header, path, and query-string changes. A valuable action is “re-evaluate request routing,” which reruns path-based routing after the path has been rewritten. Use cases:
  • Add or remove headers (e.g., X-Forwarded-For, security headers).
  • Modify request host or path to match backend expectations.
  • Add or alter query parameters for backend routing.
  • Re-evaluate routing after path rewrite so the gateway forwards to the correct backend.
A presentation slide titled "Configure Rewrite Policies" with three turquoise buttons on the left labeled Request Routing Rule Association, Rewrite Condition, and Rewrite Type. On the right is a "Create rewrite set" UI screenshot showing fields for rewrite rules and an "Add rewrite rule" button highlighted.
Rewrite sets are reusable collections of conditional rules. Associate them with listeners or routing rules to transform headers, paths, or queries before requests hit your backend—useful for host header overrides, security headers, and compatibility mapping.

​
Portal walkthrough — building a path-based routing example

This concise walkthrough shows how to configure a path-based Application Gateway in the Azure portal. The screenshots below follow the portal steps.
  1. Create the Application Gateway resource:
    • Choose subscription, resource group, region, and SKU (Standard_v2 or WAF_v2 for WAF). For this example we select Standard_v2 with a single instance.
    • Note: WAF_v2 includes the web application firewall capability.
A screenshot of the Microsoft Azure portal showing the "Create application gateway" form with fields for subscription, resource group, instance details (name, region, tier, instance count, IP type, HTTP2) and virtual network/subnet selection. Navigation buttons like "Next: Frontends" are visible at the bottom.
  1. Networking: deploy the Application Gateway into a dedicated subnet. Name the subnet exactly ApplicationGatewaySubnet (this exact name is required) and choose an appropriate address range (for example /27 if not using autoscale). Select the subnet for the gateway.
  2. Frontend: create or select a public IP (or private IP for internal gateways). This becomes the gateway frontend address.
  3. Backend pools: create backend pools for each service (for example API servers and image servers). Targets can be VM NICs, IP addresses, or FQDNs.
  4. Routing rules: add a routing rule and create a listener (for example port 80, protocol HTTP). Choose “Path-based” and configure a default backend target plus path rules such as:
    • /api → API backend pool
    • /images → IMG backend pool
When creating backend HTTP settings, configure protocol, backend port, cookie-based affinity (sticky sessions), host name override, and custom probes.
Screenshot of the Microsoft Azure portal showing the Application Gateway "Add a routing rule" configuration page with fields for rule name, priority, listener name, frontend IP, protocol (HTTP/HTTPS), port, and custom error page URLs. The left pane shows the Frontends section with a public IP for the gateway.
  1. Add path entries for /api and /images, each pointing to its respective backend settings and backend pool.
Screenshot of the Microsoft Azure portal on the "Create application gateway" configuration page. The right-hand "Add a path" panel is open with fields filled for Path (/api), Target name (api-target), backend settings, and backend target.
  1. Backend settings: configure HTTP settings for each pool (protocol, port, cookie-based affinity, connection draining, hostname override, etc.). Reuse HTTP settings across multiple paths when settings are identical.
A screenshot of the Microsoft Azure portal during the "Create application gateway" workflow, with the "Add Backend setting" pane open. The pane shows backend settings such as name, protocol (HTTP/HTTPS), port 80, cookie-based affinity, connection draining, and host name override options.
  1. Finalize and create the gateway. Deployment usually takes several minutes.
A screenshot of the Microsoft Azure portal on the "Create application gateway" Configuration step, with an "Add a routing rule" pane open. The pane shows fields for rule name, priority, backend target and path-based rules mapping "/api" and "/images" to backend pools.
After deployment, review the resource overview for WAF configuration (if applicable), backend pools, HTTP settings, frontends, listeners, rules, rewrite sets, and health probes.
A screenshot of the Microsoft Azure portal showing the Application Gateway "appgw-az700-01" overview and settings pane. The page displays resource details (location, subscription, IP) and a green check saying the resource is following "Light" best practices.

​
Adding backend targets and health probes

  • Add virtual machine NICs, IPs, or FQDNs to backend pools.
  • Configure health probes (custom or default) and associate them with backend HTTP settings. Custom probes allow specifying a path, host header, HTTPS, interval, timeout, and unhealthy threshold.
A screenshot of the Microsoft Azure portal showing the "Add health probe" configuration for an Application Gateway. The form includes fields for Name, Protocol (HTTP/HTTPS), Host, Path (/images/example.aspx), Interval/Timeout/Unhealthy threshold and Test/Cancel buttons.
Even without a custom probe, Application Gateway uses default probe behavior tied to HTTP settings. However, custom probes are recommended when you need precise checks (specific path, host header, or thresholds). Once targets are added, verify the pool shows the expected target count.
A Microsoft Azure portal screenshot showing the "Edit backend pool" page for an Application Gateway, with backend targets listed as virtual machines (nic-appgw-img-01 and nic-appgw-img-02) and options to add IP/FQDN. The lower left shows Save and Cancel buttons.

​
Verify in the browser

Use the Application Gateway public IP (or DNS name) to test configured paths:
  • Hitting the root path should return the default backend content.
  • Hitting /api should route to the API backend pool.
  • Hitting /images or /images/index.html should route to the image backend pool.
You should see round-robin responses across backend servers unless cookie-based affinity (sticky sessions) is enabled in HTTP settings.
A browser screenshot showing a green webpage with centered text reading "API Endpoint Active." Below it is server info ("Server: vm-appgw-api-01") and a note that this is the /api path on the API backend.
If you receive a 404 for a path, check:
  • Path mapping in the path-based rule.
  • Presence of content on the backend (for example index.html).
  • Host header or hostname override settings in the HTTP settings.
When corrected, the image backend will return content and round-robin across image servers unless sticky sessions are configured.
A screenshot of a coral-pink webpage titled "Images Gallery" with centered white text showing server info and a line of garbled characters across the page. The browser address bar shows an IP URL and a "Not Secure" warning.

​
Rewrites and backend health checks

  • Rewrites: Create rewrite sets and associate them with routing rules or listeners to change paths, headers, or query strings. Use conditions to target specific traffic and enable “re-evaluate request routing” when the path change should alter backend selection.
  • Backend health: Use the Backend Health blade to inspect each backend instance’s probe status (HTTP 200 indicates healthy). This helps identify failing backend targets and misconfigured probes quickly.
A Microsoft Azure portal screenshot of an Application Gateway "Backend health" page showing four backend servers (IP addresses) all marked Healthy. Each server's health probe returned success (HTTP 200).
Best practices summary:
  • Use path-based routing to isolate microservices and static assets.
  • Use custom health probes to precisely validate backend health.
  • Prefer 301 redirects for permanent moves (SEO-friendly) and 307 for temporary redirects when preserving the HTTP method matters.
  • Centralize header and path transformations via rewrite sets to avoid application-level coupling.
This covers the core concepts and a practical portal walkthrough for Application Gateway request routing, redirection, and rewrite policies.

Watch Video