This page gives you an overview of the advanced traffic management capabilitiesavailable for global external Application Load Balancers. This page is for theglobal external Application Load Balancer only. These load balancers are always global andalways in Premium Tier. If you use a load balancer in a different mode,see one of the following pages:

• Traffic management overview for aclassic Application Load Balancer

• Traffic management overview forregional external Application Load Balancers

• Traffic steering. Intelligently route traffic based on HTTP(S) parameters (forexample, host, path, headers, and other request parameters).
• Traffic actions. Perform request-based and response-based actions (forexample, redirects and header transformations).
• Traffic policies. Fine-tune load balancing behavior (for example, advancedload balancing algorithms).

You can set up these features by using URL maps and backend services.For more information, see the following topics:

• URL map overview
• Using URL maps
• Understanding backend services

Use case examples

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

Traffic steering: header-based routing

Traffic steering lets you direct traffic to service instances based onHTTP parameters such as request headers. For example, if a user's device isa mobile device withuser-agent:Mobile in the request header, trafficsteering can send that traffic to service instances designated to handle mobiletraffic, and send traffic that doesn't haveuser-agent:Mobile to instancesdesignated to handle traffic from other devices.

Traffic actions: weight-based traffic splitting

Deploying a new version of an existing production service generally incurs somerisk. Even if your tests pass in staging, you probably don't want to subject100% of your users to the new version immediately. With trafficmanagement, you can define percentage-based traffic splits across multiplebackend services.

For example, you can send 95% of the traffic to the previous version of yourservice and 5% to the new version of your service. After you've validated thatthe new production version works as expected, you can gradually shift thepercentages until 100% of the traffic reaches the new version of your service.Traffic splitting is typically used for deploying new versions, A/B testing,service migration, and similar processes.

Traffic policies: request mirroring

Your organization might have specific compliance requirements mandating thatall traffic be mirrored to an additional service that can, for example,record the request details in a database for later replay.

Extensibility with Service Extensions

The integration withService Extensionslets you insert custom logic into the load balancing data path ofsupported Application Load Balancersby using callouts and plugins.

You can configure these extensions at various points in the processing path:authorization,edge,route,andtraffic.

You can also use Service Extensions to configure advancedfeatures, such asdynamic forwarding.

For more information, seeService Extensions overview.

Traffic management components

You can set up traffic steering and traffic actions by using URL maps.Google Cloud resources that are associated with URL maps include thefollowing:

• Route rule
• Rule match
• Rule action

You can set up traffic policies by using backend services.Google Cloud resources that are associated with backend servicesinclude the following:

• Locality load balancer policy
• Consistent hash load balancer settings
• Outlier detection

The following diagram shows the resources that are used to implement eachfeature.

Routing requests to backends

• The load balancer selects a backend service or backend bucket based on rulesdefined in aglobal URL map.
• The backend service selects a backend instance based onpolicies defined in aglobal backend service.

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

• Simple host and path rule
• Advanced host, path, and route rule

The two modes are mutually exclusively. 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 map overview.

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 doesn't match, the defaultbackend service is used.

A typical simple host and path rule might look something like the following, wherevideo traffic goes tovideo-backend-service, and all other traffic goes toweb-backend-service.ThedefaultService andservice can point to a backend service or a backendbucket. This example shows backend services.

gcloud compute url-maps describe lb-map

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

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 have an associated priority value and are interpreted in priorityorder (rather than by using longest-path-matches-first semantics).

As in the earlier simple host and path rule example, you can configureadvanced traffic management by using a URL map. For example, the followingURL map configures routing where 95% of the traffic is routed to one backendservice, and 5% of the traffic is routed to another backend service.

ThedefaultService andservice can point to a backend service or a backendbucket. This example shows backend services.

gcloud compute url-maps describe lb-map

defaultService:global/backendServices/service-ahostRules:-hosts:-'*'pathMatcher:matcher1name:lb-mappathMatchers:-defaultService:global/backendServices/service-aname:matcher1routeRules:-matchRules:-prefixMatch:''routeAction:weightedBackendServices:-backendService:global/backendServices/service-aweight:95-backendService:global/backendServices/service-bweight:5

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.

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:

• One or more path rules (pathRules)or route rules (routeRules).
• A default service (defaultService), which is the default backend service or backend bucket that is used when no other backend services or backend buckets match.

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.

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 lets you, for example, send HTTP(S) requests to a setof backends based on the presence of a custom-defined HTTP header.

If you have multiple route rules, the load balancer executes them in priorityorder (based on thepriority field), which lets you specify custom logicfor 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.

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

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 hostname is the domain name portion of a URL; for example,the hostname portion of the URLhttp://example.net/video/hd isexample.net. In the request, the hostname 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 hostname—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).

Route actions

Route actions are specific actions to take when a route rule matches theattributes of a request.

You can specify one of the following route actions:

• Route traffic to a single service (service).
• Split traffic between multiple services (weightedBackendServices weight:x,wherex must be from 0 to 1000).
• Redirect URLs (urlRedirect).

In addition, you can combine any one of the previously mentioned route actionswith one or more of the following route actions:

• Mirror traffic (requestMirrorPolicy).
• Rewrite URL host and path (urlRewrite).
• Retry failed requests (retryPolicy).
• Set timeout (timeout).
• Introduce faults to a percentage of the traffic (faultInjectionPolicy).
• Add CORS policy (corsPolicy).
• Manipulate request or response headers (headerAction).

• urlRedirect
• urlRewrite
• headerAction
• requestMirrorPolicy
• weightedBackendServices
• retryPolicy
• timeout
• faultInjectionPolicy
• corsPolicy

HTTP-to-HTTPS redirects

If you need to redirect HTTP traffic to HTTPS, youcan create two forwarding rules with a common IP address.

Traffic policies

By using backend service resources, you can configure traffic policies tofine-tune load balancing within an instance group or network endpointgroup (NEG). These policies only take effect after a backend service has beenselected by using your URL map (as described previously).

Traffic policies enable you to:

• Control the load balancing algorithm among instances within the backendservice.
• Control the volume of connections to an upstream service.
• Control the eviction of unhealthy hosts from a backend service.

• To configure traffic management for global external Application Load Balancer, seeSetting up traffic management for global external Application Load Balancers.