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 (DSR).
The following diagrams show a network load balancer whose forwarding rule has the
IP address 120.1.1.1. The network load balancer is configured in the
us-central1 region with its backends located in the same region.
Network load balancers are regional in nature and only support backends in the same region as their configured frontends. However, packets to network load balancers can still be sent from anywhere on the internet regardless of whether the IP address of the load balancer is in the Premium Tier or the Standard Tier. If the IP address of the load balancer is in the Premium Tier, the traffic traverses Google's high‑quality global backbone with the intent that packets enter and exit a Google edge peering point as close as possible to the client. If the IP address of the load balancer is in the Standard Tier, the traffic enters and exits the Google network at a peering point closest to the Google Cloud region where the load balancer is configured.
In the following diagram, traffic is routed from a user in Singapore to the
network load balancer in us-central1 (forwarding rule IP address 120.1.1.1).
In the following diagram, traffic is routed from a user in Iowa to the
network load balancer in us-central1 (forwarding rule IP address 120.1.1.1).
Scope
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 cases
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:
Architecture
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: