Regional 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.
Regional 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
Regional 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).
Backend service-based regional external passthrough Network Load Balancers support the following features:
- Managed and unmanaged instance group backends. Backend service-based regional external passthrough Network Load Balancers support both managed and unmanaged instance groups as backends. Managed instance groups automate certain aspects of backend management and provide better scalability and reliability as compared to unmanaged instance groups.
- Zonal NEG backends. Backend service-based
regional external passthrough Network Load Balancers support using zonal NEGs with
GCE_VM_IPendpoints. Zonal NEGGCE_VM_IPendpoints let you do the following:- Forward packets to any network interface, not just
nic0. - Place the same
GCE_VM_IPendpoint in two or more zonal NEGs connected to different backend services.
- Forward packets to any network interface, not just
- Support for multiple protocols. Backend service-based regional external passthrough Network Load Balancers can load-balance TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic.
- Support for IPv6 connectivity. Backend service-based regional external passthrough Network Load Balancers can handle both IPv4 and IPv6 traffic.
- Fine-grained traffic distribution control. A backend service allows traffic to be distributed according to the configured session affinity, connection tracking policy, and weighted load balancing settings. The backend service can also be configured to enable connection draining and designate failover backends for the load balancer. Most of these settings have default values that let you get started quickly. For more information, see Traffic distribution for regional external passthrough Network Load Balancers.
- Support for non-legacy, regional health checks. Backend service-based regional external passthrough Network Load Balancers support regional health checks, which can use any supported health check protocol.
- Google Cloud Armor integration. Cloud Armor supports advanced network DDoS protection for regional external passthrough Network Load Balancers. For more information, see Configure advanced network DDoS protection.
GKE integration. 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 described on this page, except that its lifecycle is fully automated and controlled by GKE.
Related GKE documentation:
Architecture
The following diagram illustrates the components of a regional external passthrough Network Load Balancer:
The load balancer is made up of several configuration components. A single load balancer can have the following:
- One or more regional external IP addresses
- One or more regional external forwarding rules
- One regional external backend service
- One or more backends: either all instance groups or all zonal NEG backends
(
GCE_VM_IPendpoints) - Health check associated with the backend service
Additionally, you must create firewall rules that allow your load balancing traffic and health check probes to reach the backend VMs.
IP address
A regional external passthrough Network Load Balancer requires at least one forwarding rule. The forwarding rule references a regional external IP address that is accessible anywhere on the internet.
For IPv4 traffic, the forwarding rule references a single regional external IPv4 address. Regional external IPv4 addresses come from a pool unique to each Google Cloud region. The IPv4 address can be assigned either by specifying a reserved external IP address or by letting Google Cloud automatically assign an ephemeral IPv4 address.
For IPv6 traffic, the forwarding rule references a
/96range of IPv6 addresses from a dual-stack or IPv6-only subnet. The subnet must have an assigned external IPv6 subnet range in the VPC network. External IPv6 addresses are available only in Premium Tier.The
/96IPv6 address range can be assigned by either specifying a reserved external IPv6 address, specifying a custom ephemeral IPv6 address, or letting Google Cloud automatically assign an ephemeral IPv6 address.To specify a custom ephemeral IPv6 address, you must use the gcloud CLI or the API. The Google Cloud console doesn't support specifying custom ephemeral IPv6 addresses for forwarding rules.
For more details about IPv6 support, see the VPC documentation on IPv6 subnet ranges and IPv6 addresses.
Use a reserved IP address for the forwarding rule if you need to keep the address associated with your project for reuse after you delete a forwarding rule or if you need multiple forwarding rules to reference the same IP address.
Regional external passthrough Network Load Balancers support both Standard Tier and Premium Tier for regional external IPv4 addresses. Both the IP address and the forwarding rule must use the same network tier. Regional external IPv6 addresses are only available in the Premium Tier.
Forwarding rule
A regional external forwarding rule specifies the protocol and ports on which the load balancer accepts traffic. Because regional external passthrough Network Load Balancers are not proxies, they pass traffic to backends on the same protocol and ports, if the packet carries port information. The forwarding rule in combination with the IP address forms the frontend of the load balancer.
The load balancer preserves the source IP addresses of incoming packets. The destination IP address for incoming packets is an IP address associated with the load balancer's forwarding rule.
Incoming traffic is matched to a forwarding rule, which is a combination of a particular IP address (either an IPv4 address or an IPv6 address range), protocol, and if the protocol is port-based, one of port(s), a range of ports, or all ports. The forwarding rule then directs traffic to the load balancer's backend service.
If the forwarding rule references an IPv4 address, the forwarding rule is not associated with any subnet. That is, its IP address comes from outside of any Google Cloud subnet range.
If the forwarding rule references a
/96IPv6 address range, this/96IPv6 address range must come from a dual-stack or single-stack IPv6 subnet with an external IPv6 subnet range (with--ipv6-access-typeset toEXTERNAL).The subnet that the forwarding rule references can be the same subnet used by the backend instances; or, backend instances can be located in any dual-stack or single-stack IPv6 subnet in the same region as the forwarding rule. For example, the subnet used by the backends can have an internal IPv6 subnet range (with
--ipv6-access-typeset toINTERNAL).
A regional external passthrough Network Load Balancer requires at least one forwarding rule. Forwarding rules can be configured to direct traffic coming from a specific range of source IP addresses to a specific backend service (or target instance). For details, see traffic steering. You can define multiple forwarding rules for the same load balancer as described in Multiple forwarding rules.
If you want the load balancer to handle both IPv4 and IPv6 traffic, create two forwarding rules: one rule for IPv4 traffic that points to IPv4 (or dual-stack) backends, and one rule for IPv6 traffic that points only to dual-stack backends. It's possible to have an IPv4 and an IPv6 forwarding rule reference the same backend service, but the backend service must reference dual-stack backends.
Forwarding rule protocols
Regional external passthrough Network Load Balancers support the following protocol options for each
forwarding rule: TCP, UDP, and L3_DEFAULT.
Use the TCP and UDP options to configure TCP or UDP load balancing.
The L3_DEFAULT protocol option enables a regional external passthrough Network Load Balancer to
load balance
TCP, UDP, ESP, GRE, ICMP, and ICMPv6
traffic.
In addition to supporting protocols other than TCP and UDP, L3_DEFAULT makes
it possible for a single forwarding rule to serve multiple protocols. For
example, IPsec services typically handle some combination of ESP and
UDP-based IKE and NAT-T traffic. The L3_DEFAULT option allows a single
forwarding rule to be configured to process all of those protocols.
Forwarding rules using the TCP or UDP protocols can reference a backend
service using either the same protocol as the forwarding rule or a backend
service whose protocol is UNSPECIFIED.
L3_DEFAULT forwarding rules can only
reference a backend service with protocol UNSPECIFIED.
If you're using the L3_DEFAULT protocol, you must configure the forwarding
rule to accept traffic on all ports. To configure all ports, either set
--ports=ALL by using
the Google Cloud CLI, or set allPorts to
True by using the API.
The following table summarizes how to use these settings for different protocols.
| Traffic to be load balanced | Forwarding rule protocol | Backend service protocol |
|---|---|---|
| TCP | TCP |
TCP or UNSPECIFIED |
L3_DEFAULT |
UNSPECIFIED |
|
| UDP | UDP |
UDP or UNSPECIFIED |
L3_DEFAULT |
UNSPECIFIED |
|
| ESP, GRE, ICMP/ICMPv6 (echo request only) | L3_DEFAULT |
UNSPECIFIED |
Multiple forwarding rules
You can configure multiple forwarding rules, of which there can be two types:
Multiple forwarding rules for the same IP address. You can configure multiple forwarding rules for the same IP address as long as as long as no two forwarding rules consume the same protocol and port combinations. Each forwarding rule can have a different backend service, or multiple forwarding rules can have the same backend service.
Multiple forwarding rules the reference the same backend service. You can configure multiple forwarding rules for the same backend service. Subject to the conditions noted in the first point, two or more forwarding rules can use the same IP address, or each forwarding rule can use a unique IP address.
When using multiple forwarding rules, make sure that you configure the application running on your backend VMs so that it binds to all the external IP address(es) of the load balancer's forwarding rule(s).
Configuring multiple forwarding rules can be useful for the following use cases:
- You need to configure more than one external IP address for the same backend service. For example, one forwarding rule for an IPv4 address and another for an IPv6 address.
- You need to configure multiple forwarding rules for the same external IP address but with different protocols or non-overlapping ports or port ranges. The forwarding rules can use the same or different backend services.