GCP HTTP(S) Load Balancer Setup: Step-by-Step Guide

What is a GCP HTTP(S) load balancer?

The GCP HTTP(S) Application Load Balancer is a global, Layer 7 load balancer. “Layer 7” means it understands HTTP — it can inspect the URL path, route different paths to different backends, and terminate TLS so your backend VMs never have to handle certificates themselves.

”Global” means Google distributes the load balancer across its worldwide network using Anycast routing. A single IP address is announced from Google’s edge locations around the world. A user in Tokyo and a user in London connect to the same IP, but Google routes each to the nearest healthy backend automatically.

This is the right load balancer for public web applications and APIs served from Compute Engine VMs. It is different from the internal load balancer, which handles private traffic inside your VPC between services, and different from the external TCP/UDP load balancer, which operates at Layer 4 without HTTP-level routing.

How it works in plain English

Here is what actually happens step by step when a request comes in:

1. A user’s browser looks up your domain and gets the global static IP address you reserved in GCP.
2. The browser connects to that IP on port 443 (HTTPS) or port 80 (HTTP).
3. A forwarding rule receives the connection and hands it to the appropriate proxy.
4. For HTTPS: the target HTTPS proxy terminates TLS using your SSL certificate. The encrypted connection ends here, at Google’s edge — not at your VM.
5. The proxy consults the URL map to decide which backend should handle this request.
6. The backend service checks which of its backends are currently healthy (using the health check results) and picks one.
7. The request is forwarded from the load balancer to the backend VM on port 80, entirely over Google’s internal network.
8. For HTTP on port 80: a separate forwarding rule catches it and returns a 301 redirect to HTTPS, before the request ever reaches your VMs.

The health check runs continuously in the background, probing each VM every few seconds. VMs that stop responding are pulled from rotation automatically and re-added once they recover.

What you are building

By the end of this guide you will have all of the following, wired together and working:

• Global static IP address. The permanent public IP your DNS record points at. Survives load balancer rebuilds.
• Managed instance group. The pool of backend VMs that serve your application traffic.
• Health check. The probe that decides which backends are healthy enough to receive requests.
• Backend service. The configuration layer that links the instance group and health check, and defines balancing behaviour.
• URL map. The routing rules that decide which backend service handles a given request path.
• Google-managed SSL certificate. Auto-provisioned and auto-renewed TLS for your domain.
• Target HTTPS proxy. The TLS termination point that binds the URL map and certificate together.
• HTTPS forwarding rule. Exposes port 443 on your global IP and routes traffic to the HTTPS proxy.
• HTTP redirect forwarding rule. Catches port 80 requests and returns a 301 to HTTPS.

When to use this setup

This is the right setup when you:

