Choose a load balancer

This document helps you determine which Google Cloud load balancer best meets your needs. To see an overview of all the Cloud Load Balancing products available, see Cloud Load Balancing overview.

Load balancing aspects

To decide which load balancer best suits your implementation of Google Cloud, consider the following aspects of Cloud Load Balancing:

Load balancer decision tree

After you determine your network architecture requirements, use the following decision tree to determine which load balancers are available for your client, protocol, and network configuration.

Decision tree for choosing a load balancer (click to enlarge)
Decision tree for choosing a load balancer (click to enlarge)

Summary of load balancer types

The following table summarizes the load balancing products available for each combination of features.

Internal or external IP address Regional or global Premium or Standard network tier Proxy or pass-through Traffic type Load balancer type
Internal Regional Premium only Pass-through TCP or UDP Internal TCP/UDP load balancer
Proxy HTTP or HTTPS Internal HTTP(S) load balancer
Proxy TCP Internal regional TCP proxy load balancer
External Global Premium only Proxy HTTP or HTTPS Global external HTTP(S) load balancer
Global in Premium Tier

Effectively regional1 in Standard Tier
Premium or Standard Proxy HTTP or HTTPS Global external HTTP(S) load balancer (classic)
SSL External SSL proxy load balancer
TCP External TCP proxy load balancer
Regional Premium or Standard Pass-through TCP, UDP, ESP, GRE, ICMP, and ICMPv6 External TCP/UDP network load balancer
Standard only Proxy HTTP or HTTPS Regional external HTTP(S) load balancer
Standard only Proxy TCP External regional TCP proxy load balancer
1Effectively regional means that, while the backend service is global, if you choose Standard Tier, the external forwarding rule and external IP address must be regional, and the backend instance groups or network endpoint groups (NEGs) attached to the global backend service must be in the same region as the forwarding rule and IP address. For more information, see Configuring Standard Tier for external HTTP(S) load balancers, external TCP proxy load balancers, and external SSL proxy load balancers.

External versus internal load balancing

Google Cloud load balancers can be divided into external and internal load balancers:

  • External load balancers distribute traffic coming from the internet to your Google Cloud Virtual Private Cloud (VPC) network. Global load balancing requires that you use the Premium Tier of Network Service Tiers. For regional load balancing, you can use Standard Tier.

  • Internal load balancers distribute traffic to instances inside of Google Cloud.

Global versus regional load balancing

Use global load balancing when your backends are distributed across multiple regions, your users need access to the same applications and content, and you want to provide access by using a single anycast IP address. Global load balancing can also provide IPv6 termination.

Use regional load balancing when your backends are in one region, you only require IPv4 termination, or when you have jurisdictional compliance requirements for traffic to stay in a particular region.

Backend region and network

The following table summarizes support for backends residing in different VPC networks.

Load balancer Backend region and network
Global external HTTP(S) load balancer Backends can be in any region and any VPC network.
  • Global external HTTP(S) load balancer (classic)
  • External SSL proxy load balancer
  • External TCP proxy load balancer
In Premium Tier: Backends can be in any region and any VPC network.

In Standard Tier: Backends must be in the same region as the forwarding rule, but can be in any VPC network.
  • External TCP/UDP network load balancer
  • Internal TCP/UDP load balancer
All backends must be in the same VPC network and the same region as the backend service. The backend service must also be in the same region and VPC network as the forwarding rule.
  • Internal HTTP(S) load balancer
  • Internal regional TCP proxy load balancer
  • Regional external HTTP(S) load balancer
  • External regional TCP proxy load balancer

Backends are typically located in the same VPC network and region as the backend service. However, this isn't the case if your backends are located on-premises or in other cloud environments.

The backend service must also be in the same region and VPC network as the forwarding rule.

Geographic control over where TLS is terminated

Workloads that require regionalized resources for compliance reasons mandate that certain resources must be kept in a specific region, or require traffic to be terminated in a given region.

The global external HTTP(S) load balancers and external SSL proxy load balancers terminate Transport Layer Security (TLS) in locations that are distributed globally, so as to minimize latency between clients and the load balancer. If you require geographic control over where TLS is terminated, you should use either the regional external HTTP(S) load balancer, or the network load balancer where you terminate TLS on backends that are located in regions appropriate to your needs.

Load balancer resilience to outages

Load balancers are a critical component of most highly available applications. Google Cloud offers both regional and global load balancers. In either case, it is important to understand that the resilience of your overall application depends not just on which load balancer you choose, but also on the redundancy of your backend services.

