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
Cloud load balancers can be divided up as follows:
- Global versus regional load balancing
- External versus internal load balancing
- Traffic type
The sections that follow describe these different types of load balancers.
Global versus regional load balancing
Use global load balancing when your users and instances are globally distributed, 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 users and instances are concentrated in one region and you only require IPv4 termination.
Global load balancing requires that you use the Premium Tier of Network Service Tiers. For regional load balancing, you can use Standard Tier.
Global Load Balancing
Google global load balancing is implemented entirely in software, done by Google Front Ends (GFEs). The GFEs are distributed globally and load balance traffic in sync with each other by working with Google’s other software-defined systems and global control plane. Your traffic is directed to a single anycast IP address. GFEs terminate your user traffic as close as possible to your users and direct load balanced traffic to the closest healthy backend that has capacity.
- HTTPS, HTTP, or TCP/SSL
- Single anycast IP address
- Instances globally distributed
- Health checks
- IP address and cookie-based affinity
- IPv6 and IPv4 client termination
- Connection draining
- Autoscaling
- Monitoring and logging
- Load balancing for cloud storage
- Cross-region overflow and failover
- Requires Premium Tier of Network Service Tiers
Regional Load Balancing
Google regional load balancing is implemented entirely in software. Your instances are in a single GCP region and traffic is distributed to instances within a single region. Use network TCP/UDP Load Balancing to load balance external traffic. Use internal TCP/UDP Load Balancing to load balance internal traffic.
- Internal TCP/UDP Load Balancing
- UDP or TCP/SSL traffic
- Instances in one region
- Single IP address per region
- Health checks
- Session affinity
- IPv4 only
- Autoscaling
- Standard Tier of Network Service Tiers
The following illustration shows regional load balancing.
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 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
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 require global, external load balancing.
- TCP traffic can be handled by global, external load balancing; external, regional load balancing; or internal, regional load balancing.
- UDP traffic can be handled by external regional load balancing or internal regional 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:
- Global load balancing: Your applications are available to your customers at a single global IP address, which simplifies your DNS setup. HTTP(S) Load Balancing balances HTTP and HTTPS traffic across multiple backend instances and across multiple regions.
- HTTP or HTTPS traffic
- IPv4 or IPv6 clients
- HTTP requests are load balanced on port 80 or 8080.
- HTTPS requests are load balanced on port 443.
- Autoscaling: HTTP(S) Load Balancing is scalable, requires no pre-warming, and enables content-based and cross-region load balancing.
- URL maps direct requests based on rules: You can configure URL maps that route some URLs to one set of instances and route other URLs to other instances. Requests are generally routed to the instance group that is closest to the user. If the closest instance group does not have sufficient capacity, the request is sent to the next closest instance group that does have capacity.
Global load balancing requires that you use the Premium Tier of Network Service Tiers. For regional load balancing, you can use Standard Tier.
More information
For more information on HTTP(S) Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
SSL Proxy Load Balancing
Google Cloud SSL Proxy Load Balancing terminates user SSL (TLS) connections at the load balancing layer, then forwards the connections across your instances using SSL or TCP. Use Cloud SSL Proxy Load Balancing for non-HTTP(S) traffic. SSL Proxy Load Balancing allows you to enable encryption between your clients and the load balancing layer. You can also enable SSL between the load balancing layer and your backends.
SSL proxy is a global load balancing service. You can deploy your instances in multiple regions, and the load balancer automatically directs user traffic to the closest region that has capacity.
SSL Proxy Load Balancing provides the following benefits:
- Global load balancing
- External
- For TCP traffic with SSL offload (non-HTTPS encrypted traffic)
- Enables you to configure end-to-end encryption by configuring backend services to accept traffic over SSL
- Intelligent routing
- IPv4 or IPv6 clients
- SSL offload with SSL Proxy Load Balancing
- Centralized certificate management
- Requests are load balanced over ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222
More information
For more information on SSL Proxy Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
TCP Proxy Load Balancing
Google Cloud TCP Proxy Load Balancing enables you to use a single IP address for all users. GCP TCP Proxy Load Balancing is a global load balancing service. It automatically routes traffic to the instances that are closest to the user. Use TCP Proxy Load Balancing for non-HTTP traffic.
TCP Proxy Load Balancing enables you to terminate your customers’ TCP sessions at the load balancing layer, then forward the traffic to your virtual machine instances using TCP or SSL. You can deploy your instances in multiple regions, and the load balancer automatically directs user traffic to the closest region that has capacity. If the closest region does not have sufficient capacity, the request is sent to the closest region that does have capacity.
TCP Proxy Load Balancing offers the following benefits:
- Global load balancing
- External
- For TCP traffic without SSL offload (non-HTTP unencrypted traffic)
- For SSL traffic, but packets are not decrypted before forwarding
- Does not preserve client IPs
- IPv4 or IPv6 clients
- Intelligent routing
- Requests are balanced over ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 5222
More information
For more information on TCP Proxy Load Balancing, see the following documents:
How-to Guides
Conceptual Guides
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 benefits:
- Regional load balancing
- External
- For SSL, TCP, or UDP traffic
- Supports load balancing SSL and TCP traffic on ports not supported by SSL Proxy and TCP Proxy Load Balancing
- Preserves client IPs
- IPv4 clients
- 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 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 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 Load Balancing works with regional managed instance groups, so you can autoscale across a region, protecting your service from zonal failures.
Internal TCP/UDP Load Balancing offers the following benefits:
- TCP/UDP traffic
- RFC 1918 IP addresses
- Andromeda-based
- TCP, SSL(TLS), HTTP, or HTTPS health checks
- Connection draining
- Support for clients across VPN
- Session affinity
- Autoscaling for your backends without pre-warming
- Client IP preservation
- Works with auto-mode VPC networks, custom mode VPC networks, and legacy networks
More information
For more information on Internal TCP/UDP 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
