Load Balancing

Exam guide§2.3

Cloud Load Balancing is a fully distributed, software-defined, managed service. It is not instance- or device-based, so there is no physical load-balancing hardware to provision, patch, or scale - Google Cloud runs it for you.

#NumbersCloud Load Balancing at a glance

• Fully distributed, software-defined, managed - no physical load-balancing appliance to deploy or maintain.
• Scales to over 1 million queries per second.
• Distributes backends across a single region or multiple regions to meet high-availability needs.
• Pairs with autoscaling to grow or shrink backend capacity with demand, serving each user from the closest healthy region.

The whole family fits in one matrix - external vs internal, and Layer 7 (Application) vs Layer 4 (Network):

Every Google Cloud load balancer is one cell of this matrix: external or internal, and Layer 7 (Application) or Layer 4 (Network, which is either proxy or passthrough).

Pick a load balancer by answering three questions:

1. Where are the clients? Internet-facing (external) or inside the VPC (internal)?
2. How far do backends spread? One region (regional) or many (global)?
3. What layer? HTTP(S) content routing (L7 / Application) or raw TCP/UDP (L4 / Network)?

L7 balancers are proxies (terminate the connection, can route by URL/host, do TLS). L4 can be proxy (proxy Network LB, TCP or SSL) or passthrough (passthrough Network LB preserves client IP, no proxy).

?DECISIONExternal vs internal - quick cut

The public internet→External LB

Inside your VPC / on-prem over VPN/Interconnect→Internal LB

Pick this when: who initiates the connection decides everything

The selection table

?DECISIONWhich load balancer?

Global website / API, URL routing, CDN→Global external Application LBExternal · Global · L7

Regional web app, keep it simple/cheap→Regional external Application LBExternal · Regional · L7

Internet TCP/UDP, preserve client IP, gaming→External passthrough Network LBExternal · Regional · L4 passthrough

Internet TCP/SSL, non-HTTP, global→Global external proxy Network LBExternal · Global · L4 proxy

Internal microservice HTTP routing→Internal Application LBInternal · Regional · L7

Internal TCP/UDP, front a service in-VPC→Internal passthrough Network LBInternal · Regional · L4 passthrough

Pick this when: match client location + scope + protocol layer to one row

⚠GotchaOnly global external Application LB gets one anycast IP worldwide

The global external Application LB uses a single anycast IP and routes each user to the nearest healthy backend region - it needs Premium network tier. Regional LBs serve a single region. If the question says "one IP, users everywhere, closest region", it is the global external Application LB.

⚠GotchaPassthrough preserves the client source IP; proxy does not

Passthrough Network LB does not terminate connections - backends see the real client IP. Any Application LB or proxy LB terminates the connection, so backends see the LB's IP (client IP is in X-Forwarded-For). Choose passthrough when the app needs the true source IP.

How the Application Load Balancer routes a request

The external Application LB is not one resource - it is a chain of them, all fronted by a single global IP address. A request walks the chain top to bottom:

→StepsThe request pipeline, in order

• Global forwarding rule - the front door for the global IP; hands the request to the target proxy.
• Target HTTP(S) proxy - terminates the connection and consults the URL map.
• URL map - matches the host/path and picks the backend service.
• Backend service - holds one or more backends (managed instance groups or NEGs) plus the health check and balancing mode.
• Backends (MIGs / NEGs) - the actual instances, spread across one or more regions.

The same chain drives two behaviors worth knowing for the exam: routing a request to the closest region (example 1), and routing it to the right backend by URL path (example 2).

Example 1 - Cross-region load balancing

Here one guestbook app has a single global IP but two sets of users - one in North America, one in EMEA - and two backends, us-central1-a and europe-west1-d.

Request path - NA and EMEA users hit the global forwarding rule, which the target proxy and URL map route to the backend service, which spreads traffic across the US-Central1-a and Europe-West1-d managed instance groups while the health check probes them.

The load balancing service knows the approximate origin of each request (from source IP), plus the location, capacity, and current usage of every backend. If the closest region has healthy capacity the request goes there - NA users to us-central1-a, EMEA users to europe-west1-d. Within a region, requests spread evenly across all healthy backends.

⚠GotchaNo capacity in the closest region spills over to the next closest

If a region has no healthy instances with available capacity (per the health checker), the LB forwards the request to the next closest region instead - EMEA traffic can land on the us-central1-a backend when europe-west1-d is full or unhealthy. This is cross-region load balancing, and it is automatic - you do not configure a failover target.

Example 2 - Content-based load balancing

Same single global IP, but now the URL map splits traffic across different backend services by URL path. Requests to /video go to the video backend; everything else falls to the default web backend:

The Application Load Balancer splits HTTP traffic by URL path - default requests route to instance group 1 (www-service) and /video to instance group 2 (video-service).

The split is decided entirely by the URL map, so one front-end IP can fan out to purpose-built backends (a www-service for pages, a video-service for streaming) without the client ever knowing there is more than one.

Recap

#NumbersFixed facts

• Health checks are mandatory for all LBs - unhealthy backends get no traffic.
• Backend service = managed instance groups (MIGs) or network endpoint groups (NEGs) + health check + balancing mode.
• Cloud CDN attaches only to the external Application LB.
• SSL/TLS termination happens at Application LBs and proxy Network LBs, not at passthrough.
• Internal LBs use RFC 1918 private IPs and only serve clients inside the VPC (or connected via VPN/Interconnect).