---
name: vpc-nlb-about
title: About network load balancers
description: You can use the IBM Cloud® Network Load Balancer for VPC (NLB) to distribute traffic among multiple server instances within the same region of your VPC.
last-updated: 2026-08-19
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/vpc?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# About network load balancers
{: #network-load-balancers}

You can use the IBM Cloud® Network Load Balancer for VPC (NLB) to distribute traffic among multiple server instances within the same region of your VPC.
{: shortdesc}

NLBs can accept members across all three availability zones, but the NLB itself resides in one specific zone. For more information, see [Multi-zone support](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vs-elb&format=markdown#nlb-mz-support).

It is possible to assign ports per customer, but there is no port enforcement at the VP gateway level.
{: important}

## Types of network load balancers
{: #types-network-load-balancers}

As discussed in the [Load balancers for VPC overview](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vs-elb&interface=ui&format=markdown), many types of NLBs are available:

* **Public** - A public load balancer is a load balancer with a publicly accessible IP address that is registered with DNS.
* **Private** - A private load balancer is only accessible from within the VPC network, where the client is in the same VPC or has reachability (for example, through Direct Link, Transit Gateway, or both). For private load balancers, you must have a dedicated subnet with no custom routes configured for the subnet.
* **Private with routing mode enabled** - Private NLBs with routing mode enabled support Virtual Network Function (VNF) devices as back-end targets. They perform direct routing without any NAT, enabling VNF devices to inspect packets as-is.

   Both symmetric and asymmetric traffic are supported where multiple private NLBs with routing mode in each zone can receive traffic asynchronously at any time using [weighted forwarding](https://cloud.ibm.com/docs/vpc?topic=vpc-network-load-balancers&format=markdown#weighted-forwarding-method). For more information, see [Creating a network load balancer with routing mode](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vnf&interface=ui&format=markdown).

* **Private Path** - Service providers use Private Path NLBs to securely connect IBM Cloud with third-party, VPC-hosted services on the IBM Cloud private network. Private Path NLBs are required when you use [Private Path services](https://cloud.ibm.com/docs/vpc?topic=vpc-private-path-service-intro&format=markdown) to keep network traffic on a private path that never intersects with the internet. For more information, see the [Private Path solutions guide](https://cloud.ibm.com/docs/private-path?format=markdown).

   Private Path NLBs can only be used with a Private Path service.
   {: important}

## Getting started
{: #nlb-getting-started}

To get started using network load balancers, follow these steps:

1. Review [Known issues for network load balancers](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-limitations&format=markdown).
1. Follow instructions for your particular NLB:
   * [Create a public or private network load balancer](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-ui-creating-network-load-balancer&format=markdown).
   * [Create a private network load balancer with routing mode](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vnf&format=markdown).
   * [Create a Private Path network load balancer](https://cloud.ibm.com/docs/vpc?topic=vpc-ppnlb-ui-creating-private-path-network-load-balancer&format=markdown).

For more information, see [Types of load balancers](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vs-elb&interface=ui&format=markdown#load-balancer-types) and the [Load balancer comparison chart](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-vs-elb&interface=ui&format=markdown#lb-comparison-chart).
{: note}

## Load-balancing methods
{: #network-load-balancing-methods}

Three load-balancing methods are available for distributing traffic across back-end application servers: round-robin, weighted round-robin, and least connections.

### Least connections
{: #least-connections-method}

With this method, the back-end server instance that serves the least number of connections at a particular time receives the next client connection.

Private Path NLBs don't support the least-connection method.
{: important}

### Round-robin
{: #round-robin-method}

Round-robin is the default load-balancing method. With this method, the load balancer forwards incoming client connections in a round-robin fashion to the back-end servers. As a result, all back-end servers receive roughly an equal number of client connections.

### Weighted forwarding
{: #weighted-forwarding-method}

Weighted forwarding is supported only on private NLBs that use routing mode.
{: note}

With weighted forwarding, the NLB uses a IP-hash algorithm to distribute packets across targets based on their assigned weights. Because weighted forwarding is stateless, the NLB does not maintain connection state. Instead, each packet is evaluated independently based on its headers and forwarded according to the current hash result and configured weights. As a result, traffic is accepted and forwarded even when no existing connection state is present.

This behavior enables support for asymmetric routing scenarios, including deployments where same-zone traffic flows are not symmetric, such as when using a public address range IP. Another supported scenario is a multi-zone deployment where private NLBs configured with the `weighted_forwarding` pool algorithm can receive traffic asynchronously in any zone. For symmetric traffic flows, the NLB continues to provide deterministic hash-based forwarding similar to other pool algorithms, making weighted forwarding suitable for any route-mode NLB deployment.

If a route-mode NLB becomes unhealthy due to an unhealthy zone or no healthy back-end members remain, the NLB automatically withdraws its associated VPC ingress routing advertisement. Traffic is then redirected to healthy route-mode NLBs in healthy zones.

For example, consider a route-mode private NLB with two healthy back-end members, Server A with a weight of `8` and Server B with a weight of `2`. Out of 1,000 incoming packets, approximately 800 packets are forwarded to Server A and 200 packets are forwarded to Server B. But because weighted forwarding is stateless, the NLB does not maintain connection state. Each packet is evaluated independently using packet header information and forwarded according to the current hash result and configured weights. This means that packets that belong to the same flow can arrive and return through different route-mode NLBs and still be forwarded successfully, even when the observed distribution differs from the configured weight ratio.

This behavior enables asymmetric routing scenarios. For more information, see [Use case 8: Multi-zone, high availability using asymmetric routing](https://cloud.ibm.com/docs/vpc?topic=vpc-network-load-balancers&format=markdown#multi-zone-ha-using-asymmetric-routing).

### Weighted round-robin
{: #weighted-round-robin-method}

With this method, the load balancer forwards incoming client connections to the back-end servers in proportion to the weight assigned to these servers. Each server is assigned a default weight of `50`, which can be customized to any value in the range `0 - 100`.

For example, if application servers A, B, and C have the weights `60`, `60`, and `30`, then servers A and B receive an equal number of connections, while server C receives half that number of connections.

The server weight values are applicable only with the weighted round-robin method. They are ignored with the round-robin and least connections load-balancing methods.

Setting a server weight to `0` means that no new connections are forwarded to that server, but any existing traffic continues to flow. Using a weight of `0` can help to gradually bring down a server and remove it from service rotation.
{: tip}

## Front-end listeners and back-end pools
{: #nlb-front-end-listeners-and-back-end-pools}

Front-end listeners are application ports for load balancers to receive incoming requests while back-end pools are the application servers behind the load balancers. You can define up to 10 front-end listeners and map them to back-end pools on the back-end application servers. For a public NLB, the FQDN assigned to your load balancer and the front-end listener ports are exposed to the internet. Incoming user requests are received on these ports. TCP and UDP are the supported protocols for front-end listeners and back-end pools.

You can attach up to 50 virtual server instances to a back-end pool. Traffic is sent to each instance on its specified data port. This data port does not need to be the same as the front-end listener port.

### Back-end pool failsafe policies
{: #nlb-back-end-pool-failsafe-policies}

When editing a back-end pool in a load balancer, you can specify one of the following failsafe policy actions:

* **Forward:** - The load balancer routes requests to a designated backup pool. This provides a clean failover path to another set of application servers. You must have an existing backup pool configured and ready to receive traffic.
* **Bypass:** - The load balancer sends requests directly to the member's destination IP addresses, bypassing the load balancer completely. This option is typically used in specific networking setups, such as with Network Load Balancers and virtual network function (VNF) devices.
* **Drop:** -  The load balancer drops all incoming requests, and the client receives no response.

You can choose a failsafe target from a list of applicable backup pools.

**Failsafe Target pool requirements (if action is Forward):**
* must belong to the same load balancer
* must have the same or compatible protocol (TCP is only compatible with TCP, but any combination of HTTP and HTTPS is compatible)

## Maximum connections
{: #nlb-maximum-connections}

There is no defined number of default connections or maximum connections for a network load balancer. The total number of concurrent connections depends on factors, such as allocated resources and network throughput.

## VPC representation of a network load balancer
{: #vpc-nlb-representation}

Figure 1 shows the VPC representation of a typical network load balancer setup. The NLB is provisioned on a VPC subnet. To configure the network data path on the NLB, a listener, a pool, and at least one member must be created. A _listener_ is the front-end port that the NLB is listening on for customer requests. These requests are forwarded to the targets in the pool that is associated with the listener. A _pool_ is a group of targets that are used to distribute the network requests coming into the NLB for a specific listener. A _member_ is a back-end server with a specified port that is configured to listen for requests.

![Network load balancer work flow](images/nlb-workflow-customer-view.svg "Network load balancer work flow"){: caption="Network load balancer work flow" caption-side="bottom"}

## Layer 4 load balancing
{: #nlb-layer4}

Network Load Balancer for VPC provides a layer 4 (known as the transport layer) load-balancing service to the user’s servers in a VPC. It decides where traffic is directed based on the source and destination IP addresses and the port in the packet header. The load balancer does not perform a check on the contents of the packet.

Since layer 4 load balancing requires fewer computations compared to more sophisticated load balancing, such as layer 7, CPU usage and memory are used more efficiently.

## Use case 1: Public network load balancer
{: #nlb-use-case-1}

A public NLB supports Direct Server Return (DSR). Application load balancers do not support this capability.

Figure 2 illustrates how a public NLB works. The Consumer registers the load balancer’s IP address with DNS using the load balancer’s FQDN. The Consumer optionally queries the DNS server. DNS responds with the load balancer’s IP address. The Consumer sends a TCP request to the load balancer for data, and the load balancer forwards the request to a back-end target. The target generates a response and the response is sent directly to the Consumer with DSR.

![Public load balancer](images/lb_use_case_1.svg "Public load balancer"){: caption="Public load balancer" caption-side="bottom"}

## Use case 2: Private network load balancer
{: #nlb-use-case-2}

A private NLB is accessible only from within the VPC network, where the Consumer has reachability (for example, through Direct Link, Transit Gateway, or both).

For private load balancers, you must have a dedicated subnet with no custom routes configured for the subnet.
{: important}

Figure 3 illustrates how a private NLB works. The Consumer queries DNS for the load balancer’s IP address using the load balancer’s FQDN. The Consumer optionally queries the DNS server. DNS responds with the load balancer’s IP address. The Consumer sends a TCP request to the load balancer for data through a direct link or transit gateway, and the load balancer forwards the request to a back-end target. The target generates a response and the response is sent directly to the Consumer using DSR.

![Private load balancer](images/lb_use_case_2.svg "Private load balancer"){: caption="Private load balancer" caption-side="bottom"}

## Use case 3: Private network load balancer with routing mode enabled
{: #nlb-use-case-3}

NLBs with `route_mode` set to `true` are private load balancers that support only virtual network function (VNF) appliances, such as a firewall, as back-end targets.
{: important}

Figure 4 illustrates how a private NLB with routing mode works. The Consumer queries DNS for the load balancer’s IP address using the load balancer’s FQDN. The Consumer optionally queries the DNS server. DNS responds with the load balancer’s IP address. The Consumer sends a TCP request to the load balancer for data through a direct link or transit gateway. The load balancer forwards the request to VNF devices then to back-end targets. The target generates a response and that response is sent back to the NLB, then again to VNF devices before returning to the client.

![Private load balancer with routing mode enabled](images/lb_use_case_3.svg "Private load balancer with routing mode enabled"){: caption="Private load balancer with route mode enabled" caption-side="bottom"}

Multiple private NLBs with routing mode enabled in each zone can receive traffic asynchronously at any time. If a route-mode NLB becomes unhealthy, it stops receiving traffic, and traffic automatically shifts to healthy route-mode NLBs in the zone. For more information, see [weighted forwarding](https://cloud.ibm.com/docs/vpc?topic=vpc-network-load-balancers&format=markdown#weighted-forwarding-method).
{: note}

## Use case 4: Multi-zone, high availability using a network load balancer
{: #nlb-use-case-4}

Figure 5 illustrates how you can deploy an NLB to support multiple zones. This deployment scenario often requires the use of the global load balancer (GLB) option in [IBM Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis?topic=cis-configure-glb&format=markdown).

A [known limitation](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-limitations&format=markdown#limitations-network-load-balancers) exists for this use case. Two members with the same instance and port cannot exist at the same time. Instead, you can use a different port with the same instance.
{: important}

You might want to leverage the high throughput performance (and low latency) the NLB gains through DSR. In addition, it is recommended that you deploy your workloads in multiple zones to increase their availability in a High Availability (HA) environment.

You can use this deployment scenario to obtain high availability and ensure workloads are available across multiple availability zones in case there is a load balancer failure. If a failure condition happens to a load balancer in one availability zone, then the GLB no longer sends traffic to that availability zone. For example, if a failure happens in availability zone 1, the GLB sends traffic to availability zone 2 or availability zone 3. Examples scenarios can include a large of failures, everything from a single NLB, all the way to an entire availability zone.

![Multi-zone public network load balancer](images/lb_use_case_5.svg){: caption="Multi-zone network load balancer" caption-side="bottom}

The requirement of one NLB per zone is only needed for Public and Private NLB. Private Path NLB is regional by nature, so there is no need to define one per zone. 
{: note}

## Use case 5: Private Path network load balancer
{: #nlb-use-case-5}

A Private Path NLB keeps all traffic checkpoints between the Provider and the Consumer within the IBM Cloud infrastructure. Data does not exit to the internet.

Unlike other NLBs, a Private Path network load balancer provides regional availability and is resilient to zone failure even if a single subnet is selected. You do not need to create multiple Private Path load balancers or specify more than a single subnet to ensure resiliency to zone failure. Your subnet selection only impacts the IP-addresses associated with the load balancer.

You can only use Private Path NLBs with a Private Path service. For more information, see [About Private Path services](https://cloud.ibm.com/docs/vpc?topic=vpc-private-path-service-intro&format=markdown).
{: important}

Figure 6 illustrates how a Private Path NLB works to support a Private Path service. The Private Path NLB registers with the DNS server. The Consumer optionally queries the DNS server. The Consumer then sends a TCP request for data to the Private Path NLB through a VPE gateway, and the Private Path NLB forwards the request to the targets. In turn the targets generate a response, that response is sent by direct-server-return to the VPE, and then is sent to the Consumer.

![Private path network load balancer](images/lb_use_case_4.svg "Private path network balancer"){: caption="Public load balancer" caption-side="bottom"}

## Use case 8: Multi-zone, high availability using asymmetric routing
{: #multi-zone-ha-using-asymmetric-routing}

The following configuration can be used only with a private NLB that has routing mode enabled.
{: note}

Figure 9 illustrates how private route-mode NLBs can provide multi-zone high availability through asymmetric routing. First, a consumer sends a request to the provider's hub VPC through a private connectivity path, such as VPN, Direct Link, or Transit Gateway. The provider's private route-mode NLB sends the request through a transit gateway to virtual server instances in the spoke VPC. With weighted forwarding enabled, return traffic can follow a different path than the original request without relying on previously established connection state.

For example, a request packet might enter through the NLB in Availability Zone 1 and be forwarded to a virtual server instance in the spoke VPC, while the response packet returns through the NLB in Availability Zone 2. Because forwarding is independent of the original connection path, the response is accepted and forwarded correctly. Configured weights continue to influence how traffic is distributed across backend virtual server instances while maintaining multi-zone high availability.

Furthermore, if a zone becomes unavailable or a Route Mode Network Load Balancer (NLB) no longer has any active firewall instances associated with it, the corresponding route advertisement is automatically withdrawn. This dynamic route withdrawal mechanism prevents traffic from being directed to unhealthy service endpoints and enables regional high availability (HA) by ensuring traffic is routed only through operational VNF-based firewall devices.

![Multi-zone, high availability using asymmetric routing](images/lb_use_case_8.svg){: caption="Multi-zone, high availability using asymmetric routing" caption-side="bottom}

## Related links
{: #nlb-permissions-related-links}

* [Load balancer CLI reference](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&format=markdown#lb-anchor)
* [Load balancer API reference](https://cloud.ibm.com/docs/apis/vpc#list-load-balancer-profiles)
* [Load balancer resources for Terraform](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_lb){: external}
* [Managing IAM access for VPC Infrastructure Services](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started&interface=ui&format=markdown)
* [Activity tracking events](https://cloud.ibm.com/docs/vpc?topic=vpc-at_events&format=markdown#events-load-balancers)
* [FAQ for network load balancers](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-faqs&format=markdown)
* [Quotas and service limits](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas&interface=ui&format=markdown#nlb-quotas)