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.
A Highly Available IP address is the IP, the frontend listens to. It provides a special configuration and is by default routed to the primary Load Balancer Instance. In case of a failure of the primary Load Balancer Instance, this address is automatically rerouted to the replicated one. This is done automatically, by the Load Balancer control subsystems.
By default, each Load Balancer is created automatically with a Highly Available IP.
When you delete a Load Balancer, you can keep the HA IP allocated to your account for 1€ a month and reuse it later. HA IP is not compatible with Compute Instances, as you cannot use an IP address, earlier allocated for a Compute Instance, for a Load Balancer.
Each Load Balancer comes with one highly available 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.
Each Load Balancer consists of two Instances: Primary and Replica. These Instances are deployed identically on different hardware clusters to ensure that they do not share physical resources to minimize the risk of simultaneous failure.
In case the primary Load Balancer fails, the highly available IP address is automatically re-routed to the replica Load Balancer to handle the traffic.
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 Bare 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, Bare 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