Load balancing and Cloud CDN

The load balancer family

Google Cloud names load balancers by traffic type. The older names (HTTP(S) Load Balancing, SSL Proxy, TCP Proxy, Network LB) still show up in questions.

Quick decision flow

1. Traffic from the internet or from inside the VPC? External or internal.
2. HTTP(S) and you need URL routing, CDN, WAF, redirects, header changes? Application LB.
3. Other TCP that needs TLS offload or global anycast? Proxy Network LB.
4. Need the original client IP at the backend, UDP, ESP or non-standard protocols, or all ports? Passthrough Network LB.
5. Users in many regions with one IP? Global external Application or Proxy NLB in Premium Tier. One region or compliance? Regional.
6. Internal across regions? Cross-region internal Application LB (or regional internal with global access to one region).

Traps:

• Passthrough LBs are regional only; there is no global passthrough. For a global TCP service use the global external proxy Network LB.
• With proxy LBs the backend sees the proxy’s IP; use X-Forwarded-For (Application LB) or PROXY protocol (proxy NLB) to learn the client IP.
• Passthrough LBs have no proxy, so there is no TLS termination at the LB, and backends must have the VIP configured (guest OS handles it) — Google’s agent takes care of that on its images.
• An internal LB is not reachable from the internet and by default is reachable only from the same region and VPC. Internal passthrough and regional internal Application LBs can enable global access; hybrid clients over VPN and Interconnect reach them in the same region unless global access is on.

Proxy-only subnets and firewalls

• Envoy-based LBs (regional external, regional internal, cross-region internal) require a proxy-only subnet per region and VPC (purpose REGIONAL_MANAGED_PROXY or GLOBAL_MANAGED_PROXY). Minimum size /26, /23 recommended. The proxies source traffic from these addresses, so firewall rules must allow the proxy-only range to backends.
• Health check probes come from 130.211.0.0/22 and 35.191.0.0/16 (plus a few more for legacy external and proxy cases). Firewall rules must allow them or all backends look unhealthy. Internal passthrough LBs also use these probe ranges. This is the #1 cause of “backends are unhealthy” after setting up an LB.
• Global external LBs reach backends from Google front ends in the same probe ranges. Backends with only internal IPs are fine.

Backends

A backend service (or backend bucket) holds the backends, health check, balancing mode, session affinity, timeouts and security policy. Backends are groups of endpoints.

Balancing modes and capacity

• UTILIZATION (CPU based, for instance groups), RATE (requests per second per instance or endpoint) and CONNECTION (concurrent connections). Custom metrics balancing is also available for Envoy-based LBs.
• Mode choices depend on the LB and backend type: Application LB with MIGs uses utilization or rate; proxy NLBs use connection; NEGs use rate or connection.
• Capacity scaler (0 to 1) scales a backend’s share; setting it to 0 drains a backend without removing it (a common way to stop new traffic while preserving existing sessions). Max utilization, max rate and max connections cap a backend before spillover to others (including cross-region spillover on global LBs).
• A global LB sends users to the closest backend with capacity and spills over to the next closest when the first is full or unhealthy.
• Autoscaling MIG with LB: the autoscaler can use HTTP load balancing serving capacity (target utilization of the LB’s backend capacity), CPU, or monitoring metrics; keep autoscaling policy and balancing mode consistent, otherwise the LB sees a full backend while the autoscaler sees idle CPU.
• Locality load balancing policy within a backend: round robin, least request, ring hash, Maglev, random, weighted. Choose consistent hashing (ring hash or Maglev) for session affinity on Envoy LBs.

Session affinity

Affinity is best-effort: it breaks when backends are added, removed, become unhealthy, or exceed capacity.

Health checks

• Protocols: TCP, SSL, HTTP, HTTPS, HTTP/2, gRPC. Global and regional resources exist (use regional for regional LBs).
• Defaults: check interval 5 s, timeout 5 s, healthy threshold 2, unhealthy threshold 2. A successful HTTP check is a 200 response from the path you configure (use a dedicated lightweight path).
• Use the same port the service serves traffic on or specify a port; for NEGs you can use the serving port of each endpoint.
• Failure modes: health check unhealthy because the firewall blocks the probe ranges, the wrong port/path, or the app listening only on loopback.
• If all backends are unhealthy, global LBs in “fail open” mode may send traffic anyway; Cloud DNS or LB failover policies are separate concepts.

