Cloud 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 address, and scale your resources up or down with intelligent autoscaling.

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.

GCP offers different types of load balancers that can be divided into two categories: global and regional.

The global load balancers are the HTTP(S), SSL proxy, and TCP proxy load balancers. These load balancers leverage the Google frontends, which are software-defined, distributed systems that sit in Google’s points of presence and are distributed globally. Therefore, you want to use a global load balancer 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.

The regional load balancers are the internal and network load balancers, and they distribute traffic to instances that are in a single GCP region. The internal load balancer uses Andromeda, which is GCP’s software-defined network virtualization stack, and the network load balancer uses Maglev, which is a large, distributed software system.

There’s also another internal load balancer for HTTP(S) traffic. This 6th load balancer is a proxy-based, regional Layer 7 load balancer that enables you to run and scale your services behind a private load balancing IP address that is accessible only in the load balancer’s region in your VPC network.

Choosing a load balancer

Now, in order to decide which load balancer best suits your implementation of GCP, consider the following aspects of Cloud Load Balancing: global versus regional load balancing, external versus internal load balancing, and the traffic type. If you need an external load balancing service, start on the top left of this flow chart.

First, choose the type of traffic that your load balancer must handle. If that is HTTP or HTTPS traffic, I recommend using the HTTP(S) load balancing service as a Layer 7 load balancer. Otherwise, use the TCP and UDP traffic paths of this flow chart to determine whether the SSL proxy, TCP proxy, or network load balancing service meets your needs.

If you need an internal load balancing service, you have the internal load balancing service available, and it supports both TCP and UDP traffic. There’s actually another internal load balancer for HTTP(S) traffic but it’s in beta as of this post. This 6th load balancer is for HTTP or HTTPS traffic and it’s regional, meaning for IPv4 clients.

You can use load balancers with managed instance groups and their autoscaling configurations

We will talk about managed instance groups and templates in our next post.

Thank you for taking your time to read this article, we hope it gave you an idea of what cloud load balancers are… for more information you can reach us on WhatsApp chat.