Google Cloud external TCP/UDP Network Load Balancing (after this referred to as Network Load Balancing) is a regional, pass-through load balancer. A network load balancer distributes external traffic among virtual machine (VM) instances in the same region.
A network load balancer can receive traffic from:
- Any client on the internet
- Google Cloud VMs with external IPs
- Google Cloud VMs that have internet access through Cloud NAT or instance-based NAT
Network Load Balancing has the following characteristics:
- Network Load Balancing is a managed service.
- Network Load Balancing is implemented by using Andromeda virtual networking and Google Maglev.
- Network load balancers are not proxies.
- Load-balanced packets are received by backend VMs with their source IP unchanged.
- Load-balanced connections are terminated by the backend VMs.
- Responses from the backend VMs go directly to the clients, not back through the load balancer. The industry term for this is direct server return.
The following diagram shows users in California, New York, and Singapore. They're all connecting into their backend resources, which are myapp, test, and travel. When a user in Singapore connects into the U.S. West backend, the traffic ingresses closest to Singapore because the range is anycasted. From there, the traffic is routed to the regional backend.
A network load balancer balances traffic originating from the internet.
The scope of a network load balancer is regional, not global. This means that a network load balancer cannot span multiple regions. Within a single region, the load balancer services all zones.
Use Network Load Balancing in the following circumstances:
- You need to load balance non-TCP traffic, or you need to load balance a TCP port that isn't supported by other load balancers.
- It is acceptable to have SSL traffic decrypted by your backends instead of by the load balancer. The network load balancer cannot perform this task. When the backends decrypt SSL traffic, there is a greater CPU burden on the VMs.
- Self-managing the backend VM's SSL certificates is acceptable to you. Google-managed SSL certificates are only available for HTTP(S) Load Balancing and SSL Proxy Load Balancing.
- You need to forward the original packets unproxied. For example, if you need the client source IP to be preserved.
- You have an existing setup that uses a pass-through load balancer, and you want to migrate it without changes.
The architecture of a network load balancer depends on whether you use a backend service-based network load balancer or a target pool-based network load balancer.
Backend service-based network load balancer
Network load balancers can be created with a regional backend service that defines the behavior of the load balancer and how it distributes traffic to its backend instance groups. Backend services enable features that are not supported with legacy target pools, such as support for non-legacy health checks (TCP, SSL, HTTP, HTTPS, or HTTP/2), auto-scaling with managed instance groups, connection draining, and a configurable failover policy.
Backend service-based network load balancers can be used to load-balance TCP, UDP, ESP, and ICMP traffic.
For architecture details, see network load balancer with a regional backend service.
You can also transition an existing target pool-based network load balancer to use a backend service instead. For instructions, see Transitioning network load balancers from target pools to backend services.
Target pool-based network load balancer
A target pool is the legacy backend supported with Google Cloud's network load balancers. A target pool defines a group of instances that should receive incoming traffic from the load balancer.
Target pool-based network load balancers support either TCP or UDP traffic.
For architecture details, see network load balancer with a target pool backend.
Comparing Network Load Balancing to other Google Cloud load balancers
For information about how the Google Cloud load balancers differ from each other, see the following documents: