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.
You can configure a network load balancer for TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic.
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 the packet's source and destination IP addresses, protocol, and, if the protocol is port-based, the source and destination ports 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 External 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.
- You require advanced network DDoS protection for your network load balancer. For more information, see Configure advanced network DDoS protection using Google Cloud Armor.
Load balancing for GKE applications
If you are building applications in GKE, we recommend that you use the built-in GKE Service controller, which deploys Google Cloud load balancers on behalf of GKE users. This is the same as the standalone load balancing architecture, except that its lifecycle is fully automated and controlled by GKE.
Related GKE documentation:
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 support IPv4 and IPv6 traffic. They can load-balance TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic. You can also use source-IP based traffic steering to direct traffic to specific backends.
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. Forwarding rules for target pool-based network load balancers only support external IPv4 addresses.
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: