5.1 Load Balancing Options and Use Cases

Why Load Balancing Is a High-Value ACE Topic

Domain 2 of the Associate Cloud Engineer (ACE) exam guide, Planning and configuring a cloud solution, explicitly calls out network resources — and load balancing is the single most commonly tested networking-planning concept on the exam. You will see scenario questions that describe a workload (a global HTTPS API, a UDP-based multiplayer game server, an internal-only microservice) and ask you to pick the correct load balancer type. Getting these right requires knowing not just that Google Cloud "has load balancing," but which specific product fits which protocol, scope, and traffic pattern.

Google Cloud's load balancing portfolio is software-defined — it does not run on a fleet of physical appliances you provision in advance. Every load balancer is built from the same core components, then specialized by layer (7 vs. 4), scope (global vs. regional), and direction (external vs. internal).

The Building Blocks

Every Google Cloud load balancer, regardless of type, is assembled from a small set of resources:

• Forwarding rule — binds a public or internal IP address and port to the load balancer; this is what actually receives traffic.
• Target proxy (HTTP(S)/SSL/TCP) — terminates the connection and applies routing logic; passthrough load balancers skip this piece entirely.
• URL map — for Application Load Balancers only; routes requests to different backend services based on host/path.
• Backend service (or backend bucket) — groups backends (instance groups, GKE NEGs, or serverless NEGs for Cloud Run/Cloud Functions) and defines the health check, timeout, and balancing mode.
• Health check — periodically probes backends; unhealthy backends are automatically removed from rotation without any manual failover step.

Layer 7: Application Load Balancers

Application Load Balancers operate at Layer 7 (HTTP/HTTPS) and understand request content — host, path, headers, and cookies — which lets them do content-based routing, serve Google-managed SSL certificates, and integrate with Cloud CDN and Cloud Armor for edge caching and WAF protection.

• Global external Application Load Balancer — uses a single anycast IP address advertised from every Google point of presence worldwide; backends can live in multiple regions, and Google's network automatically routes each user to the closest healthy region. This is the default choice for a public, multi-region web application or API.
• Regional external Application Load Balancer — same Layer 7 feature set, but all backends must sit in one region; commonly chosen for regulatory/data-residency reasons or when Standard Tier pricing is required (global scope requires Premium Tier).
• Classic Application Load Balancer — the older HTTP(S) load balancer resource model; its scope (global vs. regional) is actually determined by the Network Service Tier of its IP address rather than by an explicit setting.
• Regional internal Application Load Balancer — private, proxy-based Layer 7 load balancing for traffic that never leaves a single region's VPC — the standard pattern for internal microservice-to-microservice HTTP traffic.
• Cross-region internal Application Load Balancer — the internal equivalent of the global external version: private backends spread across multiple regions, reachable from any region via internal IPs.

Layer 4: Network Load Balancers

Network Load Balancers operate below the application layer and split into two distinct families that are frequently confused on the exam:

• Proxy Network Load Balancer — a Layer 4 reverse proxy for TCP traffic, with optional SSL/TLS offload at the proxy. Because it is a true proxy, it can front backends across regions (global) or within one region, and works well when you need TLS termination for non-HTTP TCP protocols.
• Passthrough Network Load Balancer — not a proxy. It uses direct server return, so packets arrive at the backend with the original client IP, protocol, and port untouched. It supports TCP, UDP, ESP, GRE, ICMP, and ICMPv6, and is always regional — there is no global passthrough option. Choose this when the client's real IP address must reach the application (fraud detection, custom logging) or when the protocol isn't HTTP/TCP-proxyable, such as UDP game traffic or ESP for VPN gateways.

Exam Scenarios

Scenario 1: A company runs a public REST API on Compute Engine instances in us-central1 and europe-west1 and wants users routed to whichever region is closest, with a single IP address and managed SSL certificates. Answer: Global external Application Load Balancer — it is the only option offering one anycast IP across multiple regions with HTTP(S) routing.

Scenario 2: A real-time multiplayer game server needs to see the player's actual source IP for anti-cheat logging and communicates over UDP. Answer: External Passthrough Network Load Balancer — it is the only load balancer that supports UDP while preserving the original client IP.

Scenario 3: Two internal services in the same VPC, one on GKE and one on Compute Engine, need to call each other over HTTP without any traffic touching the public internet. Answer: Regional internal Application Load Balancer, pointed at a mix of GKE network endpoint groups (NEGs) and an unmanaged instance group backend.

Common Traps

• Assuming "Network Load Balancer" always means the legacy passthrough product — Google's current naming has both a Proxy Network Load Balancer and a Passthrough Network Load Balancer, and only the passthrough variant preserves client IP and skips TLS termination.
• Forgetting that a global external Application Load Balancer requires the Premium Network Service Tier — a regional external Application Load Balancer is what you get (or must explicitly choose) under Standard Tier.
• Picking an Application Load Balancer for a raw TCP database connection or a UDP workload — Application Load Balancers are HTTP(S)-only; anything else needs a Network Load Balancer.

Key Takeaways

• Application Load Balancers (Layer 7, HTTP/HTTPS) support content-based routing, Cloud CDN, and Google-managed certificates; they come in global external, regional external, and internal (regional or cross-region) flavors.
• Proxy Network Load Balancers terminate TCP (with optional SSL offload) and can span regions; Passthrough Network Load Balancers never proxy, preserve the client's IP via direct server return, support UDP/ESP/GRE, and are always regional.
• A global external Application Load Balancer needs exactly one anycast IP and the Premium Tier; anything requiring UDP or raw client-IP visibility must use a passthrough load balancer instead.