Routing Policies for Load Balancers

Use routing policies to apply a named ordered list of routing rules to a load balancer's listener.

A routing policy is a named ordered list of routing rules that is applied to a listener. Request routing policies allow you to route ingress traffic requests based on whether they match certain conditions you define. These rule conditions can use boolean and near-match operations. The rules are evaluated in the order you define and the evaluation stops at the first match. You can attach one such request routing rule set to your HTTP or HTTPS listeners. A well-formed request routing rule is made up of one or more match conditions and a single corresponding route action. You can create multiple routing rules. If an incoming request doesn't match any of the rules you created, the request is routed to a default backend set attached to the listener. See Routing Policy Language for an explanation of the routing policy language.

You can perform the following routing policy management tasks:

• Creating a Routing Policy

• Listing Routing Policies

• Getting a Routing Policy's Details

• Editing a Routing Policy

• Deleting a Routing Policy

For HTTP headers, query data parameters, and cookies, the following match types are supported:

• Contains: <key> equals <value>

• Does not contain: <key> equals <value>

• Exists: <key>

• Does not exist: <key>

Routing policies also support rules that match against request URL paths. This behavior is similar to path route sets, but offers different match options. The following match types are supported in routing policies for path matching:

• Is: An exact match of the path, such as /videos or /images.

• Is not: Any path that doesn't exactly match the specified path.

• Starts with: A match happens if the path begins with the input value. If the parameter provided was /videos, then a request for /videos/images would still produce a match.

• Does not start with: A match happens if the path begins with anything other than the parameter provided. If the parameter provided was /videos, then a request for /images/stills would still produce a match.

• Ends with: A match happens if the path ends with the parameter. If the parameter provided was /videos, then a request for both /images/videos or /previews/videos would both produce a match.

• Does not end with: A match happens if the path ends with anything other than the parameter provided. So if the parameter provided was /videos, then a request for /videos/images would produce a match.

The only supported routing rule action is:

• Route to a specific backend set: This choice routes the matched requests to a backend set that you specify.