Proxy Network Load Balancer overview Stay organized with collections Save and categorize content based on your preferences.
Proxy Network Load Balancers are layer 4 reverse proxy load balancers that distributeTCP traffic to backends in your Google Cloud Virtual Private Cloud (VPC)network or in other cloudenvironments. Traffic is terminated at the load balancing layer and thenforwarded to the closest available backend by using TCP.
Proxy Network Load Balancers are intended for TCP traffic only, with or without SSL.For HTTP(S) traffic, we recommend that you use an Application Load Balancerinstead.
The proxy Network Load Balancers support the following features:
- TLS/SSL offload for external load balancers. You can use aglobal external proxy Network Load Balancer or a classic proxy Network Load Balancer to offload TLS atthe load balancing layer by using an SSL proxy.
- Support for all ports. These load balancers allow any valid port from1-65535. For more information, seePortspecifications.
- Port remapping. The port used by the load balancer's forwarding rule doesnot have to match the port used when making connections to its backends. Forexample, the forwarding rule could use TCP port 80, while the connection tothe backends could use TCP port 8080.
- Relays original source IP address. You can use the PROXY protocol torelay the client's source IP address and port information to the load balancerbackends.
The following diagram shows a sample proxy Network Load Balancer architecture.
Proxy Network Load Balancers are available in the following modes of deployment:
External proxy Network Load Balancer: Load balances traffic that comes from clientson the internet. For architecture details, seeExternal proxy Network Load Balancerarchitecture.
Deployment mode Network service tier Load-balancing scheme† IP address Frontend ports Global external Premium Tier EXTERNAL_MANAGED IPv4
IPv6Can reference exactly one port from 1-65535 Classic Global in Premium Tier
Regional in Standard Tier
EXTERNAL IPv4
IPv6 (requires Premium Tier)Regional external Premium or Standard Tier EXTERNAL_MANAGED IPv4 Internal proxy Network Load Balancer: Load balances traffic within yourVPC network or networks connected to your VPCnetwork. For architecture details, seeInternal proxy Network Load Balancerarchitecture.
Deployment mode Network service tier Load-balancing scheme† IP address Frontend ports Regional internal Premium Tier INTERNAL_MANAGED IPv4 Can reference exactly one port from 1-65535 Cross-region internal Premium Tier INTERNAL_MANAGED IPv4
† The load-balancing scheme is an attribute on theforwarding rule and thebackend service of a loadbalancer and indicates whether the load balancer can be used for internal orexternal traffic. The term*_MANAGED in the load-balancing schemeindicates that the load balancer is implemented as a managed service onGoogle Front Ends(GFEs) or as a managed service on the open sourceEnvoy proxy. In aload-balancing scheme that is*_MANAGED, requests are routedeither to the GFE or to the Envoy proxy.
External proxy Network Load Balancer
The external proxy Network Load Balancer distributes traffic that comes from the internet tobackends in your Google Cloud VPC network, on-premises, orin other cloud environments. These load balancers can be deployed in one of thefollowing modes:global, regional, or classic.
External proxy Network Load Balancers support the following features:
- IPv6 termination. The external load balancers support both IPv4 andIPv6addresses for client traffic. ClientIPv6 requests are terminated at the load balancing layer and then proxiedover IPv4 to your backends.
TLS/SSL offload. You can use a global external proxy Network Load Balancer or aclassic proxy Network Load Balancer to offload TLS at the load balancing layer by usingan SSL proxy. New connections are forwarded to the closest available backendsby using either SSL (recommended) or TCP. You can configure the followingaspects of your deployment:
- Better utilization of backends. SSL processing can be veryCPU-intensive if the ciphers used are not CPU efficient. To maximize CPUperformance, use ECDSA SSL certificates and TLS 1.2, and prefer the
ECDHE-ECDSA-AES128-GCM-SHA256cipher suite for SSL between the loadbalancer and your backend instances. - SSL policies.SSLpolicies give you the abilityto control the features of SSL that your load balancer negotiates withclients.
- Better utilization of backends. SSL processing can be veryCPU-intensive if the ciphers used are not CPU efficient. To maximize CPUperformance, use ECDSA SSL certificates and TLS 1.2, and prefer the
Integration with Cloud Armor. You can useCloud Armor security policiesto protect your infrastructure from distributed denial-of-service (DDoS)attacks and other targeted attacks.
Geographic control over where TLS is terminated. The load balancerterminates TLS in locations that are distributed globally, so as to minimizelatency between clients and the load balancer. If you require geographiccontrol over where TLS is terminated, you can use the Standard Network Tier toforce the load balancer to terminate TLS on backends that are located in aspecific region only. For details, seeConfiguring StandardTier.
Support for App Hub. Resources used byglobal external proxy Network Load Balancers and regional external proxy Network Load Balancers can bedesignated as services inApp Hub applications.
In the following diagram, traffic from users in City A and City B is terminated atthe load balancing layer, and a separate connection is established to theselected backend.
For more details, seeExternal proxy Network Load Balancer overview.
Internal proxy Network Load Balancer
Theinternal proxy Network Load Balancer is an Envoyproxy-based regional Layer 4 load balancer that lets you run and scaleyour TCP service traffic behind an internal IP address that is accessible onlyto clients in the same VPC network or clients connected to yourVPC network.
The load balancer distributes TCP traffic to backends hosted onGoogle Cloud, on-premises, or in other cloud environments. These loadbalancers can be deployed in one of the following modes:cross-region orregional.
Internal proxy Network Load Balancers support the following features:
- Locality policies. Within a backend instance group or network endpointgroup, you can configure how requests are distributed to member instances orendpoints.
- Global access. When global access is enabled, clients from any region canaccess the load balancer.
- Access from connected networks. You can make your internal load balanceraccessible to clients from networks beyond its own Google CloudVPC network. The other networks must be connected to the loadbalancer's VPC network by using either VPC Network Peering,Cloud VPN, or Cloud Interconnect.
- Support for App Hub. Resources used byglobal internal proxy Network Load Balancers and regional internal proxy Network Load Balancers can bedesignated as services inApp Hub applications.
For more details, seeInternal proxy Network Load Balancer overview.
High availability and cross-region failover
You can set up a cross-region internal proxy Network Load Balancer in multiple regions to get thefollowing benefits:
If backends in a particular region are down, thetraffic fails over to the backends in another region gracefully.
The cross-region failover deployment example shows the following:
- A cross-region internal proxy Network Load Balancer with a frontend VIP address in theRegion A of your VPC network. Your clients are alsolocated in the Region A.
- A global backend service that references the backends in theGoogle Cloud Region A and Region B.
- When the backends in the Region A are down, trafficfails over to the Region B.
Cross-region internal proxy Network Load Balancer with a cross-region failover deployment (click to enlarge). Cross-region internal proxy Network Load Balancers can also shield your application fromcomplete regional outages by serving traffic to your client from proxiesand backends in another region.
The high availability deployment example shows the following:
- A cross-region internal proxy Network Load Balancer with frontend VIPs in the Region A and Region B of your VPC network. Your clients arelocated in the Region A.
You can make the load balancer accessible by using frontend VIPs from tworegions.
Cross-region internal proxy Network Load Balancer with high availability deployment (click to enlarge).
For information about how to set up a high availability deployment, see:
- Set up a cross-region internal proxy Network Load Balancer with VM instance group backends
- Set up a cross-region internal proxy Network Load Balancer with hybrid connectivity
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-15 UTC.