• Are serving a public web application or API from Compute Engine VMs
• Need a single public entry point with automatic HTTPS termination
• Want Google to handle SSL certificate provisioning and renewal
• Need health-based routing that automatically removes unhealthy VMs from rotation
• Want to distribute traffic across multiple VMs or across multiple zones
• May need path-based routing later, such as sending /api/* to one backend and /static/* to another without changing infrastructure

This is not the right setup if:

• You only need to load-balance traffic inside your VPC. Use an internal load balancer instead.
• You are using Cloud Run or App Engine. Those services have built-in HTTPS and do not need this setup.
• You need raw TCP or UDP load balancing without HTTP routing. Use the external TCP/UDP load balancer.
• You want the simplest possible public HTTPS endpoint for a prototype. Cloud Run with a custom domain is faster to configure.

Component overview and build order

Each component depends on the ones before it. You cannot create a forwarding rule before its proxy exists, and you cannot create the proxy before its URL map exists. Attempting to skip ahead produces resource-not-found errors. Follow this order:

1. Global static IP address. The public entry point. Everything else eventually references this IP.
2. VM instance group. The actual backends. Must exist before the backend service can reference them.
3. Health check. Defines how backends are probed. Must exist before the backend service is created.
4. Backend service. Links instance groups and health checks. Must exist before the URL map references it.
5. URL map. Defines routing rules. Must exist before the proxy references it.
6. SSL certificate. Required before the target HTTPS proxy can be created.
7. Target HTTPS proxy. Terminates TLS. References both the URL map and certificate. Must exist before the forwarding rule.
8. Forwarding rule. The final piece. Binds the IP address and port to the proxy.

The firewall rule for health checks is technically independent of this chain, but create it alongside the health check. If you wait, there will be a window where backends exist but appear unhealthy because the probes are being blocked.

Step 1: Reserve a global IP address

Reserve the IP address first so you have it ready for DNS configuration. This IP is permanent — it persists even if you tear down and rebuild every other part of the load balancer, which means you do not need to update DNS records if you recreate the setup later.

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

# Get the assigned IP — you will need this for your DNS A record
gcloud compute addresses describe web-lb-ip \
  --global \
  --format="get(address)"

Write down the IP address. The Google-managed SSL certificate you create later will not provision until your domain’s DNS A record points here. If you manage DNS in GCP, see Cloud DNS setup for how to create the A record.

Step 2: Create the backend instance group

The backend is a managed instance group (MIG), which is a pool of identical VMs that GCP maintains for you. The MIG automatically replaces any VM that fails health checks, and can scale up and down based on load. For production use, run at least two instances across zones for redundancy.

You first create an instance template that defines the VM configuration (machine type, OS, tags, startup script). Then you create the MIG from that template.

# Instance template — defines the VM configuration for every instance in the group
gcloud compute instance-templates create web-template \
  --machine-type=e2-medium \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --network=production-vpc \
  --subnet=web-subnet \
  --tags=web-server \
  --metadata=startup-script='#!/bin/bash
    apt-get update && apt-get install -y nginx
    echo "Hello from $(hostname)" > /var/www/html/index.html
    systemctl start nginx'

# Create the managed instance group from the template
gcloud compute instance-groups managed create web-mig \
  --template=web-template \
  --size=2 \
  --zone=us-central1-a

# Set named ports so the load balancer knows which port serves HTTP traffic
gcloud compute instance-groups set-named-ports web-mig \
  --named-ports=http:80 \
  --zone=us-central1-a

If you want the group to scale automatically with traffic, read autoscaling instance groups after completing this setup.

Step 3: Create a health check and firewall rule

The health check defines how the load balancer probes your backends to decide which ones are ready to receive traffic. GCP’s health checker infrastructure sends HTTP requests to each VM at the defined interval.

gcloud compute health-checks create http hc-http-80 \
  --port=80 \
  --request-path=/ \
  --check-interval=10s \
  --timeout=5s \
  --healthy-threshold=2 \
  --unhealthy-threshold=3

This probes port 80 every 10 seconds. A VM is considered healthy after 2 consecutive successful responses (2xx or 3xx HTTP status) and marked unhealthy after 3 consecutive failures. Once unhealthy, a VM is removed from rotation and re-added after 2 successful probes.

gcloud compute firewall-rules create allow-lb-health-checks \
  --network=production-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80 \
  --source-ranges=35.191.0.0/16,130.211.0.0/22 \
  --target-tags=web-server

The —target-tags=web-server restricts this rule to VMs carrying that network tag, which your instance template assigns via —tags=web-server. See firewall rules explained for how network tags and ingress rules interact.

Step 4: Create the backend service

The backend service is the central coordination object. It links your instance group to the health check, defines how traffic is distributed, and is what the URL map references when deciding where to send a request.

# Create the backend service
gcloud compute backend-services create web-backend-service \
  --protocol=HTTP \
  --port-name=http \
  --health-checks=hc-http-80 \
  --global

# Add the instance group as a backend
gcloud compute backend-services add-backend web-backend-service \
  --instance-group=web-mig \
  --instance-group-zone=us-central1-a \
  --balancing-mode=UTILISATION \
  --max-utilization=0.8 \
  --global

—protocol=HTTP means the load balancer communicates with backends using plain HTTP. This traffic travels entirely inside Google’s network between the load balancer and your VMs, so it is not exposed to the public internet even though it is unencrypted. If you need end-to-end encryption all the way to the VM, use —protocol=HTTPS — but your VMs must also be configured to serve HTTPS.

—port-name=http must exactly match the named port you set on the instance group in Step 2. This is how the backend service resolves port 80 from the name http.

Step 5: Create the URL map

The URL map is the routing configuration for your load balancer. It inspects incoming requests and decides which backend service should handle them. For a single-backend setup, you just define a default service that catches all requests:

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

This routes all requests to web-backend-service regardless of path. If you later want path-based routing — sending /api/* to a different backend or serving /static/* from Cloud Storage — you update the URL map with additional path matcher rules without touching any other component in the load balancer.

Step 6: Create the SSL certificate and HTTPS proxy

The target HTTPS proxy is where TLS termination happens. It needs an SSL certificate before it can be created. A Google-managed certificate is the easiest option — GCP handles provisioning and renewal automatically:

# Google-managed certificate — provisioned and renewed automatically by GCP
gcloud compute ssl-certificates create web-ssl-cert \
  --domains=example.com,www.example.com \
  --global

# Target HTTPS proxy — binds the URL map and certificate together
gcloud compute target-https-proxies create web-https-proxy \
  --url-map=web-url-map \
  --ssl-certificates=web-ssl-cert \
  --global

If you need more control — for example, using an existing certificate from a third-party CA, or managing certificates centrally across multiple load balancers — read SSL certificates in GCP for the alternatives.

Step 7: Create forwarding rules

Forwarding rules are the final piece. They bind a global IP address and port to a target proxy. You need two: one for HTTPS on port 443, and a second for HTTP on port 80 that redirects all traffic to HTTPS. Both use the same global IP.

# HTTPS forwarding rule — the main entry point for all HTTPS traffic
gcloud compute forwarding-rules create web-https-forwarding-rule \
  --address=web-lb-ip \
  --global \
  --target-https-proxy=web-https-proxy \
  --ports=443

# Create a redirect URL map that returns 301 HTTPS redirects for all HTTP requests
gcloud compute url-maps import http-redirect-map \
  --global \
  --source /dev/stdin << 'EOF'
defaultUrlRedirect:
  redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
  httpsRedirect: true
EOF

# Target HTTP proxy for the redirect — uses a plain HTTP proxy, not HTTPS
gcloud compute target-http-proxies create web-http-proxy \
  --url-map=http-redirect-map

# HTTP forwarding rule on port 80 — redirects all plain HTTP to HTTPS
gcloud compute forwarding-rules create web-http-forwarding-rule \
  --address=web-lb-ip \
  --global \
  --target-http-proxy=web-http-proxy \
  --ports=80

With both rules in place, a visitor who types your domain without https:// hits the port 80 rule, receives a 301 redirect, and their browser reconnects automatically on port 443 via the main rule. Without the port 80 rule, plain HTTP requests would get a connection refused error. Browsers with a cached HSTS entry would be fine, but anyone without one would not reach your site.

Verifying the setup

Run these checks once all components are created. Do not skip to DNS until backends are showing healthy.

# Backend health — wait until all instances show HEALTHY
gcloud compute backend-services get-health web-backend-service \
  --global

# Forwarding rules — confirm both port 80 and port 443 rules exist
gcloud compute forwarding-rules list --global

# SSL certificate state — should move from PROVISIONING to ACTIVE after DNS is set
gcloud compute ssl-certificates describe web-ssl-cert \
  --global \
  --format="get(managed.status, managed.domainStatus)"

# Confirm the global IP is reserved and in use
gcloud compute addresses describe web-lb-ip \
  --global \
  --format="get(address, status)"

What to look for:

• Backend health. Each instance should show HEALTHY. If any show UNHEALTHY, the health check firewall rule is the first thing to check. See load balancer backend unhealthy for a full diagnostic walkthrough.
• Forwarding rules. You should see two rules — one on port 443 pointing at the HTTPS proxy, one on port 80 pointing at the HTTP proxy.
• Certificate state. PROVISIONING is normal before DNS is pointed at the load balancer IP. It moves to ACTIVE after GCP validates the domain. If it stays stuck, check that the domain resolves correctly and that the port 80 forwarding rule exists.
• HTTP redirect. Once live, test with curl -I http://yourdomain.com and confirm a 301 response with a Location header pointing to https://.
• HTTPS. Test with curl -I https://yourdomain.com once the certificate is active and confirm a 200 response from your backend.

If you need to debug connectivity at a lower level — VPC routes, firewall logs, packet loss — see troubleshooting network issues in GCP.

HTTP(S) load balancer vs internal load balancer

The two load balancers you are most likely to reach for are the external HTTP(S) Application Load Balancer (what this page covers) and the internal load balancer. They serve fundamentally different purposes:

If the service you are load-balancing only needs to be reachable from other services inside your VPC — for example, an internal API called by other VMs — the internal load balancer is simpler, cheaper, and keeps all traffic private. Use the external HTTP(S) load balancer when you need to accept traffic from the public internet.

For a full comparison of all GCP load balancer types, see external load balancers and global load balancing.