In the old days of on-premises data centers, a load balancer was a big metal appliance sitting in a rack—an F5 BIG-IP or a Citrix NetScaler. You plugged cables into it, configured VIPs, and prayed for firmware updates. In Google Cloud, there is no box. The load balancer is a distributed software capability that lives at the edge of Google’s network, spanning every single Point of Presence on the planet. It is not a device you deploy—it is a feature you activate.
The flagship product is the Global External HTTP(S) Load Balancer, often called GCLB. When you create one, Google gives you a single IPv4 address, and that address works everywhere on Earth simultaneously. A user in Mumbai connects to Google’s Mumbai PoP. A user in London connects to the London PoP. Both are seamlessly routed to the nearest healthy backend over Google’s private backbone. This “Anycast” magic is the defining feature of Google Cloud load balancing, and it is only available on Premium Network Tier.
The Anatomy of a Load Balancer
The PCNE exam requires you to know each component in the “path of a packet.” There are five layers, and they always appear in this order:
1. Forwarding Rule
The “Front Door.” It holds the external IP address and listens on a specific port (80, 443). This is the entry point where traffic arrives.
2. Target Proxy
The “Receptionist.” It terminates the SSL/TLS connection (holds the certificate) and inspects the HTTP headers. For HTTPS traffic, this is a Target HTTPS Proxy.
3. URL Map
The “Router.” It reads the request path (/images vs /api vs /video) and directs traffic to the appropriate backend. This is where you implement path-based routing, host-based routing, and traffic splitting for canary deployments.
4. Backend Service
The “Manager.” It knows the health of every backend instance, handles session affinity (sticky sessions), and manages capacity scaling. Health checks are attached here.
5. NEG or MIG (The Workers)
The actual compute doing the work. Could be VMs in a Managed Instance Group (MIG), Pods in a GKE cluster (via a Zonal NEG), or even a Cloud Run service (via a Serverless NEG).
Network Endpoint Groups (NEGs): The Modern Backend
The term “NEG” often confuses people. It is just a generic container for endpoints, and there are three types:
- Zonal NEG: Points to VM or Pod IP addresses. This is how GKE clusters integrate with the load balancer—traffic goes directly to the Pod, bypassing kube-proxy.
- Serverless NEG: Points to Cloud Run, App Engine, or Cloud Functions. This is how you put a global load balancer in front of a serverless app.
- Internet NEG: Points to an endpoint outside Google Cloud (e.g., an on-premises server or an AWS instance). Yes, you can use Google’s LB to front your on-prem data center.
SSL Certificates: Managed vs. Self-Managed
Google-Managed Certificates
The easy button. Google provisions and renews the certificates for you automatically using Let’s Encrypt. You just specify the domain name.
Self-Managed Certificates
You upload your own PEM files. Use this if you need Extended Validation (EV) certificates, internal CA requirements, or wildcard certs that Google-managed does not support.
Cloud Armor: The Bouncer at the Door
Because the L7 load balancer terminates the connection (it is a reverse proxy), you can attach Cloud Armor security policies to the Backend Service. This gives you:
- WAF Rules: Block SQL injection, XSS, and other OWASP Top 10 attacks.
- Rate Limiting: “Block any IP sending more than 1000 requests per minute.”
- Geo-Blocking: “Deny all traffic from Country X.”
- Named IP Lists: Use Google’s curated lists of known-good IPs (like CDN providers) for whitelisting.
The Internal HTTP(S) Load Balancer
Not all load balancers face the internet. The Internal L7 LB is a regional resource that uses the Envoy proxy model internally.
- Use Case: Microservice-to-microservice communication. Service A calls Service B with rich HTTP routing features (path-based, header-based, retries, traffic weights), but strictly over private internal IPs.
- If the exam says “Global” and “Single Anycast IP,” it is always the External HTTP(S) LB. If it says “Internal” and “Regional,” it is the Internal HTTP(S) LB.
Putting it Together: A Pro-Engineer View
Imagine you are running a global e-commerce platform. Your web frontend is served by Cloud Run in three regions. Your product API runs on GKE. Your legacy catalog service still lives on-premises. You create a single Global External HTTPS LB with three backend services: a Serverless NEG for Cloud Run, a Zonal NEG for GKE, and an Internet NEG for your on-prem catalog. You attach a URL Map that routes /web to Cloud Run, /api to GKE, and /catalog to on-prem. You enable Cloud Armor with rate limiting and SQL injection protection. One Anycast IP. Three different backends. One seamless experience for every user on the planet.
