Google Cloud Load Balancing is a family of services, not one product with a single behavior. The correct design depends on protocol, whether Google terminates or proxies the connection, whether the client source IP must be preserved, whether the service is internal or internet-facing, and whether backends span one region, multiple regions, or multiple environments.

For candidates working toward the Professional Cloud Network Engineer or Professional Cloud Architect, the practical skill is to map an application requirement to the right load-balancer family. A generic statement such as “use a Google load balancer for high availability” is incomplete until the protocol and traffic-processing model are clear.

Begin with layer 7, proxy layer 4, or passthrough layer 4

The first decision is how much of the connection the load balancer should understand. Application Load Balancers operate at layer 7 for HTTP and HTTPS traffic. They can make routing decisions using application information such as hostnames and URL paths. Proxy Network Load Balancers operate at layer 4 but terminate the client connection at a proxy and create a separate connection to the backend. Passthrough Network Load Balancers distribute layer-4 traffic without proxy termination.

This difference affects nearly every downstream feature. A layer-7 proxy can perform HTTP-aware routing and integrate with web-focused security controls. A proxy network load balancer can handle TCP-oriented workloads that still benefit from a Google-managed proxy. A passthrough load balancer is appropriate when preserving original packet characteristics and client source IP is important or when protocols do not fit a proxy model.

Cloud load balancing principles such as health checking, distribution, failover, and capacity protection still apply, but Google Cloud architecture requires the product-family distinction before backend selection begins.

Application Load Balancers provide HTTP-aware traffic management

Application Load Balancers are designed for HTTP, HTTPS, and related application protocols. A typical configuration uses a forwarding rule, target proxy, URL map, backend service, and health checks. The URL map can route requests according to host and path patterns, which allows multiple services to share an entry point while receiving different traffic.

Because the load balancer terminates the client connection, it can participate in TLS certificate management, redirects, HTTP-to-HTTPS behavior, header-based routing features, content delivery integrations, and application security. External variants serve internet clients, while internal variants support private application traffic. Google also provides regional and cross-region options for designs that need different placement and availability characteristics.

Application-layer awareness is powerful but it also changes troubleshooting. A backend can be healthy at the TCP level while returning an HTTP status that fails the configured health check. A URL map can send a request to an unexpected backend even though DNS and the frontend IP are correct. Engineers therefore need to inspect the complete request-routing chain.

Proxy Network Load Balancers handle TCP or TLS through a proxy

Proxy Network Load Balancers provide layer-4 proxying for workloads that do not need HTTP-aware routing. Google accepts the client connection at the load-balancer frontend and opens a separate connection toward the backend. This model can provide a stable managed entry point for TCP services while decoupling clients from backend instances.

Because the connection is proxied, the backend does not see the original client connection in the same way as a passthrough design. Applications that require the client source IP should verify the supported mechanism for carrying client information or select a different family if packet preservation is fundamental.

Proxy load balancing is useful for services such as custom TCP applications and TLS workloads where a managed proxy is desirable. The exact external or internal product variant determines scope, backend types, and other supported features, so design documents should name the specific load-balancer mode rather than saying only “TCP load balancer.”

Passthrough Network Load Balancers preserve packet semantics

Passthrough Network Load Balancers operate at layer 4 without terminating the connection at a proxy. Traffic is delivered to healthy backend VMs while preserving important packet fields, including the client source IP. That makes passthrough useful for applications that depend on source-address visibility, support protocols beyond the proxy families, or perform their own connection handling.

The backend must be prepared to receive traffic addressed to the load balancer’s frontend. This is a different operating model from a proxy, where the backend sees a new connection from Google infrastructure. Health checks, instance configuration, and firewall rules must therefore match the passthrough architecture.

Passthrough does not mean “no load balancing intelligence.” Google still distributes traffic according to the service design and backend health. The distinction is that the packets are not converted into a separate proxy session before reaching the backend.

Global, regional, and cross-region scope are architecture choices

Google Cloud load balancers can have different geographic scopes. Some external load balancers use global anycast frontends so clients can reach a single global IP and enter Google’s network near their location. Regional load balancers keep frontend and backend behavior tied to a region. Cross-region internal application load balancing can provide private application access across multiple regions.

