This page gives you an overview of the traffic management capabilities availablefor the classic Application Load Balancer. This page is for the classic Application Load Balanceronly. If you use a load balancer in a different mode with support for theexpanded set of traffic management features, see one of the following pages:

• Traffic management overview forregional external Application Load Balancers

• Traffic management overview forglobal external Application Load Balancers

Classic Application Load Balancer supports traffic managementfunctionality that enables you to use the following features:

• Traffic steering. Intelligently route traffic based on HTTP(S)parameters:
  • Host and path
• Traffic actions. Perform request-based actions:
  • Rewrites
  • HTTP to HTTPS redirects
  • Header-based and parameter-basedrouting
• Traffic policies. Fine-tune load balancing behavior:
  • Timeouts
  • Max rates and maxconnections

You configure these features using the load balancer's URL map. For backgroundinformation, see the following topics:

• URL map overview
• Using URL maps
• Backend services overview

Traffic management components

At a high level, external Application Load Balancers provide traffic management by usingglobal URL maps.

The load balancer provides the following mutually exclusive primary actions:

• Route requests to a backend service
• Perform a redirect

When you set up a load balancer, you can configure a URL rewrite action beforethe load balancer sends requests to the backend service or backend bucket.

Rewrites or redirects can be applied at three levels in the URL map:

• At thepathRule where the action takes effect when a path is matched
• At thepathMatcher where the action takes effect when no paths are matchedfor thispathMatcher
• At theurlMap where the action takes effect when none of the hostsspecified in any of the host rules are matched

UsingrouteRules in apathMatcher is an alternative to usingpathRules.pathRules androuteRules cannot both appear in the samepathMatcher.UnlikepathRules, where order doesn't matter,routeRules are examined inorder. ArouteRule can test the URL path, HTTP headers, and URL queryparameters.

Use case examples

Traffic management addresses many use cases. This section provides a fewhigh-level examples.

Rewrites

URL rewrites allow you to present external users with URLs that are differentfrom the URLs that your services use.

A URL rewrite separates a URL from a resource. You can translate fromhuman-friendly URLs, which are easier for users to remember and use,transforming them into search-engine friendly URLs, which are easier for searchengines to find, or into internal implementation-specific URLs.

The URL rewrite feature does the following:

1. Reads the incoming URL in the request.
2. Replaces the host, the path, or both the host and the path, transforming theURL before directing traffic to the backend service or backend bucket.

In the following diagram:

1. A user in Japan sends a request for the URLwww.mydomain.com/static/images/someimage.jpg.
2. When the request reaches the external Application Load Balancer, the load balancer usesinformation in the URL map to rewrite the URL towww.myorigin.com/august_snapshot/images/someimage.jpg.
3. (Optional) In this example, the URL map sends the request to anexternalbackend.

For a configuration example, seeRewrites.

Redirects

With URL redirects, you can redirect client requests from one URL to anotherURL.

This includes the capability to:

• Redirect all HTTP requests to HTTPS requests.
• Redirect to a different URL formed by modifying the host, path, or both thehost and path portion of the URL, and either stripping out or retaining anyquery parameters.
• Choose which redirect response codes to issue.

Use URL redirects for the following capabilities:

• Provide URL shortening. Client-facing URLs can be made substantiallyshorter. This service issues a redirect to the web page with the long URL.
• Prevent broken links when web pages are moved or become outdated.
• Allow multiple domain names belonging to the same owner to refer to a singleweb site.
• Avoid the toil and inefficiencies of configuring workarounds at the backendserver to support the necessary redirect.
• Reduce latency. Redirects created at the edge can result in lower latencycompared to redirects created at the backend endpoints.

HTTP-to-HTTPS redirects further specifically help you to:

• Meet compliance requirements (such as HIPAA) for encrypted traffic.
• Redirect requests using HTTPS instead of rejecting requests sent with theHTTP protocol.
• Improves the security profile of your application by redirecting the trafficat the layer-7 load balancer itself, as opposed to implementing the redirectat the backend server.

In the following diagram:

