About Load Balancers

A load balancer distributes incoming network traffic between multiple instances of the public Cloud or of a Virtual Private Cloud (VPC) to avoid overload and to improve the availability and reliability of your services.

You can:

  • Load balance using the TCP/SSL and HTTP/HTTPS protocols.

  • Distribute the load between several Availability Zones (AZs) or subnets.

  • Set up health checks to verify the status of each instance and send traffic only to the healthy ones.

General Information

Load Balancers and Back-end Instances

The instances registered with a load balancer are called back-end instances, or backends. You can register as many back-end instances as you need with a load balancer, and register or deregister back-end instances at any time depending on your needs.

  • You can register back-end instances using either their instance IDs or their External IPs (EIPs). For more information, see Registering Instances with a Load Balancer.

  • A load balancer is created in a specific AZ or a specific subnet, but it can distribute traffic to any AZs of its Region or any subnets of its VPC.

Depending on its security group rules, a back-end instance can receive either only the traffic coming from the load balancer or both the traffic coming from the load balancer and from elsewhere (another load balancer, directly from the Internet, and so on).

Load balancers work in round-robin mode: front-end requests are evenly distributed to back-end instances. The number of front-end requests received by one back-end instance corresponds to the total number of front-end requests divided by the total number of back-end instances.

The load balancer checks the health of back-end instances to determine the healthy ones that it can distribute the traffic to. For more information about health checks, see Configuring Health Checks.

You can configure only one type of health checks per load balancer, by specifying the protocol and port of back-end instances to check. We recommend creating one load balancer per service to avoid any undetected failure.

Load Balancer Types

A load balancer can be either Internet-facing or internal:

  • An Internet-facing load balancer can be created in either the public Cloud or in a VPC. This type of load balancer distributes inbound flows coming from the Internet between its back-end instances that can be placed in different AZs of a same Region or different subnets of a same VPC. This load balancer can be accessed through the Internet.

Internet-facing load balancer in the public Cloud

sch LBU InternetLBPublicCloud

Internet-facing load balancer in a VPC

sch LBU InternetLBVPC

  • An internal load balancer can only be created in a VPC. This type of load balancer distributes the traffic between its back-end instances within one or more subnets of the VPC. This load balancer can only be accessed from within the CIDR of the VPC.

Internal Load Balancer

sch LBU InternalLB

DNS Name

A DNS name is automatically assigned to each load balancer and is composed of the name of the load balancer and its endpoint (load-balancer-name.endpoint). This DNS name enables you to access your load balancer and send requests to it.

Internet-facing load balancers receive a public DNS name, while internal load balancers receive a private one.

Whether privately (in the VPC) or publicly (on the Internet), the DNS name of an internal load balancer is resolved to the private IP of the load balancer.

External IP

External IPs (EIPs) are public IPv4 addresses that you can allocate to your account. You can associate EIPs with internet-facing load balancers only, either in the Public Cloud or in a VPC.

EIPs are owned either by 3DS OUTSCALE or by you, depending on what you specify when associating them.

The table below covers the different association behaviors when using the PublicIp parameter:

OUTSCALE API method EIP specification Association behavior



The EIP you specify is associated with the internet-facing load balancer.


Not specified

An EIP owned by 3DS OUTSCALE is automatically created and associated with the internet-facing load balancer.



If the previous EIP is yours, it is disassociated. If the previous EIP is owned by 3DS OUTSCALE, it is deleted.


Specified with an empty value

If the previous EIP is yours, it is disassociated and replaced with an EIP owned by 3DS OUTSCALE. If the previous EIP is owned by 3DS OUTSCALE, it is kept and an error is returned.


Not specified

No change.


Not required

If the EIP is yours, it is disassociated. If the EIP is owned by 3DS OUTSCALE, it is deleted.

For more information about EIPs, see About EIPs.



