A load balancer is a system composed of multiple interacting components. There isn't a single API resource that represents a load balancer. Instead, multiple components work together to distribute incoming traffic across multiple backends.
The following diagram shows the core components of an Application Load Balancer, a proxy Network Load Balancer, and a passthrough Network Load Balancer.
Application load balancer
Proxy network load balancer
Passthrough network load balancer
This section provides a high-level overview of the key components of a load balancer, starting from the point where traffic reaches the load balancer to the stage where it is routed to the backend resource. For a deeper understanding of each load balancer component, refer to the page linked in each section.
Forwarding rule
A forwarding rule specifies an IP address, an IP protocol, and one or more ports on which the load balancer accepts traffic. The forwarding rule and its attached IP address represent the frontend of a Google Cloud load balancer.
For more information, see Forwarding rules overview.
Target proxy
Target proxies terminate incoming connections from clients and create new connections from the load balancer to the backends.
The first connection originates from the client and is terminated at the target proxy of the load balancer.
The second connection starts at the target proxy and ends at the backend instance, which handles the client request.
The first connection is terminated either in a Google Front End (GFE) or in a specially designated subnet known as the proxy-only subnet, which is reserved exclusively for Envoy proxies. To know whether a load balancer is GFE-based or Envoy-based, see Underlying technologies of Google Cloud load balancers.
Target proxies are used only by proxy-based load balancers such as Application Load Balancers and proxy Network Load Balancers. For these types of load balancers, responses from the backend instances are sent back to the target proxy rather than directly to the client.
For more information, see Target proxies.
Proxy-only subnet
A proxy-only subnet provides a pool of IP addresses that are reserved exclusively for Envoy proxies used by Google Cloud load balancers. The proxies terminate incoming connections and then create new connections to the backend.
For more information, see Proxy-only subnets for Envoy-based load balancers
SSL certificates
Also known as Transport Layer Security (TLS) certificates, SSL certificates facilitate secure communication between clients and load balancers. Proxy-based load balancers whose forwarding rules reference a target HTTPS proxy or a target SSL proxy require a private key and SSL certificate as part of the load balancer's target proxy configuration.
For more information, see SSL certificates.
URL map
Upon terminating the connection, the target HTTP(S) proxy uses the URL map to decide where to route the new request (the second connection as stated in the Target proxy section). The URL map routes the request to either the backend service or the backend bucket. URL maps are only used by Application Load Balancers. As Application Load Balancers operate at Layer 7 of the OSI model, they can make routing decisions based on HTTP attributes, such as domain name, request path, and query parameters.
For more information, see URL maps.
Backend service
A backend service defines how your load balancer distributes traffic. The backend service configuration contains a set of values, such as the protocol used to connect to backends, various distribution and session settings, health checks, and timeouts.
These settings provide fine-grained control over how your load balancer behaves and let you direct traffic to the correct backends, which can be either VM instance groups or network endpoint groups (NEGs).
For more information, see Backend services overview.
Backend bucket
If your workload serves static content using the HTTP(S) protocol, you can use a Cloud Storage bucket to store static content, and then use a backend bucket to route requests to it.
Health checks
When you configure a load balancer's backend service, you need to specify one or more health checks for its backends. A health check, as the name suggests, determines whether the backend instances of the load balancer are healthy. This determination is based on the ability of the backend to respond to incoming traffic. The traffic that a backend needs to respond to depends on the type of the load balancer. You can create health checks using both Layer 7 and Layer 4 protocols to monitor load balanced instances.
Firewall rules
For health checks to work, you must create ingress allow firewall rules that allow health check probes to reach your backends.
Load balancers based on Google Front Ends require an ingress allow firewall rule
that permits traffic from the CIDRs of Google Front End to connect to your
backends. Load balancers based on the open source Envoy proxy require an ingress
allow firewall rule that permits traffic from the proxy-only subnet to reach
the backend instances.
For more information, see Firewall rules.
Backends
Backends are the final destination of load-balanced traffic.
Different load balancers support different types of backends. When you add a backend to the backend service, you specify a balancing mode. This mode evaluates the backend's capacity to handle new requests and determines how traffic is distributed among the backends.
For more information, see Backends.
What's next
- To help you determine which Google Cloud load balancer best meets your needs, see Choose a load balancer.
- To see a comparative overview of the load-balancing features offered by Cloud Load Balancing, see Load balancer feature comparison.