Jump toUpdate content
Load Balancers - Concepts
An Access Control List (ACL) is a list of permissions that control which traffic (based on source and destination IPs, or HTTPS information) is allowed to pass through your Load Balancer. This allows you to build extra security into your Load Balancer, and permit or deny access to the application(s) behind it. Learn more about ACLs in our dedicated how-to.
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.
Load Balancers support three different modes of balancing the incoming load:
- Round Robin
In round-robin mode, each request is queued and then assigned in a defined sequence to the backend servers. Basically, the load balancer acts like a turnstile. This is the most frequently used rule, and the easiest to implement as it is perfect for infrastructures that have identical backends.
- Least Connection
In the least connection mode, each request is assigned to the server with the fewest active connections. This rule works best when each user connects at different times and helps keep the servers well-balanced.
- First Connection
In first connection mode, the inbound request is directed towards the first server available for processing.
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.
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.
Load Balancers should only forward traffic to “healthy” backend servers. To monitor the health of a backend server, health checks regularly attempt to connect to 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.
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
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.
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 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 (eg 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 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 Identitication (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.
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 trafic 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.
- Cookie-based stickiness uses a 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 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.
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.