Loadbalancing in GCP

Loadbalancing Process

At a high-level, traffic processed via:

• Step 1: User types in www.website.com/service in their browser, The DNS returns the frontend IP of the loadbalancer for www.website.com
• Step 2: Layer-7 (Application LB): The Forwarding Rule sends traffic to a Target Proxy. The LB terminates the SSL/TLS connection here. The LB must hold the SSL certificate. Layer-4 (Passthrough Network LB): The Forwarding Rule sends the packet directly to the Backend (Target Pool/Backend Service). There is no “Proxy” in the middle. The LB does not look at the data; it just forwards the TCP/UDP packet. Layer-4 (Proxy Network LB): A hybrid. It acts like L4 (TCP) but uses a Proxy to terminate SSL at the LB level before sending it to the VM.
• Step 3: Layer-7: The Target Proxy decrypts the traffic and reads the /service path. It injects the X-Forwarded-For header so the VM knows the user’s real IP (since the LB “broke” the original connection). Layer-4 (Passthrough): The LB cannot see the /service path and cannot inject headers. The VM sees the original packet exactly as the user sent it, including the User’s IP address.
• Step 4.1: Layer-7: The LB establishes a brand new connection to the VM. The traffic between the LB and the VM can be plain HTTP (even if the user used HTTPS) because the “scary” public internet part is already over. Layer-4 (Passthrough): The LB simply “steers” the original connection to the VM. If the user sent encrypted traffic (Port 443), the VM receives that encrypted traffic.
  • Crucial Logic: If the VM holds no certificate, it cannot decrypt the traffic, and the request dies here.

---

Differences between Layer-4 and Layer-7 Loadbalancer

Feature	Layer 4 (Network LB)	Layer 7 (Application LB)
OSI Layer	Transport (TCP/UDP)	Application (HTTP/HTTPS/HTTP2)
Visibility	Sees IP addresses and Ports.	Sees URLs, Paths, Cookies, and Headers.
SSL/TLS	No termination. Pass-through only.	Terminates SSL. Handles certs and decryption.
Routing Logic	“Packets in, packets out.”	“Request in, logic applied, request out.”
Speed	Faster (requires very little compute).	Slightly slower (due to decryption/inspection).
Client IP	VM sees the actual Client IP naturally.	VM sees the LB’s IP (needs X-Forwarded-For).

---

Steps to create a Loadbalancer (Layer-4) in GCP

Section 1: Creating the Workloads

1. Create a VM Instance with the running apache2 service. This will be the compute that is running your workload

  gcloud compute instances create www3 \
    --zone=us-central1-b  \
    --tags=network-lb-tag \
    --machine-type=e2-small \
    --image-family=debian-11 \
    --image-project=debian-cloud \
    --metadata=startup-script='#!/bin/bash
      apt-get update
      apt-get install apache2 -y
      service apache2 restart
      echo "<h3>Web Server: www3</h3>" | tee /var/www/html/index.html'

1. Create a firewall rule to allow external (http: 80, https: 443) traffic to VM instances.

Please see:

• GCP list of allowed VM traffic, link.
• GCP firewall best practices: link
• GCP blocked/limited traffic: here

gcloud compute firewall-rules create www-firewall-network-lb --target-tags network-lb-tag --allow tcp:80

Section 2: Configure load balancing service

A load balancing service

1. Create static IP for lb

gcloud compute addresses create network-lb-ip-1 --region us-central1

1. Add http healthcheck resource

gcloud compute http-health-checks create basic-check

Section 3: Create a target pool and Load balancer (Layer-4)

1. A target pool is a group of backend instances that receive incoming traffic from external passthrough NLBs. All backend instances of a target pool must reside in the same Google Cloud region.

# Create the target pool
gcloud compute target-pools create www-pool --region us-central1 --http-health-check basic-check

# Add the instances created in section 1 to target pool
gcloud compute target-pools add-instances www-pool --instances www3

1. Create forwarding rule

gcloud compute forwarding-rules create www-rule \
    --region us-central1 \
    --ports 80 \
    --address network-lb-ip-1 \
    --target-pool www-pool

---

Create Application Load balancer (Layer-7)

Application Load Balancing is implemented on Google Front End (GFE). GFEs are distributed globally and operate together using Google’s global network and control plane. You can configure URL rules to route some URLs to one set of instances and route other URLs to other instances. Requests are always routed to the instance group that is closest to the user, if that group has enough capacity and is appropriate for the request. If the closest group does not have enough capacity, the request is sent to the closest group that does have capacity.

1. Create an instance-templates with configs for the individual backends

gcloud compute instance-templates create lb-backend-template \
   --region=us-central1 \
   --network=default \
   --subnet=default \
   --tags=allow-health-check \
   --machine-type=e2-medium \
   --image-family=debian-11 \
   --image-project=debian-cloud \
   --metadata=startup-script='#!/bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

1. Create managed instance group based on the template

Managed instance groups (MIGs) let you operate apps on multiple identical VMs. You can make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating.

gcloud compute instance-groups managed create lb-backend-group \
   --template=lb-backend-template --size=2 --zone=us-central1-b

1. Create firewall rule to allow health checks

gcloud compute firewall-rules create fw-allow-health-check \
  --network=default \
  --action=allow \
  --direction=ingress \
  --source-ranges=130.211.0.0/22,35.191.0.0/16 \
  --target-tags=allow-health-check \
  --rules=tcp:80

1. Create static IP address

gcloud compute addresses create lb-ipv4-1 \
  --ip-version=IPV4 \
  --global

1. Create health check for load balancer

gcloud compute health-checks create http http-basic-check --port 80

1. Create backend service

This is a logical grouping

gcloud compute backend-services create web-backend-service \
  --protocol=HTTP \
  --port-name=http \
  --health-checks=http-basic-check \
  --global

1. Add instance group to backend service

gcloud compute backend-services add-backend web-backend-service \
  --instance-group=lb-backend-group \
  --instance-group-zone=us-central1-b \
  --global

1. Create URL map to route incoming traffic to backend service.

URL map in GCP are very similar to ingress or http-route resource in k8’’s

• Requests for https://example.com/video go to one backend service.
• Requests for https://example.com/audio go to a different backend service.

gcloud compute url-maps create web-map-http \
    --default-service web-backend-service

1. Create target-proxy to route request to URL map

Target proxies terminate incoming connections from clients and create new connections from the load balancer to the backends.

gcloud compute target-http-proxies create http-lb-proxy \
    --url-map web-map-http

1. Create global forwarding rule to route incoming traffic to the target-proxy

gcloud compute forwarding-rules create http-content-rule \
   --address=lb-ipv4-1\
   --global \
   --target-http-proxy=http-lb-proxy \
   --ports=80