Jump toUpdate content
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 for 1€ a month and reuse it later. These flexible IPs are not compatible with other Scaleway products (eg 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 are ready to create load balancing routing rules. These rules will indicate how to redirect incoming connections based on various parameters such as IP addresses, path, host, etc. You can choose the frontend and the backend to which the rule should apply. Currently, a Server Name Indication (SNI) based redirection is supported.
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