Network Load Balancing
Network Load Balancers are Layer 4 load balancers - they distribute TCP, UDP, or other IP protocol traffic to backends in a single region or across multiple regions. This is the L4 counterpart to the Application Load Balancer; pick it when you are not routing on HTTP(S) content.
- Layer 4 - operates on TCP/UDP and other IP protocols, not HTTP paths or hosts.
- Comes in two families: proxy and passthrough.
- Handles TCP, UDP, ESP, GRE, ICMP, and ICMPv6 (passthrough); proxy handles TCP (with or without SSL).
- Backends can sit in a single region or across multiple regions depending on the family and mode.
Proxy vs passthrough - the first decision
The two families behave very differently. A proxy terminates the client connection at the load balancer and opens a fresh one to the backend; a passthrough forwards the client's packets untouched and lets the backend answer the client directly.
Both proxy and passthrough Network LBs are for raw L4 traffic. For HTTP(S) - URL routing, host headers, CDN - use an Application Load Balancer instead.
Proxy Network Load Balancer
A proxy Network Load Balancer is a Layer 4 reverse proxy. Client traffic is terminated at the load balancing layer, then a new connection is forwarded to the closest available backend over TCP.
It deploys externally (internet-facing) or internally (in-VPC - covered later in this module). External proxy Network LBs distribute internet traffic to backends in your VPC, on-premises, or in other clouds.
- Built on Google Front Ends (GFEs) or Envoy proxies.
- Deployed in three modes: global, regional, or classic.
- Intended for TCP traffic only, with or without SSL.
- The connection from the proxy to the backends can use SSL or TCP - Google recommends SSL.
Target TCP proxy vs target SSL proxy
Depending on the traffic, an external proxy Network LB is configured with either a target TCP proxy or a target SSL proxy. The topology is identical - two connections, terminate at the global LB, re-open to the closest region - only the frontend protocol and port differ.
In the example, the user in Boston reaches the us-east region and the user in Iowa reaches the us-central region, each if there is enough capacity.
| Target proxy | Frontend | Typical port | Use for |
|---|---|---|---|
| Target TCP proxy | Plain TCP | e.g. 110 | Unencrypted TCP that you still want reverse-proxied |
| Target SSL proxy | SSL/TLS | e.g. 443 | Encrypted non-HTTP TCP - SSL terminates at the LB |
With a target SSL proxy the client's SSL connection terminates at the load balancer. The separate connection from the proxy to the backend can be SSL or TCP - Google recommends SSL there as well. For HTTP(S), still prefer an external Application Load Balancer.
Passthrough Network Load Balancer
A passthrough Network Load Balancer is a Layer 4 regional load balancer that distributes traffic among backends in the same region. It is implemented with Andromeda virtual networking and Google Maglev.
- It is not a proxy - load-balanced packets arrive at backend VMs with their source and destination IP, protocol, and (for port-based protocols) source and destination ports unchanged.
- Connections are terminated at the backends, not at the load balancer.
- Responses go directly from the backend VMs to the clients, not back through the LB - the industry term is direct server return (DSR).
- Deployed in two modes: external (internet-facing) or internal (in-VPC, covered later).
External passthrough Network Load Balancer
External passthrough Network LBs are built on Maglev. Clients reach them from anywhere on the internet regardless of Network Service Tier, and they can also receive traffic from Google Cloud VMs with external IPs or with internet access via Cloud NAT or instance-based NAT.
Backends are configured with either a backend service or a target pool. For new deployments, use a backend service.
Backend service-based architecture
A regional backend service defines the behavior of the load balancer and how it distributes traffic to its backend instance groups.
- IPv4 and IPv6 traffic.
- Multiple protocols: TCP, UDP, ESP, GRE, ICMP, and ICMPv6.
- Managed and unmanaged instance group backends.
- Zonal network endpoint group backends with GCE_VM_IP endpoints.
- Fine-grained traffic distribution controls and failover policies.
- Non-legacy health checks matching the traffic type (TCP, SSL, HTTP, HTTPS, or HTTP/2).
You can also transition an existing target-pool-based network load balancer to use a backend service instead.
Target pool (legacy)
A target pool is the legacy backend for external passthrough Network LBs. It defines a group of instances that receive traffic from forwarding rules. When a forwarding rule points at a target pool, the LB picks an instance by a hash of the source IP and port and the destination IP and port.
- Usable only with forwarding rules that handle TCP and UDP traffic.
- Each project can have up to 50 target pools.
- Each target pool has exactly one health check.
- All instances in a target pool must be in the same region (same limit as the Network LB itself).
Unlike a backend service (which supports non-legacy, protocol-matched health checks), a target pool allows only a single health check, its instances must all be in one region, and it only carries TCP/UDP. Prefer a backend service for anything new.