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 GCP network.
GCP external load balancing offers the following:
- HTTP or HTTPS traffic: global HTTP(S) Load Balancing
- TCP traffic with SSL offload: global SSL Proxy Load Balancing
- TCP traffic without SSL offload: global TCP Proxy Load Balancing
- UDP traffic: regional Network TCP/UDP Load Balancing
- IPv4 or IPv6 clients
- Global or regional load balancing
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 GCP network.
GCP Internal TCP/UDP Load Balancing offers the following:
- TCP or UDP traffic
- RFC 1918 load balancing
- Client IP address is preserved
- Health checks
- Autoscaling without prewarming
- Session affinity
- Regional load balancing
GCP Internal HTTP(S) Load Balancing (Beta) offers the following:
- HTTP(S) traffic
- RFC 1918 load balancing
- Health checks
- Autoscaling without prewarming
- Session affinity
- Regional load balancing
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 Network Load Balancing or Internal TCP/UDP Load Balancing.
- UDP traffic can be handled by Network Load Balancing or Internal TCP/UDP Load Balancing.
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 provides the following benefits:
- Supports HTTP traffic on TCP ports 80 or 8080.
- Supports HTTPS traffic on TCP port 443.
- Efficiently handles traffic bursts without pre-warming.
- Supports instance group backends, including autoscaling instance groups, and Network Endpoint Groups backends.
- Supports Cloud Storage bucket backends.
- Routes requests based on host name and path routing rules using URL maps.
- Supports utilization and rate-based (RPS) balancing.
- Supports cookie-based and client IP-based session affinity.
- Supports connection draining.
- Offers monitoring and logging.
When you use the Premium Tier of Network Service Tiers, HTTP(S) Load Balancing offers additional benefits:
- Balances requests among backends in multiple regions by directing requests to the region closest to the user. If that region is at capacity, the load balancer uses a waterfall-by-region overflow model to deliver requests to the next closest region.
- Uses a single Anycast IPv4 or IPv6 load balancer address so that you can use a single DNS record, worldwide.
- Supports Cloud CDN.
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.
More information
For more information on HTTP(S) Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
- HTTP(S) Load Balancing Concepts
- HTTP(S) Load Balancing Logging and Monitoring
- URL Map Concepts
- GFE locations
SSL Proxy Load Balancing
SSL Proxy Load Balancing provides the following benefits:
- Supports TCP traffic that needs SSL (TLS) offload.
- Provides centralized certificate management.
- Supports end-to-end encryption when you configure the associated backend service to use the SSL protocol.
- Supports TCP traffic on ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222.
- Efficiently handles traffic bursts without pre-warming.
- Supports instance group backends, including autoscaling instance groups, and Network Endpoint Group backends.
- Supports utilization-based and connection-based balancing.
- Supports client IP-based session affinity.
- Supports connection draining.
- Offers monitoring and logging.
When you use the Premium Tier of Network Service Tiers, SSL Proxy Load Balancing offers additional benefits:
- Balances requests among backends in multiple regions by directing connections to the region closest to the user. If that region is at capacity, the load balancer uses a waterfall-by-region overflow model to deliver connections to the next closest region.
- Uses a single Anycast IPv4 or IPv6 load balancer address so that you can use a single DNS record, worldwide.
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.
More information
For more information on SSL Proxy Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
- SSL Proxy for Google Cloud Load Balancing Concepts
- TCP/SSL Proxy Logging and Monitoring
- GFE locations
TCP Proxy Load Balancing
TCP Proxy Load Balancing provides the following benefits:
- Supports TCP traffic, including SSL (TLS) without SSL termination. When used to balance SSL (TLS) connections, it does not decrypt SSL (TLS).
- Supports TCP traffic on ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222.
- Efficiently handles traffic bursts without pre-warming.
- Supports instance group backends, including autoscaling instance groups, and Network Endpoint Group backends.
- Supports utilization-based and connection-based balancing.
- Supports client IP-based session affinity.
- Supports connection draining.
- Offers monitoring and logging.
When you use the Premium Tier of Network Service Tiers, TCP Proxy Load Balancing offers additional benefits:
- Balances requests among backends in multiple regions by directing connections to the region closest to the user. If that region is at capacity, the load balancer uses a waterfall-by-region overflow model to deliver connections to the next closest region.
- Uses a single Anycast IPv4 or IPv6 load balancer address so that you can use a single DNS record, worldwide.
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), distrubuted 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.
More information
For more information on TCP Proxy Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
- TCP Proxy for Google Cloud Load Balancing Concepts
- TCP/SSL Proxy Logging and Monitoring
- GFE locations
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.
Network Load Balancing provides the following characteristics and benefits:
- Supports regional load balancing.
- Reachable via an external IPv4 address.
- Supports TCP and UDP traffic.
- Supports terminating SSL on backends using TCP pass-through.
- Preserves client IP addresses.
- Supports IPv4 clients.
- Requires legacy HTTP health checks.
More information
For more information on Network TCP/UDP Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
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 TCP/UDP Load Balancing offers the following benefits:
- Supports TCP/UDP traffic.
- Reachable via an internal RFC 1918 IP address.
- Offers Andromeda-based load balancing.
- Supports TCP, SSL(TLS), HTTP, or HTTPS health checks.
- Supports connection draining.
- Supports clients connected via Cloud VPN and Cloud Interconnect.
- Supports session affinity.
- Supports autoscaling for your backends without pre-warming.
- Preserves client IP addresses.
- Works with auto-mode VPC networks, custom mode VPC networks, and legacy networks.
- Performs regional load balancing.
More information
For more information on Internal TCP/UDP Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
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.
Internal HTTP(S) Load Balancing offers the following benefits:
- HTTP(S) traffic
- RFC 1918 load balancing
- Client IP address is preserved
- Health checks
- Autoscaling without prewarming
- Session affinity
- Regional load balancing
More information
For more information on Internal HTTP(S) Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
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
