Application Gateway Routing Rules

Application Gateway routing rules are the heart of how your gateway directs incoming traffic to the appropriate backend resources. These rules determine which backend pool receives traffic based on the request's characteristics.

Types of Routing Rules

Application Gateway supports two primary types of routing rules:

Basic Rules

A basic rule associates a listener with a single backend pool. All traffic received by the listener will be directed to this backend pool. This is suitable for simple scenarios where all requests to a specific port and host are intended for the same set of servers.


// Example of a basic routing rule configuration (conceptual)
{
  "name": "BasicRuleToAppServer",
  "listener": "ListenerForHTTP",
  "backendPool": "AppServersPool"
}

Path-Based Rules

Path-based routing allows for more granular control. You can define multiple rules that match specific URL paths within a single listener. This enables you to route requests to different backend pools based on the requested URL. For example, requests to /images/* could go to an image processing backend, while requests to /api/* go to an API backend.

A path-based rule consists of:

A listener to which the rule applies.
A set of Path Rules, where each path rule defines:
- A Path Match Condition (e.g., /images/*, /users/{id}).
- A target Backend Pool.
- An optional HTTP Settings configuration.

Content-Based Routing

Application Gateway can also perform content-based routing, which allows you to route traffic based on HTTP headers, query string parameters, and other request attributes. This provides even greater flexibility in directing traffic to specific backend services.

How Routing Rules Work

Listener Match: When a request arrives at Application Gateway, it first checks if it matches any of the configured listeners based on protocol, port, hostname, and IP address.
Rule Evaluation: If a listener is matched, Application Gateway evaluates the associated routing rules.
Path Matching (for Path-Based Rules): For path-based rules, Application Gateway examines the URL path of the incoming request and compares it against the defined path match conditions. The most specific match is typically prioritized.
Header/Content Matching (for Content-Based Routing): If content-based routing is configured, Application Gateway analyzes the request headers and body to determine the routing path.
Backend Pool Selection: Based on the matched rule, Application Gateway selects the appropriate backend pool.
Request Forwarding: The request is then forwarded to one of the healthy instances within the selected backend pool, using the configured HTTP settings.

Key Components of a Routing Rule

Component	Description
Listener	The front-end IP, port, protocol, and optionally, hostname, that Application Gateway listens on for incoming requests.
Request Routing Rule	The core component that links a listener to a backend target (backend pool or Application Gateway's own HTTP settings).
Path Rules	Define conditions (URL paths, hostnames) for path-based routing.
Backend Pool	A group of backend servers that will receive traffic.
HTTP Settings	Defines the protocol, port, cookie-based affinity, connection draining, and probe settings for traffic sent to the backend pool.

Default Rule

Every Application Gateway must have at least one default rule. This rule is used if no other specific routing rule matches the incoming request. It's typically configured to route traffic to a default backend pool.

Important: Ensure your routing rules are configured correctly to avoid unexpected traffic behavior or application downtime. Always test your routing configurations thoroughly.

Example: Routing to Microservices

Consider an application with multiple microservices deployed across different backend pools:

User Service: Handles user-related operations.
Product Service: Manages product information.
Order Service: Processes customer orders.

You can configure a single listener and a path-based routing rule to direct traffic like this:

Requests to /users/* go to the User Service Backend Pool.
Requests to /products/* go to the Product Service Backend Pool.
Requests to /orders/* go to the Order Service Backend Pool.

This allows for efficient and organized traffic management for a microservices architecture.

Azure Application Gateway