Cloud Load Balancing
Cloud Load Balancing is the broadest service family in this chapter. It is not one balancer but a matrix of variants — external or internal, global or regional, application (L7) or network (L4) — each with different capabilities and price points. The first architectural decision is choosing the right variant. The wrong choice is hard to undo without rebuilding the front door of your system.
Google's distinctive trait: the global Application Load Balancer is anycast. A single IP serves users worldwide from their nearest Google edge POP, with TLS terminated at the edge and traffic riding Google's backbone to the closest healthy backend. AWS and Azure require Global Accelerator or Front Door as a separate layer for the same behavior.
The Load Balancer Matrix
Three axes define every variant:
- External vs Internal — does the balancer accept traffic from the public internet, or only from inside the VPC?
- Global vs Regional — one anycast IP serving worldwide, or a regional IP serving traffic in one Google region?
- Application (L7) vs Network (L4) — does it understand HTTP/HTTPS, or operate at TCP/UDP only?
External Application LB (global flavor) is the default for new public HTTP(S) services. Internal Application LB serves north-south traffic inside a VPC. Network LB handles UDP, raw TCP, and any case where L7 features are not needed.
Application Load Balancer
The Application Load Balancer (HTTP/HTTPS) is the most feature-rich variant. URL maps express routing rules declaratively: path-based and host-based routing send different requests to different backends. Edge TLS termination lets backends serve plain HTTP. The Global variant gives one anycast IP worldwide; users from any region hit the nearest Google POP and ride the private backbone to the closest healthy backend. Use it for any public HTTP(S) service that benefits from edge presence — which is almost all of them.
Network Load Balancer
The Network Load Balancer family covers TCP, UDP, and other IP protocols. Two variants: proxy NLB (terminates TCP connections at the proxy, with optional TLS offload — TCP and SSL traffic only) and passthrough NLB (preserves source IP at the connection level, no TCP termination, and the only variant carrying UDP, ESP, GRE, and ICMP). Pick by traffic shape: proxy NLB when you want TLS offload or global TCP fronting; passthrough when the backend needs the original client IP or the protocol is anything other than TCP/SSL.
Application Load Balancer — for HTTP/HTTPS. Use this unless you have a specific reason not to. Path-based routing, edge TLS, Cloud Armor, Cloud CDN, URL rewriting. The right default for web services.
Network Load Balancer — for UDP, raw TCP, or workloads that need the original client IP without proxy protocol. Lower latency, fewer features. Prefer proxy NLB to passthrough when you have the choice.
Backend Services and NEGs
A backend service defines how the load balancer distributes traffic across a pool of endpoints. The endpoints themselves come from: instance groups (VMs in a Managed Instance Group), Network Endpoint Groups (NEGs) for serverless or container backends (Cloud Run, Cloud Functions, App Engine, GKE pods), or hybrid NEGs for on-prem and other-cloud endpoints. NEGs are the modern targeting model — far more flexible than VM-only instance groups. Choose them whenever the backend is anything other than raw VMs.
Health Checks
Every backend service needs a health check. The load balancer routes only to healthy backends — and a misconfigured health check is the most common reason "I deployed it but the load balancer returns 502." Health checks can be HTTP, HTTPS, gRPC, or TCP. Match the protocol to what the backend actually serves; an HTTPS check against an HTTP-only endpoint fails silently. Verify the check is succeeding in the console before declaring the deploy done.
SSL/TLS and Google-managed Certificates
Provision Google-managed certificates unless you have a specific reason not to. Google handles validation via DNS or load balancer authorization, then auto-renews — certificate operations disappear from the on-call rotation. Self-managed certificates fit two cases: you need a specific certificate authority (compliance, internal PKI), or your domain validation cannot expose a TXT record or HTTP endpoint. Otherwise managed certificates are correct.
Cloud Armor and DDoS Protection
Cloud Armor is the WAF and DDoS protection that attaches to external Application Load Balancers. It runs at Google edge, before traffic reaches your backends — a 100k-RPS DDoS hits Google's network, not your origin servers. Cloud Armor enforces WAF rules (OWASP signatures, custom rule expressions), rate limits, and geo-based filtering. Public-facing services should always have at least a baseline Cloud Armor policy.
- Choosing regional Application LB when global is needed for cross-region failover — regional has one regional IP, no anycast.
- Using Application LB for raw TCP traffic that does not need L7 features — adds cost and complexity over Network LB.
- No health checks on backend services, or a health check protocol that does not match what the backend serves.
- Self-managing SSL certificates when Google-managed certs would handle the workload.
- Public-facing service deployed without any Cloud Armor policy.
- Backend service timeout too short for legitimate long-polling, server-sent events, or websocket connections — connections drop unexpectedly.
- Using instance group backends for Cloud Run or Cloud Functions when serverless NEGs are the right targeting model.
- Application Load Balancer as the default for HTTP/HTTPS.
- Global variant unless you have a specific reason to scope to one region.
- Google-managed certificates unless self-managed is genuinely required.
- Cloud Armor on every public Application LB, with at least the OWASP baseline rules and a default rate limit.
- Serverless NEGs for Cloud Run, Cloud Functions, and App Engine backends.
- Match health check protocol to what the backend serves; verify it succeeds in the console before declaring the deploy done.
- Tune backend service timeouts for the actual application protocol — long-polling, SSE, and websockets need explicit configuration.
Knowledge Check
What is the practical benefit of the Global Application Load Balancer's anycast IP?
- It increases the number of available IP addresses for a single load balancer deployment
- A single IP serves users worldwide from their nearest Google POP, with TLS terminated at the edge and traffic riding the Google backbone to the closest healthy backend
- It enables the edge to route each request based on the client's advertised autonomous system number (ASN) rather than on raw geographic proximity to a POP
- It lets two independent regional load balancers in different regions share a single external IP and fail over to each other automatically without any DNS or client-side changes
Which load balancer variant should you choose for HTTP/HTTPS services unless a specific reason rules it out?
- Network Load Balancer (passthrough)
- Network Load Balancer (proxy)
- Application Load Balancer
- Internal Application Load Balancer regardless of traffic direction
What is the purpose of a Network Endpoint Group (NEG) in Cloud Load Balancing?
- Defining which networks a load balancer is allowed to receive traffic from
- Targeting backends that are not VMs in instance groups — Cloud Run, Cloud Functions, GKE pods, and on-prem hybrid backends
- Grouping the load balancer's health-check probes so their results can be exported to a single centralized monitoring dashboard per backend service
- Aggregating logs from multiple backend services into a single log sink
What is the most common cause of "load balancer returns 502" right after a deploy?
- The serverless NEG is in a different region from the load balancer
- Cloud Armor blocking legitimate traffic by mistake
- Health checks misconfigured — wrong protocol, wrong path, or wrong port — so the load balancer believes every backend is unhealthy
- Backend service timeout set higher than the load balancer's own request timeout, so the proxy gives up and returns 502 before the backend finishes responding
What is the principal trade-off of Google-managed SSL certificates versus self-managed?
- Google-managed certificates are cheaper per request handled
- Google-managed handles validation and auto-renewal automatically, removing cert ops from on-call; you give up the ability to use a specific CA or trust chain
- Self-managed certificates support more domains per single certificate
- Self-managed certificates work with global external load balancers, whereas Google-managed certificates are restricted to regional and internal load balancers only
You got correct