A load balancer distributes user traffic across multiple instances of your applications. By spreading the load, load balancing reduces the risk that your applications experience performance issues.
About Cloud Load Balancing
Cloud Load Balancing is a fully distributed, software-defined managed service. It isn't hardware-based, so you don't need to manage a physical load-balancing infrastructure.
Cloud Load Balancing is built on the same frontend-serving infrastructure that powers Google. It supports 1 million+ queries per second with consistent high performance and low latency. By using Cloud Load Balancing, you can serve content as close as possible to your users. Traffic enters Cloud Load Balancing through 80+ distinct global load-balancing locations and stays on Google's fast private network backbone for most of its journey. If it's needed, traffic is handed off to the public internet as close as possible to your users.
Google Cloud offers the following load-balancing features:
Single anycast IP address. With Cloud Load Balancing, a single anycast IP address is the frontend for all of your backend instances in regions around the world. It provides cross-region load balancing, including automatic multi-region failover, which moves traffic to failover backends if your primary backends become unhealthy. Cloud Load Balancing reacts instantaneously to changes in users, traffic, network, backend health, and other related conditions.
Software-defined load balancing. Cloud Load Balancing is a fully distributed, software-defined, managed service for all your traffic. It is not an instance-based or device-based solution, so you won't be locked into a physical load-balancing infrastructure or face the HA, scale, and management challenges inherent in instance-based load balancers.
Seamless autoscaling. Cloud Load Balancing can scale as your users and traffic grow, including easily handling huge, unexpected, and instantaneous spikes by diverting traffic to other regions in the world that can take traffic. Autoscaling does not require pre-warming: you can scale from zero to full traffic in a matter of seconds.
Layer 4 and Layer 7 load balancing. Use Layer 4-based load balancing to direct traffic based on data from network and transport layer protocols such as TCP, UDP, ESP, GRE, ICMP, and ICMPv6 . Use Layer 7-based load balancing to add request routing decisions based on attributes, such as the HTTP header and the uniform resource identifier.
External and internal load balancing. You can use external load balancing when your users reach your applications from the internet and internal load balancing when your clients are inside of Google Cloud.
Global and regional load balancing. Distribute your load-balanced resources in single or multiple regions, to terminate connections close to your users, and to meet your high availability requirements.
Advanced feature support. Cloud Load Balancing supports features such as IPv6 global load balancing, source-IP based traffic steering, weighted load balancing, WebSockets, user-defined request headers, and protocol forwarding for private VIPs.
It also includes the following integrations:
- Integration with Cloud CDN for cached content delivery. Cloud CDN is supported with the global external HTTP(S) load balancer and the global external HTTP(S) load balancer (classic).
- Integration with Google Cloud Armor to protect your infrastructure from distributed denial-of-service (DDoS) attacks and other targeted application attacks. Always-on DDoS protection is available for the global external HTTP(S) load balancer, the global external HTTP(S) load balancer (classic), the external TCP proxy load balancer, the external SSL proxy load balancer, and the network load balancer. Additonally, Google Cloud Armor supports advanced network DDoS protection only for network load balancers. For more information, see Configure advanced network DDoS protection.
Summary of Google Cloud load balancers
The following diagram summarizes the available Cloud Load Balancing products.
The following table provides more specific information about each load balancer.
| Load balancer type | Traffic type | IP address | Global or regional | Network service tier | Load-balancing scheme † | Load balancer frontend ports | Proxy or pass-through |
|---|---|---|---|---|---|---|---|
| Global external HTTP(S) load balancer | HTTP or HTTPS | IPv4, IPv6 | Global | Premium only | EXTERNAL_MANAGED | HTTP on 80 or 8080; HTTPS on 443 | Proxy |
| Global external HTTP(S) load balancer (classic) | HTTP or HTTPS | IPv4, IPv6 (IPv6 in Premium Tier only) | Global in Premium Tier. Regional in Standard Tier. | Premium or Standard | EXTERNAL | HTTP on 80 or 8080; HTTPS on 443 | Proxy |
| Regional external HTTP(S) load balancer | HTTP or HTTPS | IPv4 only | Regional | Standard only | EXTERNAL_MANAGED | HTTP on 80 or 8080; HTTPS on 443 | Proxy |
| Internal HTTP(S) load balancer | HTTP or HTTPS | IPv4 only | Regional | Premium only | INTERNAL_MANAGED | HTTP on 80 or 8080; HTTPS on 443 | Proxy |
| External SSL proxy load balancer | TCP with SSL offload | IPv4, IPv6 (IPv6 in Premium Tier only) | Global in Premium Tier. Regional in Standard Tier. | Premium or Standard | EXTERNAL | Exactly one port from 1-65535 | Proxy |
| External TCP proxy load balancer | TCP without SSL offload | IPv4, IPv6 (IPv6 in Premium Tier only) | Global in Premium Tier. Regional in Standard Tier. | Premium or Standard | EXTERNAL | Exactly one port from 1-65535 | Proxy |
| Internal regional TCP proxy load balancer | TCP without SSL offload | IPv4 only | Regional | Premium | INTERNAL_MANAGED | Any | Proxy |
| External regional TCP proxy load balancer | TCP without SSL offload | IPv4 only | Regional | Standard | EXTERNAL_MANAGED | Any | Proxy |
| External TCP/UDP network load balancer | TCP, UDP, ESP, GRE, ICMP, and ICMPv6 | IPv4, IPv6 (IPv6 in Premium Tier only) | Regional | Premium or Standard | EXTERNAL | Any | Pass-through |
| Internal TCP/UDP load balancer | TCP or UDP | IPv4, IPv6 | Regional backends, regional frontends (global access supported) | Premium only | INTERNAL | Any | Pass-through |
† The load-balancing scheme is an attribute on the forwarding rule and
the backend service of a
load balancer and indicates whether the load balancer can be used for internal
or external traffic. The possible values are EXTERNAL,
EXTERNAL_MANAGED, INTERNAL, and
INTERNAL_MANAGED.
The term *_MANAGED in the load-balancing scheme indicates that
the load balancer is implemented as a managed service on Google Front Ends
(GFEs) or as a managed service on the open source Envoy proxy. In a
load-balancing scheme that is *_MANAGED, requests are routed either to
the GFE or to the Envoy proxy.
Choosing a load balancer
To determine which Cloud Load Balancing product to use, you must first determine what traffic type your load balancers must handle and whether you need global or regional load balancing, external or internal load balancing, and proxy or pass-through load balancing. For details on each of these decisions, see Choosing a load balancer.
Then use this decision tree to determine which load balancers are available for your client, protocol, and network configuration.
The underlying technology of Google Cloud load balancers
This section provides more information about each type of Google Cloud load balancer, including links to overview documentation for a deeper understanding.
- Google Front Ends (GFEs) are software-defined, distributed systems that are located in Google points of presence (PoPs) and perform global load balancing in conjunction with other systems and control planes.
- Andromeda is Google Cloud's software-defined network virtualization stack.
- Maglev is a distributed system for network load balancers.
- Envoy proxy is an open source edge and service proxy, designed for cloud-native applications.
| Load balancer | Underlying technology |
|---|---|
| Global external HTTP(S) load balancer | GFEs, Envoy |
| Global external HTTP(S) load balancer (classic) | GFEs |
| Regional external HTTP(S) load balancer | Envoy, Maglev |
| Internal HTTP(S) load balancer | Andromeda, Envoy |
| External TCP proxy load balancer | GFEs |
| External SSL proxy load balancer | GFEs |
| Internal regional TCP proxy load balancer | Andromeda, Envoy |
| External regional TCP proxy load balancer | Envoy |
| External TCP/UDP network load balancer | Maglev |
| Internal TCP/UDP load balancer | Andromeda |
Internal HTTP(S) load balancer
Internal HTTP(S) load balancers are built on the Andromeda network virtualization stack and is a managed service based on the open source Envoy proxy. This load balancer provides internal proxy-based load balancing of Layer 7 application data. You specify how traffic is routed with URL maps. The load balancer uses an internal IP address that acts as the frontend to your backends.
External HTTP(S) load balancer
External HTTP(S) load balancer implementation differs based on the load balancer mode.
The global external HTTP(S) load balancer is implemented on GFEs. GFEs are distributed globally and operate together using Google's global network and control plane. GFEs offer multi-region load balancing, directing traffic to the closest healthy backend that has capacity and terminating HTTP(S) traffic as close as possible to your users. Additionally, the global external HTTP(S) load balancer uses the open source Envoy proxy to enable advanced traffic management capabilities. The global external HTTP(S) load balancer is only supported in Premium Tier.
The global external HTTP(S) load balancer (classic) is also implemented on GFEs. It is a global load balancer in Premium Tier but can be configured to be effectively regional in Standard Tier. Effectively regional means that, while the backend service is always global, when you choose Standard Tier, the external forwarding rule and external IP address must be regional, and the backends attached to the global backend service must be in the same region as the forwarding rule and IP address.
The regional external HTTP(S) load balancer is a managed service based on the open source Envoy proxy, which enables advanced traffic management capabilities. This is a regional HTTP(S) load balancer that is only supported in Standard Tier.
Internal TCP/UDP load balancer
Internal TCP/UDP load balancers are built on the Andromeda network virtualization stack. An internal TCP/UDP load balancer enables you to load balance TCP/UDP traffic behind an internal load-balancing IP address that is accessible only to your internal virtual machine (VM) instances. By using an internal TCP/UDP load balancer, an internal load-balancing IP address is configured to act as the frontend to your internal backend instances. You use only internal IP addresses for your load balanced service. Overall, your configuration becomes simpler.
Internal TCP/UDP load balancers support regional managed instance groups so that you can autoscale across a region, protecting your service from zonal failures.
External TCP/UDP network load balancer
Network load balancers are built on Maglev. This load balancer enables you to load balance traffic on your systems based on incoming IP protocol data, including address, protocol, and port (optional). It is a regional, non-proxied load-balancing system. That is, a network load balancer is a pass-through load balancer that does not proxy connections from clients.
Backend service-based network load balancers support TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic.
Target pool-based network load balancers support only TCP or UDP traffic.
External SSL proxy load balancer
External SSL proxy load balancers are implemented on GFEs that are distributed globally. If you choose the Premium Tier of Network Service Tiers, an external 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 external SSL proxy load balancer can only direct traffic among backends in a single region.
External TCP proxy load balancer
External TCP proxy load balancers are implemented on GFEs that are distributed globally. If you choose the Premium Tier of Network Service Tiers, an external 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, an external TCP proxy load balancer can only direct traffic among backends in a single region.
Internal regional TCP proxy load balancer
The internal regional TCP proxy load balancer is an Envoy proxy-based regional Layer 4 load balancer that enables you to run and scale your TCP service traffic behind an internal IP address that is accessible only to clients in the same VPC network or clients connected to your VPC network.
The load balancer distributes TCP traffic to backends hosted on Google Cloud, on-premises, or other cloud environments. This load balancer is accessible only in the chosen region of your VPC network on an internal IP address.
External regional TCP proxy load balancer
The external regional TCP proxy load balancer is an Envoy proxy-based regional Layer 4 load balancer that enables you to run and scale your TCP service traffic behind an external IP address. This load balancer is configured as a regional load balancing service that uses the Standard Tier.
The load balancer distributes TCP traffic to backends in a single region. These backends can be hosted on Google Cloud, on-premises, or in other cloud environments.
Interfaces
You can configure and update your load balancers by using the following interfaces:
The Google Cloud CLI: A command-line tool included in the Google Cloud CLI; the documentation calls on this tool frequently to accomplish tasks. For a complete overview of the tool, see the gcloud CLI guide. You can find commands related to load balancing in the
gcloud computecommand group.You can also get detailed help for any
gcloudcommand by using the--helpflag:gcloud compute http-health-checks create --helpThe Google Cloud console: Load-balancing tasks can be accomplished by using the Google Cloud console.
The REST API: All load-balancing tasks can be accomplished by using the Cloud Load Balancing API. The API reference docs describe the resources and methods available to you.
Terraform: Provision, update, and delete the Google Cloud load-balancing infrastructure by using an open source infrastructure-as-code tool such as Terraform.
What's next
- To help you determine which Google Cloud load balancer best meets your needs, see Choosing a load balancer.
- To see a comparative overview of the load-balancing features offered by Cloud Load Balancing, see Load balancer feature comparison.