1. A user in Japan sends aGET http://example.com/img1 request.
2. Based on the redirect defined in the URL map, the load balancer sends backanHTTP/1.1 302 Found Location: https://example.com/img1 redirect,redirecting the HTTP request to an HTTPS request.
3. The user's browser sends aGET https://example.com/img1 request.

For a configuration example, seeRedirects.

Supported response codes

The supported redirect response codes are listed in the table.

Header-based and parameter-based routing

Header-based and parameter-based routing allow a load balancer to make routingdecisions that are based on HTTP headers and URL query parameters.

With this feature, you can simplify your cloud architecture, without deployingadditional tiers of proxies (NGINX, for example) to do routing.

You can use the external Application Load Balancer to do the following:

• A/B testing
• Assigning customers to different sets of services running on backends
• Delivering different pages and experiences based on different categories ofdevices from which the requests originate

After apathMatcher is selected based on the host string, therouteRules inthepathMatcher select a URL path. For more information, see theURL mapsoverview.

Example: Configuring A/B testing with query parameter-based routing

The following example shows how to doA/Btesting bymatching on the query string to specify the experiment and input.

Suppose that you want to make sure that requests are handled as follows:

• All requests with the query parameter valueA go to the backend servicecalledBackendServiceForProcessingOptionA.
• All requests with the query parameter valueB go to the backend servicecalledBackendServiceForProcessingOptionB.

These requirements are summarized in the following table.

To configure this in yourglobal URLmap, you can create the followingsettings.

For a configuration example, seeHeader-based and parameter-basedrouting.

Routing requests to backends

The backend for your traffic is determined by using a two-phased approach:

• The load balancer selects a backend service with backends. The backends canbe the following:

  • Compute Engine virtual machine (VM) instances in an unmanaged instancegroup
  • Compute Engine VMs in a managed instance group (MIG)
  • Containers by means of a Google Kubernetes Engine (GKE) node in a zonalnetwork endpoint group (NEG)
  • External backends outside of Google Cloud in an internet NEG
  • Cloud Storage in backend buckets
  • App Engine, Cloud Run functions, or Cloud Runservices in a serverless NEG

  The load balancer chooses a backend service based on rules defined in aglobal URL map.

• The backend service selects a backend instance based on policies defined inaglobal backend service.

When you configure routing, you can choose between the following modes:

• Simple host and path testing, by usingpathRules
• Advanced request testing, by usingrouteRules

For each URL map, you can choose to use simple host and path rules or advancedhost, path, and route rules. The two modes are mutually exclusive. Each URLmap can contain only one mode or the other mode.

Simple host and path rule

In a simple host and path rule, URL maps work as described in theURL mapoverview.

The following diagram shows the logical flow of a simple host and path rule.

A request is initially evaluated by using host rules. A host is the domainspecified by the request. If the requesthost matches one of the entries inthehosts field, the associated path matcher is used.

Next, the path matcher is evaluated. Path rules are evaluated on thelongest-path-matches-first basis, and you can specify path rules in any order.After the most specific match is found, the request is routed to thecorresponding backend service. If the request does not match, the defaultbackend service is used.

A typical simple host and path rule might look something like the following,where video traffic goes tovideo-backend-service, and all other traffic goestoweb-backend-service.

$gcloudcomputeurl-mapsdescribeext-https-map