Each load balancer must be created with a listener to be able to receive requests. A listener corresponds to the process handling the requests coming to the load balancer from the Internet or from a corporate network, configured with a protocol and a port, using a port between 1 and 65535 both included.

You also configure the protocol and port to route traffic to back-end instances.

OUTSCALE load balancers support the HTTP/HTTPS and TCP/SSL protocols. Secure protocols are only supported between the client and the load balancer. The front-end and back-end protocols must be on the same level, therefore:

  • If the front-end protocol is HTTP or HTTPS, the back-end protocol must be HTTP.

  • If the front-end protocol is TCP or SSL, the back-end protocol must be TCP.

The port number on which back-end instances are listening must be between 1 and 65535 both included.

  • For the SSL protocol, OUTSCALE load balancers support the successor protocols TLS 1.1 and TLS 1.2. They do not support TLS 1.0 and deprecated versions of the original SSL.

  • You cannot modify the configuration of a listener once it is created. However, you can add as many listeners as you need to a load balancer, and remove them if needed. For more information, see Adding or Deleting Listeners.

You can also manage the behavior of a load balancer using listener rules. These rules enable you to redirect traffic to a specific backend instance based on a path in the URI of the request. For more information, see Creating a Listener Rule.

Sticky Sessions

By default, a load balancer distributes each network request independently, which means that two successive requests of the same user may be routed to two different back-end instances. However, you can use a sticky session policy to bind the user to the back-end instance that handled the first request.

Sticky sessions work by creating a stickiness cookie with a specific duration. When the stickiness cookie expires, the sticky session is reset and the next request creates a new sticky session.

Sticky sessions can be configured for load balancers with HTTP and HTTPS listeners only.

There are two types of sticky session policies:

  • Duration-based: The stickiness cookie has a specific time duration.

  • Application-controlled: The stickiness cookie has the same duration as a cookie of the back-end instance.

If the back-end instance that the user is bound to becomes unhealthy, the sticky session is reset among the remaining healthy instances. The session is then stuck to another instance until the cookie expires, even if the original instance becomes healthy again.

You can activate secure cookies on your load balancers. A secure cookie is a cookie that can only be emitted through HTTPS connections.

For more information, see Modifying the Attributes of a Load Balancer.

SSL Termination and SSL Passthrough

You can create a listener with an x509 SSL server certificate for a load balancer to enable encrypted traffic in SSL or HTTPS protocol between the client initiating SSL or HTTPS connections and the load balancer. x509 server certificates are delivered by a certification authority, and contain authentication information like a public key and the signature of the certification authority. This certificate is used by the load balancer to decrypt connection requests from this client, which are then forwarded to its registered back-end instances in the protocol of your choice (TCP or HTTP).

The certificate used by the load balancer for SSL termination can be replaced at any time. For more information, see Replacing the SSL Certificate Used by an HTTPS or SSL Load Balancer.

SSL termination ensures the confidentiality of the communication between the client and the load balancer by checking the authentication information. The communication between your load balancer and its registered back-end instances is unencrypted and its security is ensured by the rules you add to the security groups of your back-end instances. You may need to use load balancers SSL termination for cases where you have to ensure confidentiality, for example, a website that requires a login and password authentication.

You can also forward HTTPS flows to back-end instances that have an SSL certificate using the TCP protocol. With this method, called SSL passthrough, the server certificate is uploaded on the back-end instances instead of the load balancer. The load balancer does not decrypt data flowing between the client and the back-end instances through TCP protocol.

For more information about how to configure load balancer listeners for load balancers with SSL termination or SSL passthrough, see Configuring a Load Balancer for SSL Termination or SSL Passthrough.

You can create the SSL or HTTPS listener when creating the load balancer, or you can add it to the load balancer at any time. You first need to upload your server certificate in Elastic Identity Management (EIM), and then specify it when creating the listener using its OUTSCALE Resource Name (ORN). For more information, see Working with Server Certificates.

It is recommended to use one certificate per load balancer.

Related Pages