Skip to main content
Azure Application Gateway — Layer 7 routing options and how to configure them Azure Application Gateway provides Layer 7 (HTTP/HTTPS) routing and load‑balancing features that let you direct traffic to the most appropriate backend pools. This article covers two common routing approaches supported by Application Gateway: path-based routing and multi-site (host-based) routing. It then steps through a demo deployment and the portal configuration required to implement path-based routing for a simple color-based demo app.

​
Routing approaches

  • Path-based routing (URL path)
  • Multi-site routing (hostname / domain)
Path-based routing and multi-site routing both use Layer 7 features to enable granular traffic management and a better user experience by sending requests to the backend best suited to serve them. Path-based routing Path-based routing allows the Application Gateway to inspect the request URL path and forward requests to a specific backend pool based on path patterns. Typical examples:
  • */images/* → image server pool optimized for static content
  • */video/* → video server pool for streaming and large media
This is useful when a single application exposes multiple services or microservices that should be handled by different server groups. Multi-site routing Multi-site routing enables one Application Gateway to host multiple domains or hostnames. Incoming requests are routed to different backend pools based on the request hostname. Example:
  • https://kodekloud.com → learning backend pool
  • https://kodekloudlabs.com → lab backend pool
Using a single gateway for multiple sites reduces infrastructure overhead by consolidating hosts behind one public endpoint.
A diagram titled "Application Gateway – Routing Rules" comparing two routing types: path-based routing (routes /images/* and /video/* to image and video server pools) and multiple-site routing (routes different domains like kodekloud.com and kodekloudlabs.com to separate learning and lab pools).

​
Demo: Deploying an Application Gateway in the Azure portal

This demo uses a prepared deployment script that creates several VMs representing backend pools:
  • Red pool: red-01, red-02 (default)
  • Blue pool: blue-01, blue-02 (served at /blue)
  • Green pool: green-01, green-02 (served at /green)
  • Jumpbox for SSH access to the private VMs
Desired routing behavior for the demo:
  • Default (root path) → red servers
  • Paths containing /blue → blue servers
  • Paths containing /green → green servers
Run the deployment script to create the demo resources. Note VM IP addresses and the jumpbox DNS. Occasionally VM extension errors occur during deployment; if they do you can SSH into the jumpbox and from there SSH into individual VMs to verify or fix configuration. Example trimmed deployment console output:
Sometimes configuration extensions fail — you can still SSH to the machines from the jumpbox and verify configuration manually. Viewing the VMs After deployment, the VMs should be visible and in the Running state in the Azure portal. The list typically includes the jumpbox plus the color-named VMs.
A screenshot of the Microsoft Azure portal showing the "Virtual machines" list. It displays seven Linux VMs (e.g., blue-01, green-01, jumpbox-vm, red-02) in the East US subscription, all with status "Running."

​
Create the Application Gateway (portal walkthrough)

Follow these high-level steps in the Azure portal to create and configure the Application Gateway for the demo:
  1. Start Create > Application Gateway in the Azure portal (portal.azure.com).
    • Select subscription, resource group and provide a name for the gateway.
  2. Choose SKU / tier:
    • Options: Standard, Standard_v2, WAF, WAF_v2.
    • For this demo use Standard_v2 (supports autoscaling and improved performance). For production workloads, evaluate WAF if you require web application firewall protection.
  3. Set instance count and availability zones as needed (single instance is fine for demos).
  4. Ensure networking: select the virtual network and a dedicated subnet for the Application Gateway.
  5. Configure Frontends (assign or create a Public IP for internet-facing gateways).
  6. Define backend pools — create a pool for each color group (red, blue, green).
  7. Create backend HTTP settings (protocol, port, host header override, cookie affinity as needed).
  8. Create a listener and routing rules:
    • For path-based routing, create a basic listener and then add path-based rule entries mapping /blue/* and /green/* to the corresponding backend pools.
Virtual network and subnet requirements Application Gateway requires a dedicated subnet in the virtual network. If your virtual network lacks a suitable subnet, use the portal to add one. For demos you can use a larger subnet (for example /24), but in production plan subnet sizes according to scale and security requirements.
Application Gateway must be deployed into its own subnet (usually named ApplicationGatewaySubnet). Do not place other resources in that subnet. Plan IP address capacity for your expected scale and features (v2 SKUs can reduce address needs, but still plan ahead).
In this demo, an ApplicationGatewaySubnet was added and is selectable during gateway creation.
A screenshot of the Microsoft Azure portal showing the "color-web-vnet" virtual network Subnets page with a list of subnets (jumpboxSubnet, greenSubnet, redSubnet, blueSubnet, ApplicationGatewaySubnet) and their IPv4 ranges. A notification in the corner says "Successfully added subnet 'ApplicationGatewaySubnet'."
Frontends and public IP For a public-facing Application Gateway you must create or select a Public IP address during the Frontends step. You can create a new public IP resource and choose SKU and assignment (static/dynamic) based on your needs.
A screenshot of the Microsoft Azure portal showing the "Create application gateway" form with fields for subscription, resource group, application gateway name, region, tier, instance count, virtual network and subnet. A cursor is clicking the "Next: Frontends >" button at the bottom.
When adding the public IP, provide a descriptive name (for example PIP) and set SKU and assignment method as needed.
A Microsoft Azure portal screenshot of the "Create application gateway" wizard on the Frontends step. A pop-up "Add a public IP" dialog is open with the name field being filled and SKU/assignment options shown.
Backend pools Create backend pools for each color group (red, blue, green). You can create the named pools first and add the VM IP addresses later. Named pools make it easy to reference them when creating routing rules. Routing rules and listeners Routing rules connect frontend listeners to backend targets. For this demo create a basic HTTP listener on port 80 and then add path-based rule entries:
  • Rule name: appgwcolors HTTP route
  • Listener name: AppGW-colors-HTTP-listener
  • Frontend IP: Public
  • Protocol: HTTP
  • Port: 80
  • Listener type: Basic (use multi-site listeners only for host-based routing)
A screenshot of the Microsoft Azure portal showing the "Create application gateway" workflow with the "Add a routing rule" pane open. The panel displays configuration fields for a listener and backend targets (HTTP on port 80, listener name, rule name, and custom error page fields).
Backend HTTP settings Backend HTTP settings control how the Application Gateway communicates with backend servers (protocol, port, cookie affinity, host header override, connection draining, etc.). For the demo add a backend setting for the red (default) pool using HTTP on port 80. Create separate backend HTTP settings if blue and green pools require different host header or cookie affinity behavior.
A screenshot of the Microsoft Azure portal on the "Create application gateway" configuration page showing Frontends and Routing sections. A right-side modal titled "Add Backend setting" displays fields for backend name, protocol, port and additional options like cookie affinity, connection draining and host name override.
Next steps — configure path-based rules After creating the basic listener and default backend HTTP setting, add path-based routing rules. In the routing rule configuration:
  • Add path-based rule entries such as /blue/* and /green/*.
  • For each path pattern select the corresponding backend pool and backend HTTP setting.
  • Save and validate the configuration; test by sending requests to the public IP or DNS name with the appropriate paths.
Testing tips
  • Use curl or a browser to test http://<public-ip-or-dns>/, http://<public-ip-or-dns>/blue/, and http://<public-ip-or-dns>/green/ to confirm routing to the red, blue, and green pools respectively.
  • If backend responses are not as expected, verify backend health probes and backend HTTP settings (host header and port).
  • If a VM extension failed during deployment, SSH from the jumpbox and check the web server/container on the target VM.
Summary
  • Path-based routing directs traffic by URL path to specific backend pools.
  • Multi-site routing directs traffic by hostname (domain) to different backend pools.
  • Application Gateway requires a dedicated subnet and a frontend IP (public for internet-facing gateways).
  • Configure listeners, backend HTTP settings, backend pools, and routing rules to implement the desired routing behavior.
Links and references

Watch Video