defaultService:global/backendServices/web-backend-servicehostRules:-hosts:-'*'pathMatcher:pathmapname:ext-https-mappathMatchers:-defaultService:global/backendServices/web-backend-servicename:pathmappathRules:-paths:-/video-/video/*service:global/backendServices/video-backend-service

For a configuration example, seeHost andpath.

Advanced host, path, and route rule

Advanced host, path, and route rules provide additional configuration optionscompared to simple host and path rules. These options enable more advancedtraffic management patterns and also modify some of the semantics. For example,route rules are executed in order (rather than by usinglongest-path-matches-first semantics).

As in the earlier simple host and path rule example, you can configureadvanced traffic management by using a global URL map, but instead of usingpathMatchers[].pathRules[], you usepathMatchers[].routeRules[].

The following sections explain the advanced host, path, and route rulecomponents.

Host rules

When a request reaches your load balancer, the request'shost field isevaluated against thehostRules defined in the URL map. Each host ruleconsists of a list of one or more hosts and a single path matcher(pathMatcher). If nohostRules are defined, the request is routed to thedefaultService.

For more information, seehostRules[] anddefaultService in theglobal URL map API documentation.

Path matchers

After a request matches a host rule, the load balancer evaluates thepath matcher corresponding to the host.

A path matcher is made up of the following components:

• One or more path rules (pathRules)or route rules (routeRules).

• A default rule that executes when no other backend services match. The rulehas the following mutually exclusive options:

  • A default service specifies the default backend service to route to when noother backend services match.
  • A default redirect specifies the URL to redirect to when no other backendservices match.

When the load balancer is configured for a default service, it can additionallybe configured to rewrite the URL before sending the request to thedefault service.

For more information, seepathMatchers[],pathMatchers[].pathRules[], andpathMatchers[].routeRules[] in theglobal URL map APIdocumentation.

Path rules

Path rules (pathRules) specify one or more URL paths, such as/ or/video.Path rules are generally intended for the type of simple host and path-basedrouting described previously.

For more information, seepathRules[] in theglobal URL map APIdocumentation.

Route rules

A route rule (routeRules) matches information in an incoming request and makesa routing decision based on the match.

Route rules can contain a variety of different match rules (matchRules) and avariety of different route actions (routeAction).

A match rule evaluates the incoming request based on the HTTP(S) request's path,headers, and query parameters. Match rules support various types of matches(for example, prefix match) as well as modifiers (for example, caseinsensitivity). This enables you to, for example, send HTTP(S) requests to a setof backends based on the presence of a custom-defined HTTP header.

For a detailed list of options supported bymatchRules, seematchRules[] in theglobal URL map APIdocumentation.

If you have multiple route rules, the load balancer executes them inorder, which allows you to specify custom logic for matching, routing,and other actions.

Within a given route rule, when the first match is made, the load balancer stopsevaluating the match rules, and any remaining match rules are ignored.

Google Cloud performs the following actions:

1. Looks for the first match rule that matches the request.
2. Stops looking at any other match rules.
3. Applies the actions in the corresponding route actions.

Route rules have several components, as described in the following table.

For more information, see the following fields in theglobal URL map APIdocumentation:

• routeRules[]
• routeRules[].priority
• routeRules[].description
• routeRules[].service
• routeRules[].matchRules[]
• routeRules[].routeAction
• routeRules[].urlRedirect

Match rules

Match rules (matchRules) match one or more attributes of a request and takeactions specified in the route rule. The following list provides some examplesof request attributes that can be matched by using match rules:

• Host: A host name is the domain name portion of a URL; for example,the host name portion of the URLhttp://example.net/video/hd isexample.net. In the request, the host name comes from theHost header, asshown in this example curl command, where10.1.2.9 is the load-balancedIP address:

  curl -v http://10.1.2.9/video/hd --header 'Host: example.com'

• Paths follow the host name; for example/images. The rule can specifywhether the entire path or only the leading portion of the path needs tomatch.

• Other HTTP request parameters, such as HTTP headers, which allow cookiematching, as well as matching based on query parameters (GET variables).Note that regular expression matching for header values isn't supported.

For a complete list of supported match rules, seepathMatchers[].routeRules[].matchRules[] in theglobal URL map APIdocumentation.

Configuring traffic management

You can use the Google Cloud console,gcloud, or the Cloud Load Balancing API toconfigure traffic management. Within your chosen configuration environment, youset up traffic management by using YAML configurations.

For help writing these YAML files, you can use the following resources:

• Theglobal URL map API documentation

  Provides a full list of fields, including semantics regarding relationships,restrictions, and cardinality.

• Examples on the traffic management set up page:

  • Setting up HTTP-to-HTTPSredirect
  • Setting up URLrewrite
  • Setting up query parameter-basedrouting
  • Setting up HTTP header-basedrouting