Jump toUpdate content

Load Balancers - Concepts


Access Control Lists (ACLs) allow you to control traffic arriving at your Load Balancer's frontend, and set conditions to allow traffic to pass to the backend, deny traffic from passing to the backend, or redirect traffic. Conditions can be set based on the traffic's source IP address and/or HTTP path and header, or you can choose to carry out unconditional actions. ACLs allow you to build extra security into your Load Balancer, as well as letting you redirect traffic, for example from HTTP to HTTPS.

Learn how to use the ACL feature in our dedicated how-to and go deeper with our reference documentation


When creating a Load Balancer, you are prompted to configure its accessibility. There are two options: private or public:

  • Private: A private Load Balancer has no public IP address, and is only accessible from the Private Network(s) it is attached to. Read more about private Load Balancers.
  • Public: A public Load Balancer is accessible from the internet via its public IP address.

Accessibility cannot be modified after creation of the Load Balancer.


Each Load Balancer is configured with one or several backends. A backend represents a set of backend servers that the Load Balancer’s frontend forwards requests to using the specified configuration (port, protocol, proxy protocol etc.). Grouping backend servers into a backend allows load to be balanced between them based on a defined load-balancing algorithm configured as a backend setting. You can add and manage backends via the console.

Backend servers

The term “backend server” designates the final-destination backend servers which the Load Balancer forwards traffic on to. Each of the Load Balancer’s backends must specify one or more backend servers (via their IP addresses) to forward to.

Backend protection

Backend protection is a set of configurable values that allow you to control how load is distributed to backend servers. You can use these settings to configure the maximum number of simultaneous requests to a given backend server before it is considered to be at maximum capacity. You can also configure a queue timeout value, which defines the maximum amount of time (in ms) to queue a request or connection for a particular backend server when stickiness is enabled. Once this value is reached, the request/connection will be directed to a different backend server.

Balancing methods

Load Balancers support three different modes of balancing load (requests) between backend servers:

  • Round-robin: Requests are sent to each backend server in turn, with the Load Balancer acting like a turnstile. This is the most frequently used balancing method, and the easiest to implement. It is well-suited to infrastructures that have identical backend servers.

  • Least connections: Each request is assigned to the server with the fewest active connections. This method works best when it is expected that sessions will be long, e.g. LDAP, SQL TSE. It is less well suited to protocols with typically short sessions like HTTP.

  • First available: Each request is directed towards the first backend server with available connection slots. Once a server reaches its limit of maximum simultaneous connections, requests are directed to the next server. This method uses the smallest number of servers at any given time, which can be useful if, for example, you sometimes want to power off extra servers during off-peak hours.

For more information about balancing rules, refer to our blog post “What is a load balancer”


A certificate (aka SSL certificate / TLS certificate / TLS/SSL certificate) is a digital certificate that enables an encrypted connection between a client and a web server.


You may hear certificates referred to as “SSL certificates”, “TLS certificates” or “TLS/SSL certificates”. These are all the same thing. SSL (Secured Socket Layer) was the protocol initially used for encryption, though it has now been replaced with TLS (Transport Layer Security).

You can add a certificate to your Load Balancer’s frontend to enable the Load Balancer to decrypt/encrypt traffic, necessary for SSL bridging and SSL offloading configurations. Scaleway Load Balancer enables you to generate a Let’s Encrypt certificate, or import a third-party or self-signed certificate.

Connection timeout

Connection timeout is a configurable value for your Load Balancer’s backend. It defines the maximum time (in ms) allowed to establish a connection between a client and a backend server.

First available


Each Load Balancer is configured with one or several frontends. Frontends listen on a configured port, and forward requests to one or several backends. You can add and manage frontends via the console.

Flexible IP address

Flexible IP addresses are public IP addresses that you can hold independently of any Load Balancer. By default, each Load Balancer is created automatically with a flexible IP address, that the frontend listens to. In case of a failure of the Load Balancer, a replica Load Balancer is immediately spawned and deployed, and the flexible IP address is automatically rerouted to this replica.

Health checks

Load Balancers should only forward traffic to “healthy” backend servers. To monitor the health of a backend server, health checks regularly attempt to communicate with backend servers using the protocol and port defined by the forwarding rules to ensure that servers are listening. Various protocols for health checks are available, including HTTP, HTTPS, MySQL, and more.

Various advanced settings can be configured for health checks, including:

  • Interval: The interval between consecutive health checks.
  • Timeout: The maximum amount of time a backend server has to respond to a health check, before the health check is considered as failed.
  • Unhealthy threshold: The number of consecutive failed health checks after which a backend server is diagnosed as unhealthy, and its status is changed to Down. Requests/connections will no longer be forwarded to servers with a down status.
  • Interval (transient state): The interval between two consecutive health checks when a server is in a transient state. Note that a backend server is in a transient state when:
    • It is considered up, but then fails a health check. It stays in this transient state until the number of consecutive unsuccessful health checks goes above the unhealthy threshold, at which point it switches to down.
    • It is considered down, but then passes a health check. It stays in this transient state until the number of consecutive successful health checks goes above two, at which point it switches to up.

Read more about health checks.

High availability

A high availability (HA) setup is an infrastructure without a single point of failure. It prevents a server failure by adding redundancy to every layer of your architecture.

HTTP headers

HTTP headers are a list of strings in the format header-name: value used by the client and server to send and receive additional information between themselves for each HTTP request and response. Headers give more details about the client request, the targeted resources, the request response, and other options desired for that particular connection between client and server. There are approximately 100 different HTTP header fields.

