This document provides you with an overview of the different load balancing solutions that are available on the Google Cloud Platform.
Google Cloud Platform Load Balancing gives you the ability to distribute load-balanced compute resources in single or multiple regions, to meet your high availability requirements, to put your resources behind a single anycast IP and to scale your resources up or down with intelligent Autoscaling. Cloud Load Balancing is fully integrated with Cloud CDN for optimal content delivery.
Using Cloud Load Balancing, you can serve content as close as possible to your users, on a system that can respond to over 1 million queries per second. Cloud Load Balancing is a fully distributed, software defined, managed service. It is not instance or device based, so you do not need to manage a physical load balancing infrastructure.
Types of Cloud Load Balancing
The following table summarizes the characteristics of each Cloud load balancer, including whether the load balancer uses an internal or an external IP address, whether the load balancer is regional or global, and the supported traffic types.
| Internal or External | Load Balancer Type | Regional or Global | Supported Network Tiers | Proxy or Pass-Through |
Traffic Type |
|---|---|---|---|---|---|
| Internal | Internal TCP/UDP | Regional | Premium Tier | Pass-through | TCP or UDP |
| Internal HTTP(S) | Regional | Proxy | HTTP or HTTPS | ||
| External | Network TCP/UDP | Regional | Premium Tier Standard Tier |
Pass-through | TCP or UDP |
| TCP Proxy | Global in Premium Tier Effectively regional1 in Standard Tier |
Proxy | TCP | ||
| SSL Proxy | Proxy | SSL | |||
| HTTP(S) | Proxy | HTTP or HTTPS |
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 NEGs attached to the global backend service must be in the same region as the forwarding rule and IP address. Refer to Configuring Standard Tier for HTTP(S) LB and TCP/SSL Proxy.
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 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, and you only require IPv4 termination.
External versus internal load balancing
GCP's load balancers can be divided into external and internal load balancers. External load balancers distribute traffic coming from the internet to your GCP network. Internal load balancers distribute traffic within your GCP network.
The following diagram illustrates a common use case: how to use external and internal load balancing together. In the illustration, traffic from users in San Francisco, Iowa, and Singapore is directed to an external load balancer, which distributes that traffic to different regions in a GCP network. An internal load balancer then distributes traffic between the us-central-1a and us-central-1b zones.
External load balancing
Use external load balancing when you need to distribute traffic from the Internet to a Google 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 balancing
Use internal load balancing when you need to distribute traffic to instances within a Google Cloud VPC network.
Traffic type
The type of traffic you need your load balancer to handle is another factor in determining which load balancer to use.
- HTTP and HTTPS traffic can be handled by external HTTP(S) or Internal HTTP(S) Load Balancing.
- TCP traffic can be handled by TCP Proxy Load Balancing, Network Load Balancing, or Internal TCP/UDP Load Balancing.
- UDP traffic can be handled by Network Load Balancing or Internal TCP/UDP Load Balancing.
Backend region and network
The following table summarizes support for backends residing in different VPC networks. The table also provides information about multi-NIC load balancing support.
| Load Balancer Type | Backend Region and Network | Multi-NIC Notes |
|---|---|---|
| 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. | Using multiple load balancers, can load balance to multiple NICs on the same backend |
| Internal HTTP(S) 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. | The backend VM's nic0 must be in the same network
and region used by the forwarding rule.
|
| External HTTP(S), SSL proxy, TCP proxy load balancers | 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. | The load balancer only sends traffic to the first network interface
(nic0), whichever VPC network that
nic0 is in.
|
A closer look at Cloud load balancers
This section provides information on each type of GCP load balancer, including links to documentation.
HTTP(S) Load Balancing
HTTP(S) Load Balancing is implemented by Google Front Ends (GFEs). GFEs are distributed globally and operate together using Google's global network and control plane. In Premium Tier, GFEs offer cross-regional load balancing, directing traffic to the closest healthy backend that has capacity, and terminate HTTP(S) traffic as close as possible to your users.
SSL Proxy Load Balancing
SSL Proxy Load Balancing is implemented by Google Front Ends (GFEs). GFEs are distributed globally and operate together using Google's global network and control plane. In Premium Tier, they offer cross-regional load balancing, directing connections to the closest healthy backend that has capacity, and terminate SSL traffic as close as possible to your users.
SSL Proxy Load balancing is implemented on Google Front Ends (GFEs), distributed worldwide. If you choose the Premium Tier of Network Service Tiers, an SSL proxy load balancer is global. In Premium Tier, you can deploy backends in multiple regions, and the load balancer automatically directs user traffic to the closest region that has capacity. If you choose the Standard Tier, an SSL proxy load balancer can only direct traffic among backends in a single region.
TCP Proxy Load Balancing
TCP Proxy Load Balancing is implemented by Google Front Ends (GFEs). GFEs are distributed globally and operate together using Google's global network and control plane. In Premium Tier, they offer cross-regional load balancing, directing connections to the closest healthy backend that has capacity, and terminate SSL traffic as close as possible to your users.
TCP Proxy Load balancing is implemented on Google Front Ends (GFEs), distributed worldwide. If you choose the Premium Tier of Network Service Tiers, a TCP proxy load balancer is global. In Premium Tier, you can deploy backends in multiple regions, and the load balancer automatically directs user traffic to the closest region that has capacity. If you choose the Standard Tier, a TCP proxy load balancer can only direct traffic among backends in a single region.
Network TCP/UDP Load Balancing
Network Load Balancing enables you to load balance traffic on your systems based on incoming IP protocol data, including address, port, and protocol type. It is a regional, non-proxied load balancing system. Use Network Load Balancing for UDP traffic, and for TCP and SSL traffic on ports that are not supported by the SSL Proxy and TCP Proxy load balancers. A Network load balancer is a pass-through load balancer that does not proxy connections from clients.
Internal TCP/UDP Load Balancing
Internal TCP/UDP Load Balancing enables you to load balance TCP/UDP traffic behind a private load balancing IP address that is accessible only to your internal virtual machine instances. Use Internal TCP/UDP Load Balancing to configure an Internal Load Balancing IP address to act as the frontend to your private backend instances. You use only internal IP addresses for your load balanced service. Overall, your configuration becomes simpler.
Internal TCP/UDP Load Balancing supports regional managed instance groups, so that you can autoscale across a region, protecting your service from zonal failures.
Internal HTTP(S) Load Balancing
The internal HTTP(S) load balancer performs proxy-based load balancing of Layer 7 application data that you specify with URL maps. It uses a private IP address that acts as the frontend to your backend instances.
Cloud Load Balancing: Under the Hood
- Google Front Ends (GFEs) = Software-defined, distributed systems that are located in Google POPs and perform global load balancing in conjunction with other systems and control planes
- Andromeda = Google Cloud's software-defined network virtualization stack
- Maglev - Distributed systems for Network Load Balancing
What's next
See Choosing a load balancer and Load balancer features for more information on each type of load balancer.
