Overview

A Network Load Balancer (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 residing in the same zone as the NLB itself. Services will efficiently forward connections reaching the NLB IP to the members of the Instance Pool.

While the underlying 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 automatically be updated when the Instance Pool is scaled up or down, distributing traffic across all reachable members of the pool, and excluding unreachable ones thanks to an integrated health check functionality.

NLB acts only on incoming traffic, meaning that all return traffic from the backend to the client that originated the request goes out directly from the pool member, granting best performance.

Network Load Balancer Services

Each NLB is composed by up to 10 Services, each one with its own configuration. Each NLB Service can target a different Instance Pool living in the same zone as the NLB itself, and is independent from others Services.

Each NLB Service is composed by 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.
  • An 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 Strategy

Two types of strategy 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 be forwarded to the same Instance.

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

Details of the Source Hash Strategy

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

Source hashes provide a way to ensure that the same client always goes to the same backend based on their IP address. This may be useful e.g. 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 notably happens:

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

The source hash is NOT recalculated in case of an Health Check Failure.

Protocol, Service Port and Target Port

For each service you’ll have to 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 incoming traffic.
  • Target Port, the port to which the NLB Service has to forward 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 (HC).

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

The HC parameters are:

  • Protocol, the protocol the HC 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 us to configure the Server Name Indication of the healthcheck.
  • Port, the port on which the HC must be performed. This can be a different port than the Target Port used to forward traffic, or the very same one depending on your own setup. As for the Target Port, your target Instance Pool Security Groups must allow incoming traffic on the HC port.
  • Path, the uri relative to the machine IP address to be used for HTTP health checks. This is, a path starting with / that will be added to the target Instance IP.
  • Interval, the time in seconds between HC calls.
  • Timeout, the time in seconds until the request is dropped and the HC call considered failed.
  • Retries, the number of subsequent failed HC calls needed to consider the member down.

The HC 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 HC 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 it’s HC status is marked as ‘failure’. The HC 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 need to have an open ingress rule on the designated HC Port to work.

Limitations

  • Network Load Balancers are limited by default to 5 per account. Please note that each NLB will count towards your EIP quota as well. Please contact our support should you need more resources.
  • 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 maximum.
  • NLB does not terminate connections, it only forwards them to the member of the Instance Pool. It is not possible to terminate TCP or SSL/TLS connections with it.
  • Once a Service is created, 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.