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:
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.
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 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.
Load Balancers support three different modes of balancing load (requests) between backend servers:
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 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.
With the customized error page feature, you can redirect users to a static website hosted on Scaleway Object Storage if none of your Load Balancer’s backends are available to serve the requested content. This website could be a simple, single webpage or else something much more complex: you build it according to your own requirements.
If you do not set up a customized error page, and none of your backend servers are available, your users will instead see a standard HTTP error displayed in their browser, e.g. 503 Service Unavailable.
Benefits of using this feature include:
Edge Services is an additional feature for Scaleway Load Balancers and Object Storage buckets.
Creating an Edge Services pipeline for your Load Balancer helps to reduce load on your Load Balancer's backend servers. The origin configuration you define is used by Edge Services to connect to your Load Balancer and request content, which is then stored in the cache. Then, when your Load Balancer origin is accessed via its customizable Edge Services endpoint, the requested content is served from the cache (if present), without the need to fetch this content via the Load Balancer and its backend servers.
Edge Services lets you:
An Edge Services pipeline can be created for any Load Balancer with a public IP address. Load Balancers with frontends/backends using both TCP and/or HTTP are supported. Private Load Balancers are not compatible with Edge Services.
See balancing-methods.
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 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.
Find out how to create and manage flexible IP addresses in our dedicated how-to.
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.
Read more about health checks, including the advanced settings available, in our dedicated documentation.
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 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 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.
Internet Protocol Version 4 is the standard protocol used for IP addresses, and routes most Internet traffic as of today. Each IPv4 address has 32 bits. Written in human-readable form, an IPv4 address is generally shown as four octets of numbers separated by periods, e.g. 192.0.2.1.
When you create a public (flexible) IP address for a Load Balancer, this address can use either IPv4 or IPv6 protocol. An IPv4 address is obligatory for all public Load Balancers, but an IPv6 address can be optionally added.
Internet Protocol Version 6 is the most recent version of the IP protocol used for IP addresses. Each IPv6 address has 128 bits. Written in human-readable form, an IPv6 address can be shown as eight groups of four hexadecimal digits, each group representing 16 bits and separated by a colon, e.g. 1050:0000:0000:0000:0005:0600:300c:326b. This can also be notated as 1050:0:0:0:5:600:300c:326b by omitting leading zeros.
When you create a public (flexible) IP address for a Load Balancer, this address can use either IPv4 or IPv6 protocol. An IPv4 address is obligatory for all public Load Balancers, but an IPv6 address can be optionally added.
When you create a LoadBalancer service within your Scaleway Kubernetes cluster, the Scaleway Cloud Controller Manager will spin up an external Scaleway Load Balancer with the correct configuration to expose the specified service in your cluster.
The process for creating and managing Load Balancers for Kubernetes clusters is very specific - you cannot create or edit these via the Scaleway console or API. For full instructions on how to correctly create and configure a Scaleway Load Balancer for a Kubernetes cluster, see our dedicated documentation.
See balancing-methods.
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.
A Load Balancer is defined as private when you choose the “private” accessibility option during Load Balancer creation. A Private Load Balancer has no public IP address, and only listens to requests or connections sent through the Private Network(s) to which it is attached. Read more about private Load Balancers and their characteristics and limitations in our dedicated documentation.
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 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. For full information, see our dedicated documentation.
See balancing-methods.
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.
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 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 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 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 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.
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.
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 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.
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.