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.
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.
- 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
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.
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 back-end instance based on a path in the URI of the request. For more information, see Creating a Listener Rule.
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. They are available for load balancers with HTTP and HTTPS listeners only. When the stickiness cookie expires, the sticky session is reset and the next request creates a new sticky session.
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.
For more information, see Configuring Sticky Sessions for Your Load Balancers.
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.