Passthrough Network Load Balancers are Layer 4 regional, passthrough load balancers. These load balancers distribute traffic among backends in the same region as the load balancer. As the name suggests, passthrough 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 at the backends. 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 diagram shows a sample passthrough Network Load Balancer architecture.
You'd use a passthrough Network Load Balancer in the following circumstances:
- You need to forward original client packets to the backends un-proxied—for example, if you need the client source IP address to be preserved.
- You need to load balance TCP, UDP, ESP, GRE, ICMP, and ICMPv6 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 passthrough Network Load Balancer cannot perform this task. When the backends decrypt SSL traffic, there is a greater CPU burden on the VMs.
- You are able to manage the backend VM's SSL certificates yourself. Google-managed SSL certificates are only available for proxy load balancers.
- You have an existing setup that uses a passthrough load balancer, and you want to migrate it without changes.
Passthrough Network Load Balancers are available in the following modes of deployment.
| Scope | Traffic type | Network service tier | Load-balancing scheme † | IP address | Frontend ports | Links | |
|---|---|---|---|---|---|---|---|
| External passthrough Network Load Balancer
Load balances traffic that comes from clients on the internet. |
Regional | TCP, UDP, ESP, GRE, ICMP, and ICMPv6 | Premium or Standard | EXTERNAL | IPv4 and IPv6 | A single port, range of ports, or all ports | Architecture details |
| Internal passthrough Network Load Balancer
Load balance traffic within your VPC network or networks connected to your VPC network. |
Regional | TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE | Premium | INTERNAL | IPv4 and IPv6 | A single port, range of ports, or all ports | Architecture details |
† The load-balancing scheme is an attribute on the forwarding rule and the backend service of a load balancer and indicates whether the load balancer can be used for internal or external traffic.
External passthrough Network Load Balancers
External passthrough Network Load Balancers are regional, layer 4 load balancers that distribute external traffic among backends (instance groups or network endpoint groups (NEGs)) in the same region as the load balancer. These backends must be in the same region and project but can be in different VPC networks. These load balancers are built on Maglev and the Andromeda network virtualization stack.
External passthrough Network Load Balancers 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
External passthrough Network Load Balancers are not proxies. The load balancer itself doesn't terminate user connections. Load-balanced packets are sent to the backend VMs with their source and destination IP addresses, protocol, and, if applicable, ports, unchanged. The backend VMs then terminate user connections. Responses from the backend VMs go directly to the clients, not back through the load balancer. This process is known as direct server return (DSR).
The following diagram shows an external passthrough Network Load Balancer that is configured in the
us-central1 region with its backends located in the same region. Traffic is
routed from a user in Singapore to the
load balancer in us-central1 (forwarding rule IP address 120.1.1.1).
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.
The architecture of an external passthrough Network Load Balancer depends on whether you use a backend service or a target pool to set up the backend.
Backend service-based load balancers
External passthrough 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
backends. Backend service-based
external passthrough Network Load Balancers support IPv4 and IPv6 traffic, multiple protocols
(
TCP, UDP, ESP, GRE, ICMP, and ICMPv6
), managed and unmanaged instance group backends,
zonal network endpoint group (NEG) backends with GCE_VM_IP endpoints,
fine-grained traffic distribution controls, failover policies, and let you use
non-legacy health checks that match the type of traffic (TCP, SSL, HTTP, HTTPS,
or HTTP/2) that you are distributing.
Load balancing to Google Kubernetes Engine (GKE) is handled by using the built-in GKE Service controller. In addition, backend service-based external passthrough Network Load Balancers are supported with App Hub, which is in preview.
For architecture details and more information about supported features, see Backend service-based external passthrough Network Load Balancer overview.
You can transition an existing target pool-based load balancer to use a backend service instead. For instructions, see Migrate load balancers from target pools to backend services.
Target pool-based load balancers
A target pool is the legacy backend supported with external passthrough Network Load Balancers. A target pool defines a group of instances that should receive incoming traffic from the load balancer.
Target pool-based load balancers support either TCP or UDP traffic. Forwarding rules for target pool-based external passthrough Network Load Balancers only support external IPv4 addresses.
For architecture details, see Target pool-based external passthrough Network Load Balancer overview.
Internal passthrough Network Load Balancers
Internal passthrough Network Load Balancers distribute traffic among internal virtual machine (VM) instances in the same region in a Virtual Private Cloud (VPC) network. They enable you to run and scale your services behind an internal IP address that is accessible only to systems in the same VPC network or systems connected to your VPC network.
These load balancers are built on the Andromeda network virtualization stack. They support only regional backends so that you can autoscale across a region, protecting your service from zonal failures. Additionally, this load balancer can only be configured in Premium Tier.
The internal passthrough Network Load Balancers address many use cases. The following sections showcase a few high-level examples.
Access to connected networks
You can access an internal passthrough Network Load Balancer in your VPC network from a connected network by using the following:
- VPC Network Peering
- Cloud VPN and Cloud Interconnect
For detailed examples, see Internal passthrough Network Load Balancers and connected networks.
Three-tier web service
You can use internal passthrough Network Load Balancers in conjunction with other load balancers. For example, if you incorporate external Application Load Balancers, the external Application Load Balancer is the web tier and relies on services behind the internal passthrough Network Load Balancer.
The following diagram depicts an example of a three-tier configuration that uses external Application Load Balancers and internal passthrough Network Load Balancers:
Three-tier web service with global access
If you enable global access, your web-tier VMs can be in another region, as shown in the following diagram.
This multi-tier application example shows the following:
- A globally available internet-facing web tier that load balances traffic with an external Application Load Balancer.
- An internal backend load-balanced database tier in the
us-east1region that is accessed by the global web tier. - A client VM that is part of the web tier in the
europe-west1region that accesses the internal load-balanced database tier located inus-east1.
Using internal passthrough Network Load Balancers as next hops
You can use an internal passthrough Network Load Balancer as the next gateway to which packets are forwarded along the path to their final destination. To do this, you set the load balancer as the next hop in a static route.
A next hop internal passthrough Network Load Balancer processes packets for all supported traffic regardless of the forwarding rule and backend service protocols that you specified when you created the load balancer.
This feature supports using either IPv4 or IPv6 (Preview) addresses.
Here is a sample architecture using an internal passthrough Network Load Balancer as the next hop to a NAT gateway. You can route traffic to your firewall or gateway virtual appliance backends through an internal passthrough Network Load Balancer.
Additional use cases include:
- Hub and spoke: Exchanging next-hop routes by using
VPC Network Peering—You can configure a hub-and-spoke topology with
your next-hop firewall virtual appliances located in the
hubVPC network. Routes using the load balancer as a next hop in thehubVPC network can be usable in eachspokenetwork. - Load balancing to multiple network interfaces (
nic0throughnic7) on the backend VMs.
For more information about these use cases, see Internal passthrough Network Load Balancers as next hops.
Internal passthrough Network Load Balancers and GKE
For details about how GKE creates internal passthrough Network Load Balancers for Services, see LoadBalancer Service concepts in the GKE documentation.
Internal passthrough Network Load Balancers and App Hub
Resources used by Internal passthrough Network Load Balancers can be designated as services in App Hub, which is in preview.
Private Service Connect port mapping
Private Service Connect port mapping services use port mapping NEGs and have similar configurations to Internal passthrough Network Load Balancers. However, port mapping services don't load balance traffic. Instead, Private Service Connect forwards traffic to service ports on service producer VMs based on the client destination port that receives the traffic.
If you send traffic to a port mapping service from the same VPC network as the service, the packets are dropped.
For more information, see About Private Service Connect port mapping.
What's next
- For detailed architectural information about internal passthrough Network Load Balancers, see Internal passthrough Network Load Balancer architecture overview.
- For detailed architectural information about external passthrough Network Load Balancers, see External passthrough Network Load Balancer architecture overview.