Load Balancers are highly available and fully managed Instances which distribute the workload among your servers. They ensure the scaling of applications while securing their continuous availability. They are commonly used to improve the performance and reliability of websites, applications, databases, and other services by distributing the workload across multiple servers. It monitors the availability of your backend servers, detects if a server fails and rebalances the load between the rest of the servers, making your applications highly available for users.
A Load Balancer can be used as frontend for any Instance type, even if they do not belong to Scaleway thanks to the multicloud feature.
See our documentation on using a Load Balancer to expose a Kubernetes Kapsule.
Your frontend listens to your Load Balancer’s flexible IP address. In case of a failure of the Load Balancer, a replica Load Balancer is immediately spawned and deployed, and the IP address is automatically rerouted to this replica. This is done automatically, by the Load Balancer control subsystems.
By default, each Load Balancer is created automatically with a flexible IP address.
When you delete a Load Balancer, you can keep the flexible IP allocated to your account and reuse it later. These flexible IPs are not compatible with other Scaleway products (e.g. Instances, Elastic Metal servers, Public Gateways): each resource has its own set of flexible IPs.
Each Load Balancer comes with one highly available flexible IP address. Currently, it is not possible to assign more than one IP to each Load Balancer.
Each Load Balancer provides external connectivity via an IPv4 address. IPv6 is not yet supported for external connections, but it can be used to communicate between the Load Balancer and your backend servers.
Yes. If your Load Balancer fails, a deployment script automatically executes, spawning and deploying a replica Load Balancer Instance. Your Load Balancer’s flexible IP address is automatically rerouted to this replica Instance. If you want to know more about the failover system, read our article about strengthening our Load Balancer failover mechanism.
No, it is not required. You can use private Scaleway IPs on your backend servers if they are hosted in the same Availability Zone (AZ) as the Load Balancer.
Multicloud means that you can add as many backend servers that are neither Instances, nor Elastic Metal servers, nor Dedibox dedicated servers. These can be services from other cloud platforms such as Amazon Web Services, Digital Ocean, Google Cloud, Microsoft Azure or OVH, but also on-premises servers hosted in a third-party datacenter.
Unlike the multi-cloud offers, non-multi-cloud offers allow you to add only backend servers part of the Scaleway ecosystems which include Instances, Elastic Metal servers, and Dedibox dedicated servers.
All protocols based on
TCP are supported. This includes
IMAP and so on. You can also specify
HTTP to benefit from support and features that are exclusive to this protocol.
Yes, you can restrict the use of a
TCP port or
HTTP URL via
ACLS. Find more information in our developers documentation.
Once you have created one or more Load Balancers, you can create routes. Routes indicate how to direct incoming connections to certain backends based on various parameters such as IP addresses, path, host, etc. You can choose the frontend to which the rule should apply, and the backend it should direct to. Routes can be based on Server Name Indication (SNI) for TCP Load Balancers, or the HTTP Host header for HTTP Load Balancers. Check out our dedicated documentation for more information.
A health check is one of the core concepts for a well-functioning Load Balancer. It is a predefined request which periodically checks whether the server is in a healthy state or an unhealthy state. Only servers that respond correctly to the health check receive client requests. When the Load Balancer determines that an Instance is unhealthy, it stops routing requests to that Instance. Currently, our Load Balancer supports
TCP-based health checks such as
Yes, this is possible using routes. When you create a frontend, you must select a “default” backend, which it forwards traffic to when the request doesn’t match any configured route. But via the routes tab for your frontend in the Scaleway console, you can create routes to different backends from the same frontend. Routes are currently supported based on the value of the
Host header of incoming HTTP requests for HTTP backends, or on SNI for TCP backends.