Overview

A Network Load Balancer (or NLB) is a Layer 4 (TCP/UDP) load balancer that distributes incoming traffic to Compute instances managed by an Instance Pool.

A NLB is composed of several services, each bound to an Instance Pool that resides in the same zone as the NLB. Services will efficiently forward connections reaching the NLB’s IP address to the member instances of the Instance Pool.

While the instances remain individually accessible through their public IP, the NLB will expose a single IP address for all services and distribute the incoming traffic across the members of the Instance Pool following the service’s rules.

NLB services will update automatically when the Instance Pool scales up or down, distributing traffic across all reachable member instances of the pool and excluding unreachable ones by using an integrated health check functionality.

NLB acts only on incoming traffic, so all return traffic from the backend to the client that originated the request goes out directly from the pool member instance.

Network Load Balancer Services

Each NLB is composed of up to 10 services - each service with its own configuration. Each NLB service can target a different Instance Pool residing in the same zone as the NLB, and is independent from other services.

Each NLB Service is composed of the following parts:

  • A target Instance Pool
  • A load balancing strategy
  • A triplet indicating the Protocol, Service Port and Target Port for the traffic to be balanced.
  • A Health Check probe

Note

While is possible to edit and modify most of the parameters of a service, it is not possible to modify the targeted Instance Pool. Moreover, an Instance Pool cannot be deleted if it is targeted by a service.

Load balancing strategies

Several types of strategies are available during service configuration:

  • Round Robin: incoming traffic will be forwarded to each member of the Instance Pool in equal proportions and in circular order.
  • Source Hash: incoming traffic will be balanced on different members of the target Instance Pool depending on the source IP address. A given source IP address will always forward to the same Instance.
  • Maglev Hash: consistent hashing with minimal disruption. Each destination will receive an almost equal number of connections.

There is no difference in terms of raw performance between the strategies. The choice depends on your specific application and needs.

Details of the Source Hash strategy

Whereas Round Robin works for most use cases, Source Hash is generally better for stateful applications.

Source hashes ensure that the same client always goes to the same backend based on their IP address. This could be useful, for example, to create session stickyness.

However, it is important to notice that the entire hash distribution is recalculated when the state of the backend nodes changes. This recalculation happens:

  • When an Instance Pool member instance is added (scaling up).
  • When an Instance Pool member instance is deleted (scaling down).

Note The source hash is NOT recalculated in case of a health check failure.

Details of the Maglev Hash strategy

Maglev-hash offers a sophisticated approach with minimal disruption during server changes and optimal load distribution, making it suitable for large-scale, dynamic environments. It minimizes changes in load distribution when servers are added or removed, ensuring high availability and reliability; provides near-optimal load distribution and quick recovery.

Protocol, service port and target port

For each service you will provide the protocol of the traffic to be balanced (either TCP or UDP) and a pair of ports:

  • Service port, the port on which the NLB Service has to listen for the incoming traffic.
  • Target port, the port on which the NLB Service has to forward the traffic. This is the port on which the members of the Instance Pool will actually receive the forwarded traffic.

Warning

Your Instance Pool security groups need to have an open ingress rule on the designated target port to work.

Health check parameters

Each NLB Service comes with an integrated, non-optional health check mechanism.

Each member of the target Instance Pool will be regularly contacted using the health check parameters you provide. When the health check probe is marked as failed, the NLB will no longer forward traffic to that node.

The health check parameters are:

  • Protocol: the protocol the health check has to use to contact the pool member, either TCP, HTTP or HTTPS.
  • TLS-SNI: this parameter can be set when the protocol is HTTPS. It allows configuration of the server name indication of the health check.
  • Port: the port on which the health check must be performed. This can be a different port than the target port used to forward the traffic, or the same one depending on your own setup. As for the target port, your target Instance Pool Security Groups must allow incoming traffic on the health check port.
  • Path: the URI relative to the machine IP address to be used for HTTP health checks. The path starts with / that will be added to the target Instance IP.
  • Interval: the time in seconds between health check calls.
  • Timeout: the time in seconds until the request is dropped and the health check call is considered failed.
  • Retries: the number of subsequent failed health check calls needed to consider the member is down.

The health check probe will try to contact each member of the Instance Pool with the designated method and at the indicated interval:

  • HTTP health checks will seek a 2XX status code
  • TCP health checks will verify that it is possible to establish a connection on the specified port

The health check status of the NLB member will change from success to failure after the indicated amount of failed retries.

No traffic will be forwarded to an instance if its health check status is marked as failure. The health check probe will continue to try to reach the Instance, and as soon as the check succeeds, it will change the status back to success and resume traffic forwarding.

Warning

Your Instance Pool Security Groups needs to have an open ingress rule on the designated health check port to work.

Labels

Network Load Balancer supports labels.

Limitations

  • Network Load Balancers are limited by default to 5 per account. Please note that each NLB will count towards your Elastic IP quota as well. Please contact our support if you need to increase your quota.
  • Network Load Balancers only work with Instance Pools. It is not possible to provide an arbitrary list of instances as a target.
  • Each NLB can have up to 10 Services at most.
  • NLB only forwards connections to Instance Pool members. It is not possible to terminate TCP or SSL/TLS connections with NLB.
  • Once a service is created, it is not possible to modify its target Instance Pool.
  • Names of NLBs need to be unique in the context of an organization.
  • Names of NLB Services need to be unique in the context of the NLB itself.