The correct scope depends on the failure boundary and client population. A global public application with users on several continents may benefit from a global frontend and multi-region backends. An internal line-of-business application whose dependencies live in one region may be simpler and cheaper with regional load balancing. A private service that must survive regional failure may justify a cross-region design.

Do not treat “global” as an automatic upgrade. Multi-region backends require data, session, and dependency architecture that can actually tolerate regional failover. Sending traffic to a second region is not useful if the database or identity dependency exists only in the failed region.

Backend services, NEGs, and health checks define where traffic can go

Google Cloud separates the frontend from the backend definition. Backend services can reference instance groups or network endpoint groups depending on the load-balancer family. NEGs make it possible to represent endpoints such as GKE pods, serverless services, internet endpoints, hybrid endpoints, or other supported destination types without pretending every backend is a traditional VM group.

Health checks determine whether an endpoint should receive traffic. A good health check tests something meaningful enough to detect failure without becoming so expensive that it creates load. Checking only whether a port accepts a connection can miss an application whose dependencies are broken; checking an expensive business transaction can overload the service or fail for reasons unrelated to serving ordinary traffic.

Backend capacity, balancing mode, locality, and autoscaling should be designed together. A load balancer cannot compensate for a backend that scales too slowly, has insufficient regional quota, or depends on a single shared database bottleneck.

Security controls depend on where the connection terminates

Application Load Balancers integrate naturally with web-focused protections because Google terminates and understands the HTTP request. Cloud Armor can apply security policies, web application firewall rules, rate controls, and other protections to supported load-balanced services before requests reach application backends.

Network firewall policy still matters behind the load balancer. Backends should allow only the required health-check and load-balancer traffic sources according to the product documentation, not broad internet access. TLS policy, certificate lifecycle, backend authentication where supported, and logging should be considered separately from the decision to distribute traffic.

For internal load balancing, “internal” does not mean “trusted.” Identity and application authorization should still restrict sensitive operations, and network segmentation should limit which clients can reach the frontend.

Session behavior deserves explicit planning as well. Long-lived connections, WebSockets, connection draining, and session affinity can change how quickly traffic moves after a backend is removed or a rollout begins. Affinity can improve application behavior when state is not fully externalized, but it should not be mistaken for durable state management. A backend can still disappear during maintenance or failure, so critical session state belongs in a resilient shared store or should be reconstructible by the application.

Deployment strategy should account for those connection semantics. A canary release behind a layer-7 load balancer may use weighted routing or separate backend services, while a TCP service with persistent sessions may need longer drain periods. Load balancing is therefore part of release engineering as well as availability engineering.

Observability must show frontend, routing, and backend behavior

A user-visible failure can originate at DNS, the frontend IP, TLS negotiation, URL routing, a backend service, a health check, firewall policy, backend capacity, or the application itself. Troubleshooting is faster when logs and metrics are collected from each stage instead of treating the load balancer as a black box.

Start by verifying the client resolves the expected address and can reach the frontend. Then check certificate and proxy behavior, routing rules, backend health, and the backend application’s own logs. Compare failing and healthy requests by host, path, region, backend, response code, and latency.

During failover testing, verify real sessions and not just the console health indicator. Connection draining, session affinity, long-lived TCP sessions, and cached DNS can change what users experience after a backend is removed.

Select the family from the application contract

Choose an Application Load Balancer when the service is HTTP-based and benefits from layer-7 routing, TLS termination, web security, or global application delivery. Choose a Proxy Network Load Balancer when the application is TCP-oriented but should sit behind a managed proxy. Choose a Passthrough Network Load Balancer when packet preservation, client source IP, or broader layer-4 protocol behavior is required.

Then choose internal versus external and regional versus global or cross-region scope based on who the clients are and which failures the application must survive. Finally, select backends, health checks, and security policy that match the traffic-processing model.

Good load-balancing architecture begins with the client-to-application contract. When protocol, connection termination, source-IP requirements, scope, and backend failure behavior are explicit, Google’s load-balancer family becomes much easier to navigate and much harder to misconfigure.