GCP Load Balancers - Multi Cloud Architect, Security Specialist

This post is a brain dump of some of the nitty gritty details of GCP Load Balancers.(Also read SSL Load Balancing in GCP)

Proxy or Non Proxy Load Balancer?

GCP's documentation around load balancers is confusing. They try to divide the choices up by 'External / Internal', Type of Protocol, Type of SSL Termination, Proxy or Non Proxy,..And it gets confusing in a hurry.

The easiest way I have found to start out is to divide them based on Proxy and Non proxy Load Balancers.

What exactly is a Proxy Load Balancer?

The IP address of the client is hidden in a proxy load balancer. There is no way for the backend servers to know the IP of the client. The proxy's own IP address serves as the ' client IP ' as far as the backend is concerned

And Non Proxy is simply the opposite - the IP address of the client is known to the backend servers. This allows them to return traffic to a specific IP address.

SSL Proxy versus TCP Proxy

Now that this part is clear, we have two types of Proxy Load Balancers in GCP - SSL Proxy and TCP Proxy. In brief, TCP Proxy DOES NOT support encrypted traffic (no SSL). So, if encrypted traffic (from the client to the load balancer) is a requirement, you will need the SSL Proxy.

You may ask - Why will anyone ever opt for TCP Proxy?

Well -if the traffic is ALL internal - say your backend and your Front End is all internal, you can get away without SSL encrypted traffic.

Firewall Rules in Google Cloud Load Balancers

FW rules in GCP, unlike in AWS, cannot be applied to Load Balancers. In AWS, the ELB can be (has to be) assigned a Security Group.

In GCP Load Balancers, by default , default egress - 80 and 443 - are both allowed.

External Partners and GCP Load Balancers?

To use any of these load balancers with external partners, you would use the cloud armor service. This will allow you to apply firewall rules for external access.

In effect, GCP has three different places where FW rules can be defined and applied. The obvious ones are Compute engine and App Engine. The non obvious one is Cloud Armor. And there are also default FW rules, like those that apply to GCP load balancers, which one has no control over.

Health Check FW Rules required by GCP Load Balancers

DDoS Prevention in Google's Load Balancers

More on Proxy based external load balancers

All of the Google Cloud proxy-based external load balancers automatically inherit DDoS protection from Google Front Ends (GFEs), which are part of Google's production infrastructure.

In addition to the automatic DDoS protection provided by the GFEs, you can configure Google Cloud Armor for external HTTP(S) load balancers.

Session affinity - HTTPs load balancers only

Session affinity provides a best-effort attempt to send requests from a particular client to the same backend for as long as the backend is healthy and has the capacity, according to the configured balancing mode.

Google Cloud HTTP(S) Load Balancing offers three types of session affinity:

NONE. Session affinity is not set for the load balancer.
Client IP affinity sends requests from the same client IP address to the same backend.
Generated cookie affinity sets a client cookie when the first request is made, and then sends requests with that cookie to the same backend.

When you use session affinity, we recommend the RATE balancing mode rather than UTILIZATION. Session affinity works best if you set the balancing mode to requests per second (RPS).

Configuring a firewall rule for Health Check needed by GCP Load Balancers

In this example, you create the fw-allow-health-check firewall rule. This is an ingress rule that allows traffic from the Google Cloud health checking systems (130.211.0.0/22 and 35.191.0.0/16). This example uses the target tag allow-health-check to identify the VMs.

Console gcloud

In the Google Cloud Console, go to the Firewall page.Go to the Firewall page
Click Create firewall rule to create the second firewall rule.
For Name, enter fw-allow-health-check.
Under Network, select Default.
Under Targets, select Specified target tags.
Populate the Target tags field with allow-health-check.
Set Source filter to IP ranges.
Set Source IP ranges to 130.211.0.0/22 and 35.191.0.0/16.
Under Protocols and ports, select Specified protocols and ports.
Select the tcp checkbox, and then type 80 for the port numbers.
Click Create.

HTTPS Load Balancer

When a client sends a request to the load balancer's external IPv4 or IPv6 address, the load balancer evaluates the request according to the URL map and sends the request to the correct service.

On each backend service, you can optionally enable Cloud CDN and Google Cloud Armor.

If you are using Google Cloud Armor with Cloud CDN, security policies are enforced only for requests for dynamic content, cache misses, or other requests that are destined for the CDN origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the CDN origin server.

On backend buckets, Cloud CDN is supported, but not Google Cloud Armor.

Three-tier web services

You can use external HTTP(S) Load Balancing to support traditional three-tier web services. The following example shows how you can use three types of Google Cloud load balancers to scale three tiers. At each tier, the load balancer type depends on your traffic type:

Web tier: Traffic enters from the internet and is load balanced by using an external HTTP(S) load balancer.
Application tier: The application tier is scaled by using a regional internal HTTP(S) load balancer.
Database tier: The database tier is scaled by using an internal TCP/UDP load balancer.

One common use case is load balancing traffic among services. In the following example, external IPv4 and IPv6 clients can request video, API, and image content by using the same base URL, with the paths /api, /video, and /images.

The external HTTP(S) load balancer%

Need a GCP Consultant?

Set up a 1 on 1 appointment with Anuj to assist with your GCP cloud journey.