Why Cloud Load Balancing Is Different in GCP
Google Cloud's load balancers are not virtual machines you provision and scale yourself; they are fully managed, software-defined services built on the same global network infrastructure that runs Google Search and YouTube, meaning a single global external load balancer can front backends in multiple regions using one anycast IP address with no pre-warming required for most traffic ramps. This is a fundamental difference from traditional load balancer appliances, which are typically regional, need capacity planning, and often require a 'warm-up' request to AWS or on-prem support teams before a big traffic spike.
Cricket analogy: This is like a franchise having access to the entire national talent scouting network instantly, rather than relying on one regional scout who needs weeks of notice to cover a new city.
Global External vs Regional vs Internal Load Balancers
GCP offers several load balancer types chosen along two axes: scope (global vs regional) and traffic source (external internet-facing vs internal VPC-only). The Global external Application Load Balancer, built on the Envoy-based proxy, is the right choice for internet-facing HTTP(S) applications that need a single anycast IP routing users to the closest healthy backend across regions, with Cloud CDN and Cloud Armor integration. Regional external and internal load balancers, by contrast, are scoped to one region, suit use cases like an internal microservice mesh or a regionally compliant application, and some internal-only variants operate at Layer 4 for TCP/UDP rather than Layer 7 for HTTP.
Cricket analogy: This is like choosing between a national selection panel picking the best XI from anywhere in the country versus a state association only selecting players who are registered within that one state.
Health Checks and Backend Services
A GCP load balancer routes traffic through a backend service, which groups instance groups or NEGs (Network Endpoint Groups) and applies a health check to continuously probe each backend on a configurable interval, timeout, and unhealthy threshold; only backends currently passing the health check receive traffic. Backend services also define balancing mode, such as distributing traffic based on CPU utilization or requests per second, and support session affinity settings like client-IP-based affinity for stateful applications that need a user's requests to consistently land on the same backend instance.
Cricket analogy: This is like a fitness test before every match determining which players are match-fit to be selected, with an injured player automatically excluded from the XI until they pass a fresh fitness check.
# Create a health check for an HTTP backend service
gcloud compute health-checks create http web-health-check \
--port=80 \
--request-path=/healthz \
--check-interval=10s \
--timeout=5s \
--unhealthy-threshold=3 \
--healthy-threshold=2
# Create a backend service and attach the health check plus a managed instance group
gcloud compute backend-services create web-backend-service \
--protocol=HTTP \
--health-checks=web-health-check \
--global
gcloud compute backend-services add-backend web-backend-service \
--instance-group=web-mig-us-central1 \
--instance-group-region=us-central1 \
--globalThe Global external Application Load Balancer supports URL maps that route different paths, like /api/* versus /images/*, to entirely different backend services, enabling a single anycast IP and a single SSL certificate to front a microservices architecture without exposing multiple public endpoints.
Health checks and firewall rules are independent: even with a correctly configured health check, backends will be marked unhealthy if you haven't created a firewall rule allowing ingress traffic from Google's health-check IP ranges (35.191.0.0/16 and 130.211.0.0/22). This is one of the most common reasons a newly deployed load balancer reports all backends as unhealthy.
- GCP load balancers are fully managed and built on Google's global network, unlike traditional regional appliances that require capacity planning.
- The Global external Application Load Balancer fronts internet-facing HTTP(S) apps with one anycast IP across regions and integrates with Cloud CDN and Cloud Armor.
- Regional and internal load balancers are scoped to one region and can operate at Layer 4 (TCP/UDP) or Layer 7 (HTTP).
- Backend services group instance groups or NEGs and apply health checks that determine which backends receive traffic.
- Balancing modes like CPU utilization or requests-per-second, plus session affinity, control how traffic is distributed among healthy backends.
- URL maps let a single load balancer route different paths to different backend services.
- Firewall rules must explicitly allow Google's health-check IP ranges, or all backends will be marked unhealthy even if the app itself is fine.
Practice what you learned
1. What is a key advantage of GCP's Global external Application Load Balancer over a traditional regional appliance?
2. What determines whether a backend instance currently receives traffic from a load balancer?
3. What is a common reason a newly deployed GCP load balancer reports all backends as unhealthy despite the application working fine?
4. What does a URL map allow a Global external Application Load Balancer to do?
5. Which load balancer scope would be most appropriate for an internal microservice that should only be reachable from within a single region's VPC?
Was this page helpful?
You May Also Like
VPC Networks in GCP
Understand how Google Cloud's Virtual Private Cloud works as a global, software-defined network spanning regional subnets, and how VPC Peering and Shared VPC connect and centralize networks across projects.
Cloud CDN Basics
Learn how Cloud CDN caches content at Google's global edge locations by attaching to a load balancer's backend, how cache keys and cache modes control what gets cached, and how invalidation and signed URLs work.
Cloud DNS Basics
Understand how Google Cloud DNS serves authoritative public and private zones from a global anycast network, the core record types you'll configure, and how DNSSEC and delegation establish trust.