What's changed: Created Professional Cloud Network Engineer Chapter 3 (Domain 3 "Managed services": load balancing selection internal/external-regional/global-L7/L4, backend services/MIG/NEG/balancing mode/session affinity/health checks/URL maps/global access, GKE Gateway/Ingress, traffic splitting/mirroring/URL rewrites, Cloud CDN origins (MIG/GCS/Cloud Run/internet NEG)/cache invalidation, Cloud DNS public/private zones/split-horizon/geolocation-failover policies/DNSSEC/forwarding zones-server policies/DNS peering/cross-project binding/external-DNS).
3.1Load balancing
Understand load balancer selection (internal/external, regional/global, application/proxy/passthrough), backend services and autoscaling (NEGs/managed instance groups), balancing mode/session affinity/serving capacity/URL maps/health checks/global access, GKE load balancing (Gateway/Ingress controllers, NEGs), and Application Load Balancer traffic management (splitting/mirroring/URL rewrites).
With Cloud Load Balancing, the key is selecting the right type along requirement axes. Combine "external/internal," "global/regional," and "L7/L4" to pin the optimal choice.
3.1.1Load balancer selection axes
Selection has three axes: internal/external (internal vs public), regional/global (one region vs route global users to nearest), and Application (L7)/proxy/passthrough (L4). For HTTP(S) needing URL routing or WAF, choose the Application Load Balancer (L7; the global external ALB routes global users to the nearest); to pass TCP/UDP through, choose the passthrough Network LB; for a TCP proxy, the proxy Network LB. For internal microservices use the internal ALB / internal passthrough NLB. Map "public HTTP, global = global external ALB" and "internal L4 preserving source IP = internal passthrough NLB."
3.1.2Backends, health checks, and traffic management
Group backends under a backend service and register managed instance groups (MIG, autoscaling) or NEGs (network endpoint groups—container-native/serverless/internet). Set the balancing mode (utilization/RPS/connections), serving capacity, and, if needed, session affinity, and send traffic only to healthy backends via health checks. At L7, split by path/host with URL maps and allow cross-region internal reach with global access. On GKE, the GKE Gateway / Ingress controller auto-configures NEG-based LBs. On the Application LB, configure traffic splitting (weighted), traffic mirroring, and URL rewrites.
Common: requirement → LB type. E.g., "public HTTP, URL routing, global users" = global external Application LB; "pass TCP/UDP through, preserve source IP" = passthrough Network LB; "internal L7 between microservices" = internal Application LB; "weighted gradual rollout to a new version" = traffic splitting; "replicate prod traffic to validate" = traffic mirroring; "serverless/container backends" = NEG.
Watch the mix-ups: (1) Passthrough NLB preserves source IP, but proxy types (ALB/proxy NLB) do not (they pass it via X-Forwarded-For, etc.). (2) Allow the health-check source ranges (35.191.0.0/16, 130.211.0.0/22) in firewalls or all backends go unhealthy. (3) Global external ALB requires the Premium tier.
3.1.3Section summary
- Choose LB on 3 axes: internal/external, regional/global, L7/L4 (public HTTP global = global external ALB)
- Backends = MIG/NEG; health checks send to healthy only; L7 splits via URL maps
- Gradual rollout = traffic splitting; validation = traffic mirroring; GKE Gateway/Ingress auto-builds NEG LBs
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To serve public HTTPS to global users and route by URL path to microservices, which LB is best?
Q2. To pass TCP/UDP through without proxying and preserve the client source IP to backends, which LB?
Q3. To use serverless (Cloud Run) or containers as load balancer backends, which unit do you register?
Q4. To shift traffic to a new version 5%→25%→100% by weight, which Application LB feature?
Q5. All LB backends went unhealthy. Which network setting should you check first?