Classic Load Balancer (CLB)

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed how to create an internal network load balancer with static private ip address and ip as target.

https://cloudaffaire.com/create-an-internal-network-load-balancer-with-static-private-ip-address/

In this blog post, we will start with the Classic Load Balancer.

What Is a Classic Load Balancer?

A classic load balancer distributes incoming application traffic across multiple EC2 instances in multiple Availability Zones. Your classic load balancer serves as a single point of contact for clients. This increases the availability of your application. You can add and remove instances from your classic load balancer as your needs change, without disrupting the overall flow of requests to your application.

A listener checks for connection requests from clients, using the protocol and port that you configure, and forwards requests to one or more registered instances using the protocol and port number that you configure. You add one or more listeners to your load balancer.

You can configure health checks, which are used to monitor the health of the registered instances so that the load balancer only sends requests to the healthy instances. By default, the classic load balancer distributes traffic evenly across the Availability Zones that you enable for your load balancer. To distribute traffic evenly across all registered instances in all enabled Availability Zones, enable cross-zone load balancing on your load balancer.

Classic Load Balancer Types:

Internet-Facing Classic Load Balancers: An Internet-facing load balancer has a publicly resolvable DNS name, so it can route requests from clients over the Internet to the EC2 instances that are registered with the load balancer. When your load balancer is created, it receives a public DNS name that clients can use to send requests. The DNS servers resolve the DNS name of your load balancer to the public IP addresses of the load balancer nodes for your load balancer. Each load balancer node is connected to the back-end instances using private IP addresses.
Internal Classic Load Balancers: The nodes of an internal load balancer have only private IP addresses. The DNS name of an internal load balancer is publicly resolvable to the private IP addresses of the nodes. Therefore, internal load balancers can only route requests from clients with access to the VPC for the load balancer.

Listeners for Your Classic Load Balancer:

Before you start using Classic Load Balancer, you must configure one or more listeners for your Classic Load Balancer. A listener is a process that checks for connection requests. It is configured with a protocol and a port for front-end (client to load balancer) connections, and a protocol and a port for back-end (load balancer to back-end instance) connections.

Classic Load Balancing supports the following protocols:

HTTP
HTTPS (secure HTTP)
TCP
SSL (secure TCP)

Classic Load Balancing supports the following ports:

[EC2-VPC] 1-65535
[EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

Registered Instances for Your Classic Load Balancer:

After you’ve created your Classic Load Balancer, you must register your EC2 instances with the load balancer. You can select EC2 instances from a single Availability Zone or multiple Availability Zones within the same region as the load balancer. Elastic Load Balancing routinely performs health checks on registered EC2 instances, and automatically distributes incoming requests to the DNS name of your load balancer across the registered, healthy EC2 instances.

Classic Load Balancer Configuration Options:

Idle Connection Timeout:

For each request that a client makes through a Classic Load Balancer, the load balancer maintains two connections. One connection is with the client and the other connection is with a registered EC2 instance. For each connection, the load balancer manages an idle timeout that is triggered when no data is sent over the connection for a specified time period. If no data has been sent or received by the time that the idle timeout period elapses, the load balancer closes the connection. By default, Elastic Load Balancing sets the idle timeout to 60 seconds for both connections.

Cross-Zone Load Balancing:

With cross-zone load balancing, each load balancer node for your Classic Load Balancer distributes requests evenly across the registered instances in all enabled Availability Zones. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its Availability Zone only.

Connection Draining:

To ensure that a Classic Load Balancer stops sending requests to instances that are de-registering or unhealthy, while keeping the existing connections open, use connection draining. This enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy.

Proxy Protocol Support:

Proxy Protocol is an Internet protocol used to carry connection information from the source requesting the connection to the destination for which the connection was requested. Elastic Load Balancing uses Proxy Protocol version 1, which uses a human-readable header format. By default, when you use Transmission Control Protocol (TCP) for both front-end and back-end connections, your Classic Load Balancer forwards requests to the instances without modifying the request headers. If you enable Proxy Protocol, a human-readable header is added to the request header with connection information such as the source IP address, destination IP address, and port numbers. The header is then sent to the instance as part of the request.

Sticky Sessions:

By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.

Custom Domain Name:

Each Classic Load Balancer receives a default Domain Name System (DNS) name. This DNS name includes the name of the AWS region in which the load balancer is created. For example, if you create a load balancer named my-loadbalancer in the US West (Oregon) region, your load balancer receives a DNS name such as my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com. To access the website on your instances, you paste this DNS name into the address field of a web browser. However, this DNS name is not easy for your customers to remember and use. If you’d prefer to use a friendly DNS name for your load balancer, such as www.example.com, instead of the default DNS name, you can create a custom domain name and associate it with the DNS name for your load balancer. When a client makes a request using this custom domain name, the DNS server resolves it to the DNS name for your load balancer.

Health Checks:

Your Classic Load Balancer periodically sends requests to its registered instances to test their status. These tests are called health checks. The status of the instances that are healthy at the time of the health check is InService. The status of any instances that are unhealthy at the time of the health check is OutOfService. The load balancer performs health checks on all registered instances, whether the instance is in a healthy state or an unhealthy state. The load balancer routes requests only to the healthy instances. When the load balancer determines that an instance is unhealthy, it stops routing requests to that instance. The load balancer resumes routing requests to the instance when it has been restored to a healthy state.

Health Check Configuration:

Ping Protocol: The protocol to use to connect with the instance.
Ping Port: The port to use to connect with the instance, as a protocol:port pair. If the load balancer fails to connect with the instance at the specified port within the configured response timeout period, the instance is considered unhealthy.
Ping Path: The destination for the HTTP or HTTPS request.
Response Timeout: The amount of time to wait when receiving a response from the health check, in seconds.
HealthCheck Interval: The amount of time between health checks of an individual instance, in seconds.
Unhealthy Threshold: The number of consecutive failed health checks that must occur before declaring an EC2 instance unhealthy.
Healthy Threshold: The number of consecutive successful health checks that must occur before declaring an EC2 instance healthy.

Hope you have enjoyed this article, In the next blog post, we will create our 1^st Classic Load Balancer. The classic load balancer is a legacy load balancer offering from AWS and is replaced by either application load balancer or network load balancer depending upon the feature you need. Hence, we will not focus much on Classic Load Balancing.

To get more details on AWS ELB, please refer below AWS documentation

https://docs.aws.amazon.com/elasticloadbalancing/index.html