1. Overview
   1. Internal HTTP(S) Load Balancing supports advanced traffic management functionality
   2. Intelligently route traffic based on HTTP(S) parameters (host, path, headers, and other request parameters)
   3. Perform request-based and response-based actions (redirects and header transformations)
   4. Fine-tunes load balancing behavior based on traffic policies (advanced load balancing algorithms)
2. Traffic steering
   1. Traffic steering allows users to direct traffic to service instances based on HTTPS parameters such as request headers
   2. If a user's device is a mobile device with user-agent:Mobile in the request header, traffic steering can send that traffic to service instances designated to handle mobile traffic
3. Traffic actions
   1. Internal HTTP(S) Load Balancing allows users to define percentage-based traffic splits across multiple backend services
   2. Users can send 95% of the traffic to the previous version of the service and 5% to the new version of the service
   3. After users validated that the new production version works as expected, users can gradually shift the percentages until 100% of the traffic reaches the new version of the service
   4. Traffic splitting is typically used for deploying new versions, A/B testing, service migration, and similar processes
4. Traffic policies
   1. The organization might have specific compliance requirements mandating that all traffic be mirrored to an additional service that can, for example, record the request details in a database for later replay
   2. Set up traffic policies using regional backend services
5. Traffic management components
   1. Internal HTTP(S) load balancers provide traffic management by leveraging regional URL maps and regional backend services resources
   2. Users can set up traffic steering and traffic actions by using regional URL maps
   3. Google Cloud resources that are associated with URL maps include route rule, rule match and rule actions
   4. Google Cloud resources that are associated with backend services include
      1. Locality load balancer policy
      2. Consistent hash load balancer settings
      3. Circuit breakers
      4. Outlier detection
6. Routing requests to backends
   1. In Internal HTTP(S) Load Balancing, the backend for traffic is determined using a two-phased approach
   2. The load balancer selects a backend service with backends
   3. The backends can be Compute Engine virtual machine (VM) instances in an unmanaged instance group, Compute Engine VMs in a managed instance group (MIG), or containers by means of a Google Kubernetes Engine (GKE) node in a network endpoint group (NEG)
   4. The load balancer chooses a backend service based on rules defined in a regional URL map
   5. The backend service selects a backend instance based on policies defined in a regional backend service
   6. For each URL map, choose to use simple host and path rules or advanced host, path, and route rules
   7. The two modes are mutually exclusively.
   8. Advanced host, path, and route rules provide additional configuration options compared to simple host and path rules
   9. Route rules have an associated priority value and are interpreted in priority order (rather than by using longest-path-matches-first semantics)
7. Host rules
   1. When a request reaches the load balancer, the request's host field is evaluated against the hostRules defined in the URL map
   2. Each host rule consists of a list of one or more hosts and a single path matcher (pathMatcher)
   3. If no hostRules are defined, the request is routed to the defaultService
8. Path matchers
   1. After a request matches a host rule, the load balancer evaluates the path matcher corresponding to the host
   2. A path matcher is made up of
      1. One or more path rules (pathRules) or route rules (routeRules)
      2. A default service (defaultService), which is the default backend service that is used when no other backend services match
9. Path rules
   1. Path rules (pathRules) specify one or more URL paths, such as / or /video
   2. Path rules are generally intended for the type of simple host and path-based routing
10. Route rules
    1. A route rule (routeRules) matches information in an incoming request and makes a routing decision based on the match
    2. Route rules can contain a variety of different match rules (matchRules) and a variety of different route actions (routeAction)
    3. A match rule evaluates the incoming request based on the HTTP(S) request's path, headers, and query parameters.
    4. Match rules support various types of matches (prefix match) as well as modifiers (case insensitivity)
    5. This enables users to send HTTP(S) requests to a set of backends based on the presence of a custom-defined HTTP header
    6. Match rules (matchRules) match one or more attributes of a request and take actions specified in the route rule
11. Traffic policies
    1. Traffic policies enable fine-tuned load balancing within an instance group or network endpoint group (NEG)
    2. Policies only take effect after a backend service has been selected by using regional URL map
    3. Traffic policies enable users to
       1. Control the load balancing algorithm among instances within the backend service
       2. Control the volume of connections to an upstream service
       3. Control the eviction of unhealthy hosts from a backend service