Scaleway Load Balancers can use the Host header field to define routes from a frontend to a specified HTTP backend. HTTP headers can also be used in ACLs to allow, deny or redirect traffic based on the specified header field and value.

HTTP/2 and HTTP/3

HTTP/2 and HTTP/3 are newer, improved versions of the “classic” HTTP/1 protocol. Scaleway Load Balancers support HTTP/2 connections to frontends, and HTTP/2 connections from backends to backend servers. In addition, Scaleway Load Balancers support HTTP/3 connections to frontends, but do not support HTTP/3 connections from backends to backend servers.

Read more about HTTP/2 and HTTP/3 and how they can be configured on Scaleway Load Balancers in our dedicated documentation.

Least connections

Load Balancers

Load Balancers are highly available and fully managed instances that allow you to distribute workload across multiple servers. They ensure the scaling of all your applications while securing their continuous availability, even in the event of heavy traffic. They are commonly used to improve the performance and reliability of websites, applications, databases and other services.

Private Load Balancer

A Load Balancer is defined as private when you choose the “private” accessibility option during Load Balancer creation. A Private Load Balancer has the following characteristics:

  • It has no public IP address for sending requests or initiating TCP connections.
  • It only listens to requests or connections sent to its interface(s) on the Private Network(s) it is attached to. It is not accessible over the public internet.
  • Like a public Load Balancer, it can be attached to up to eight different Private Networks.
  • It can be configured or deleted using the Scaleway API, console, CLI, Terraform, or other devtools.
  • It provides its metrics to Scaleway Cockpit, even though there is no traffic.
  • It does not allow the use of a Let’s Encrypt certificate - only imported certificates are supported.
  • It does not support multicloud IP addresses for its backend servers, since it is not directly connected to the Internet. Routes to them are thus, not guaranteed.

A private Load Balancer can be used to balance requests between backends internally, where your backends’ clients are in the same Private Network as the Load Balancer. The security of your infrastructure is strengthened, as the Load Balancer does not have a public IP address and is not accessible over the public internet.

When you attach a private Load Balancer to multiple Private Networks, it has an IP address in each one. The Load Balancer can then forward traffic to any resource or service attached to any of its Private Networks, thus allowing inter-Private-Networks load balancing. Scaleway’s managed DNS also makes it possible to contact the Load Balancer over the Private Network without knowing its IP address (using lb-name.pn-name, which then resolves to its private IP address).


A protocol is a standard format for communication over a network. When you configure your Load Balancer’s backend, you choose a protocol (HTTP, HTTPs or TCP) which it uses to send and receive data.

Proxy protocol

Proxy protocol is an internet protocol used to transfer connection information from the client (e.g. the client’s IP address), through the Load Balancer and on to the destination server.



Routes allow you to specify, for a given frontend, which of its backends it should direct traffic to. For HTTP frontends/backends, routes are based on HTTP Host headers. For TCP frontends/backends, they are based on Server Name Identification (SNI). You can configure multiple routes on a single Load Balancer.

S3 failover

S3 failover is a feature that allows you to redirect users to a static website hosted on Scaleway Object storage, in the case that none of your Load Balancer’s backends are available.

Server Name Identification (SNI)

SNI allows the server to host multiple SSL/TLS certificates for multiple sites/applications on the same IP address and port number. It works as an extension to the TLS protocol: the client/browser specifies which hostname it is requesting at the start of the TLS handshake, allowing the server to respond appropriately.

Scaleway Load Balancers can use SNI to define routes from a frontend to a specified TCP backend.

Server timeout

Server timeout is a configurable value for your Load Balancer’s backend. It defines the maximum allowed time (in ms) that a backend server has to process a request.

SSL bridging

SSL bridging describes a configuration pattern where the Load Balancer terminates encrypted connections at the frontend (decrypting incoming traffic) before initiating a new encrypted connection to the backend before forwarding traffic.

SSL offloading

SSL offloading describes a pattern where the Load Balancer terminates encrypted connections at the frontend (decrypting incoming traffic), with the intention to forward it unencrypted to the backend servers. This effectively “offloads” the work of decrypting traffic from the backend server to the Load Balancer.

SSL passthrough

SSL passthrough is the simplest way to handle HTTPS traffic on a Load Balancer. As the name suggests, traffic is simply passed through the Load Balancer without being decrypted.

Sticky session

A sticky session enables the Load Balancer to bind a user’s session to a specific server in the backend pool. This ensures that all subsequent sessions from the user are sent to the same backend server while there is at least one active session. Sticky sessions can be cookie based or table based.

  • Cookie-based stickiness uses an HTTP cookie to identify a session, and the server in the backend pool that it will stick to. For each incoming request without a stickiness cookie, the Load Balancer creates a cookie and selects a backend for the session. Subsequent requests providing this cookie will land on the same backend. You can customize the name of the cookie.
  • Table-based (aka IP-based) stickiness uses the source (client) IP address to stick sessions to backends.

By default, when activating sticky sessions through the console, the cookie-based method is used when HTTP protocol is selected, and the table-based method is used when TCP protocol is selected. Use the API if you want to select table-based stickiness with HTTP protocol.

Tunnel timeout

Tunnel timeout is a configurable value for your Load Balancer’s backend. It defines the maximum allowed tunnel inactivity time (in ms) between a client and a backend server after a Websocket is established. This value takes precedence over client and server timeout in determining when to close the connection.

Verify certificate

The Verify Certificate configuration is relevant to Load Balancers with backends using HTTPS protocol, and specifies whether the Load Balancer should check the backend server’s certificate before initiating a connection.