The following table summarizes load balancer resilience based on the load balancer's distribution or scope.

Load balancer scope Architecture Resilient to zonal outage Resilient to regional outage
Global Each load balancer is distributed across all regions
Regional Each load balancer is distributed across multiple zones in the region An outage in a given region affects the regional load balancers in that region

Premium versus Standard Network Service Tiers

Network Service Tiers lets you optimize connectivity between systems on the internet and your Google Cloud instances. Premium Tier delivers traffic on Google's premium backbone, while Standard Tier uses regular ISP networks.

If the IP address of the load balancer is in the Premium Tier, the traffic traverses Google's high‑quality global backbone with the intent that packets enter and exit a Google edge peering point as close as possible to the client. Use Premium Tier for high performance and low latency. If you do not specify a network tier, your load balancer defaults to using the Premium Tier.

If the IP address of the load balancer is in the Standard Tier, the traffic enters and exits the Google network at a peering point closest to the Google Cloud region where the load balancer is configured. Use Standard Tier as a low-cost alternative for applications that don't have strict requirements for latency or performance. As noted in this table, not all load balancers can be deployed in the Standard Tier.

Because you choose a tier at the resource level—such as the external IP address for a load balancer or VM—you can use Standard Tier for some resources and Premium Tier for others. You can use this decision tree in the Network Service Tiers documentation to help you make your decision.

Proxy versus pass-through load balancing

Proxy load balancers terminate incoming client connections and open new connections from the load balancer to the backends. Regional external HTTP(S) load balancers, internal HTTP(S) load balancers, internal regional TCP proxy load balancers, and external regional TCP proxy load balancers are managed services based on the open source Envoy proxy.

The global external HTTP(S) load balancers, external TCP proxy load balancers, and external SSL proxy load balancers terminate client connections by using Google Front End (GFE) proxies worldwide. Additionally, the global external HTTP(S) load balancer uses Envoy proxies to implement features such as weighted traffic splitting, outlier detection, and traffic mirroring.

Proxy-based load balancers send connections to the backends from different GFE/Envoy IP addresses. If you're using a form of authentication that relies on keeping track of the IP address that opened the first connection, and expects that same IP address to open the second connection, you might not want to use a proxy load balancer. Proxy load balancers do not preserve client IP addresses by default. This type of authentication is more compatible with the passthrough load balancers described in the following section. For proxy load balancers such as the internal and external HTTP(S) load balancers, we recommend that you use IAP as your authentication method instead.

Passthrough load balancers do not terminate client connections. Instead, load-balanced packets are received by backend VMs with the packet's source, destination, and, if applicable, port information unchanged. Connections are then terminated by the backend VMs. Responses from the backend VMs go directly to the clients, not back through the load balancer. The term for this is direct server return. Use a pass-through load balancer when you need to preserve the client packet information. The external TCP/UDP network load balancers and internal TCP/UDP load balancers are pass-through load balancers.

Traffic type

The type of traffic that you need your load balancer to handle is another factor in determining which load balancer to use:

  • HTTP and HTTPS traffic:
    • Global external HTTP(S) load balancer
    • Global external HTTP(S) load balancer (classic)
    • Regional external HTTP(S) load balancer
    • Internal HTTP(S) load balancer
  • SSL traffic:
    • External SSL proxy load balancer
  • TCP traffic:
    • External TCP proxy load balancer
    • External TCP/UDP network load balancer
    • Internal TCP/UDP load balancer
    • Internal regional TCP proxy load balancer
    • External regional TCP proxy load balancer
  • UDP traffic:
    • External TCP/UDP network load balancer
    • Internal TCP/UDP load balancer
  • ESP or ICMP traffic:
    • Network load balancer

DDoS protections for external load balancers

Google Cloud Armor provides both always-on and user-configurable DDoS protections, depending on the load balancer type or mode of operation.

Load balancer type or mode Always-on DDoS protection Google Cloud Armor security policies
Global external HTTP(S) load balancer
Global external HTTP(S) load balancer (classic)
Regional external HTTP(S) load balancer
External SSL proxy load balancer
External TCP proxy load balancer
External TCP/UDP network load balancer

You can also configure advanced network DDoS protection for an external TCP/UDP network load balancer, protocol forwarding, or VMs with public IP addresses. For more information about advanced network DDoS protection, see Configure advanced network DDoS protection.

What's next