Timeouts and draining

• Backend service timeout defaults to 30 s for Application LB (increase for long uploads, WebSockets use the same value as a connection timeout).
• Connection draining timeout: 0 to 3600 s (300 s is the usual default); the LB stops sending new requests to a backend being removed or unhealthy and lets in-flight ones finish. Use it with MIG rolling updates.
• To drain and redirect traffic (maintenance or a region migration): set the capacity scaler to 0, or remove the backend while draining is configured, or use weighted backend services in the URL map to shift traffic to another backend gradually (for example to a standby region). Verify with LB monitoring metrics (request count per backend).

Application LB traffic management (URL maps)

A URL map routes requests: host rules and path matchers map to backend services or buckets. Route rules (advanced mode, Envoy-based LBs) add header and query parameter matching and actions.

Other Application LB settings: SSL certificates (Google-managed, self-managed, or Certificate Manager for wildcard and many certs), SSL policy (minimum TLS version, cipher profile), mTLS with Trust Config, HTTP/3, IAP for user-identity access, Cloud Armor attached to backend services, Cloud CDN on a backend. A forwarding rule gives the IP and port; a target proxy ties the forwarding rule to the URL map; a reserved static IP gives a stable address for DNS. HTTPS redirect from HTTP requires both forwarding rules on the same IP.

Passthrough Network LB specifics

• External passthrough NLB: regional forwarding rule on a regional external IP, backend service with instance groups or zonal NEGs, health checks (legacy target pools use legacy HTTP checks and are not recommended). Supports session affinity by 5-tuple, 3-tuple or 2-tuple, connection tracking modes, weighted load balancing with health-check driven weights, and failover configuration (active and backup pools with a failover ratio).
• Internal passthrough NLB: the frontend is an internal IP in a subnet; clients in the same VPC, peered VPCs (via a route), connected on-premises (VPN or Interconnect) or in other regions with global access can reach it. Use it as a next hop for a static route to build highly available NVA clusters. Same source IP preservation, symmetric hash for NVA setups.
• Both support UDP and all ports (--ports=ALL), forwarding to all ports across protocols with an L3_DEFAULT forwarding rule.
• Backends must accept traffic to the LB’s IP (Google guest agent adds a local route).

Load balancing for GKE

Container-native load balancing uses zonal NEGs (annotation cloud.google.com/neg) so the LB targets Pod IPs directly. Benefits: fewer hops (no kube-proxy), accurate health checks, better latency, and pod-level balancing. It is the default for VPC-native clusters in recent versions. Health checks come from the readiness probe unless a policy overrides it. Firewall rules need to allow the probe ranges and the proxy-only subnet to Pod IPs.

Cloud CDN

Cloud CDN caches content at Google edge locations close to users. It is enabled on a backend service or backend bucket behind a global external Application LB (and classic).

Key settings:

• Cache modes: CACHE_ALL_STATIC (default; caches common static types and honors headers), USE_ORIGIN_HEADERS (respect Cache-Control and Expires strictly), FORCE_CACHE_ALL (cache everything regardless, risky for private data).
• TTLs: default TTL (1 hour default), client TTL, maximum TTL; Cache-Control: max-age and s-maxage interact with them. Negative caching can cache 404s and similar.
• Cache key: protocol, host and query string; include or exclude query parameters or headers/cookies to raise the hit ratio. Fewer key components means more hits.
• Signed URLs and signed cookies restrict who can fetch cached content; the key is a CDN signing key shared with the app.
• Invalidation: gcloud compute url-maps invalidate-cdn-cache with a path (or a wildcard at the end) and optionally a host. It takes some time to propagate and is rate-limited, so prefer versioned object names (cache busting with new URLs) and short TTLs over frequent invalidations.
• Serve stale (serve-while-stale) and request coalescing reduce origin load; cache hit ratio and latency are exposed in Cloud Monitoring and LB logs (cache status in logs).
• Only certain responses are cached: successful responses to GET with cacheable status codes and a TTL; responses with Set-Cookie headers or no cache directives may not be cached; POST is never cached. Range requests are supported.
• Cloud CDN is not supported with internal LBs; and Media CDN is a separate product for large video and streaming.
• For third-party object storage (for example an S3-compatible bucket), use an internet NEG with FQDN, set the host header, and for private buckets use origin authentication (signed requests) rather than making the bucket public.