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:
- External versus internal load balancing
- Global versus regional load balancing
- Premium versus Standard Network Service Tiers
- Proxy versus pass-through load balancing
- Traffic type
- DDoS protections
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.
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|
|External||Regional||Premium or Standard||Pass-through||TCP, UDP, ESP, or ICMP (Preview)||External TCP/UDP Network load balancer|
|Standard only||Proxy||HTTP or HTTPS||Regional external HTTP(S) load balancer (Preview)|
|Global in Premium Tier
Effectively regional1 in Standard Tier
|Premium or Standard||Proxy||TCP||External TCP proxy load balancer|
|SSL||External SSL proxy load balancer|
|HTTP or HTTPS||External HTTP(S) load balancer|
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 type||Backend region and network|
||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.|
||In Premium Tier: Backends can be in any region and any
In Standard Tier: Backends must be in the same region as the forwarding rule, but can be in any VPC network.
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 external HTTP(S) load balancer and SSL proxy load balancer 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 Balancing instead, and 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.
Use Premium Tier for high performance and low latency. If you do not specify a network tier, your load balancer defaults to using Premium Tier.
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. The external HTTP(S) load balancer is implemented using Google Front End (GFE) proxies worldwide. The regional external HTTP(S) load balancer and internal HTTP(S) load balancers are managed services based on the open source Envoy proxy.
Pass-through 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 balancer and internal TCP/UDP load balancers are pass-through load balancers.
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:
- External HTTP(S) Load Balancing
- Regional external HTTP(S) load balancer
- Internal HTTP(S) Load Balancing
- TCP traffic:
- TCP Proxy Load Balancing
- External TCP/UDP Network Load Balancing
- Internal TCP/UDP Load Balancing
- SSL traffic:
- SSL Proxy Load Balancing
- UDP traffic:
- External TCP/UDP Network Load Balancing
- Internal TCP/UDP Load Balancing
- ESP or ICMP traffic:
- Network Load Balancing (Preview)
DDoS protections for external load balancers
Google Cloud provides different DDos protections, depending on the load balancer type.
Proxy-based external load balancers
All of the Google Cloud proxy-based external load balancers automatically inherit DDoS protection from Google Front Ends (GFEs), which are part of Google's production infrastructure.
In addition to the automatic DDoS protection provided by the GFEs, you can configure Google Cloud Armor for external HTTP(S) load balancers.
Pass-through external load balancers
The only pass-through external load balancer is the network load balancer. These load balancers are implemented using the same Google routing infrastructure used to implement external IP addresses for Compute Engine VMs. For inbound traffic to a network load balancer, Google Cloud limits incoming packets per VM. For more information, see Ingress to external IP address destinations.
- To select the appropriate load balancer based on your application needs, see Load balancer features.