Classic Load Balancer

What is Classic Load Balancer?

We know that Elastic Load Balancing automatically distributes the incoming traffic across multiple targets, like EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of its registered targets and routes traffic only to the healthy targets. You can also scale the load balancer when the incoming traffic spikes or changes over time. The Elastic Load Balancer can automatically scale to the vast majority of workloads.

Elastic Load Balancing supports the four major load balancers: Classic Load Balancers, Application Load Balancers, Network Load Balancers, and Gateway Load Balancers.

Depending upon your needs, you can select the type of load balancer suiting your needs. In this article, we shall focus on the Classic Load Balancers.

The Classic Load Balancer can be defined as a load balancer that distributes incoming application traffic across multiple EC2 instances in multiple Availability Zones which increases the fault tolerance of the applications along with detecting the unhealthy instances and routing the traffic only to healthy instances.

The Classic Load Balancer serves as a single point of contact for clients which increases the availability of the application. We can add and remove instances from the load balancer depending on the needs, without disrupting the overall flow of requests to our application. The Classic Load Balancier can also scale to the vast majority of workloads automatically when the traffic to the application changes over time.

We can also configure health checks, that are used to monitor the health of the registered instances so that the Classic Load Balancer is only sending the requests to the healthy instances. It is recommended to keep approximately the same number of instances in each Availability Zone registered with the Classic Load Balancer to ensure that the registered instances can handle the request load in each Availability Zone.

Let us understand this via an example. Suppose we have eight instances in Availability Zone us-west-2a and four instances in us-west-2b, and the requests are distributed evenly between the two Availability Zones. As a result, the four instances in us-west-2b serve the same amount of traffic as the eight instances in us-west-2a. Instead, you could be having six instances in each Availability Zone.

To evenly distribute the traffic across all registered instances in all enabled Availability Zones, enables the cross-zone load balancing for your load balancer. However, it is still recommended that we maintain approximately equivalent numbers of instances in each of the Availability Zone for better fault tolerance.

Features and Benefits of Classic Load Balancer

Listed below are the features that the Classic Load Balancer offers to its users:

1. Load Balancing for Layer 4 and Layer 7:
   With the implementation of Classic Load Balancer, you get the ability to balance the load for HTTP/HTTPS applications and use Layer 7-specific features like (X-Forwarded and sticky sessions). For applications that rely purely on the TCP protocol, you can make use of the strict Layer 4 load balancing.

2. SSL Offloading:
   The Classic Load Balancer supports SSL termination that includes offloading SSL decryption from centralized management of SSL certificates, application instances, and encryption to back-end instances with the feature of optional public key authentication. To control the ciphers and protocols, the Classic Load Balancer allows flexible cipher support to its clients.

3. High availability:
   One of the most important features of the Classic Load Balancer is that it is highly available. With the Classic Load balancer, you get the ability to distribute the incoming traffic across the Amazon EC2 instances in either a single Availability Zone or across multiple Availability Zones. The Classic Load Balancer automatically scales when its request handling capacity increase or decreases in response to the incoming application traffic. With the Classic Load Balancer, you also get the capability to run health checks with a custom-built measure on the targets which helps to ensure that your targets remain available and healthy.

4. IPv6 Support:
   The Classic Load Balancer supports the use of both Internet Protocol versions 4 and 6 (IPv4 and IPv6) for its EC2-Classic networks. The EC2-Classic networks can be defined as the EC2 instances that run as a single, flat network that can be shared across AWS customers. The EC2-Classic instances do not exist in an isolated environment and this option is soon to be deprecated by AWS.

5. Operational monitoring & logging:
   Amazon CloudWatch reports the Classic Load Balancer and Application Load Balancer metrics like error types, request latency, request counts, error counts, and more. Classic Load Balancer can also be integrated with AWS CloudTrail to track API calls to the load balancer.

6. Security:
   When we talk about security while working with Amazon Virtual Private Cloud (VPC), you can create as well as manage the security groups that are associated with the Elastic Load Balancing that can provide additional networking and security options for the Application Load Balancer and Classic Load Balancer. It is also possible to configure any of the Load Balancers to be Internet-facing or even create a load balancer without the public IP addresses that can even serve as an internal (non-internet-facing) load balancer.

7. High throughput:
   The Classic Load Balancer is designed to handle the traffic as it grows and hence it can balance the load offered by millions of requests/second. As it is high throughput, it is capable of handling sudden spikes and volatile traffic patterns.

8. Health checks:
   The Classic Load Balancer is always maintaining a health check on its instances as it only routes traffic to healthy targets like EC2 instances, microservices, Lambda functions, containers, IP addresses, and appliances. We get improved insight into the health of our applications in two possible ways through the Classic Load Balancer:

   • Health check improvements which allow us to configure the detailed error codes by monitoring the health of each of the services behind the load balancer
   • The metrics provide great insight into the traffic for each of our services running on an EC2 instance

9. Protection against Accidental Delete:
   By implementing the Classic Load Balancer with deletion protection enabled, you can prevent any accidental delete which can be something like an irreversible data loss getting completely deleted from any accidental or malicious operations.

10. Sticky sessions:
    The sticky session can be described as storing the newly added cookies and using the same set whenever a request for the same session is pointed to. The classic load balancer provides this sticky session feature which helps the client with a seamless experience as it maintains a connection to the same instance over a cookie's lifetime. With integration with a Classic Load Balancer, the sticky session is binding the user sessions to a specific instance. This means that all requests from a user during a session are sent to the same instance. This mechanism to route requests from the same client to the same target helps in balancing the load across the instances properly and gives the customer a seamless experience. The Classic Load Balancers support the sticky sessions and the stickiness is defined at a target group level.

How to Get Started? - Creating a Classic Load Balancer

With the following eight steps, you can now get started with Creating a Classic Load Balancer and start to handle the spike in traffic easily and seamlessly with just a few clicks. With the below given hands-on step-by-step guide, you will understand how the Classic Load Balancers can be set up through the AWS Management Console when it receives the public HTTP traffic which needs to be sent to the EC2 instances.

• Step 1: Select the Classic Load Balancer from the four different types based on the scenario we are covering

  • Open the Amazon EC2 console with the link - https://console.aws.amazon.com/ec2/ where on the navigation bar, you will get the option to choose a Region that needs to be the same as your EC2 instances.
  • Under the Load Balancing menu, select Load Balancers where you can start to create the Classic Load Balancer by simply selecting the Create option.

• Step 2: Defining the Classic Load Balancer with attributes like name, a network, and a listener

  • Start by giving a unique name (maximum of 32 characters, only alphanumeric characters and hyphens, and no beginning or ending with a hyphen) to the Classic Load Balancer.

  • For the Create LB Inside option, choose the same network as the EC2-Classic or the defined VPC. When you select the Default VPC, you need to specify the subnets for your load balancer. Select the Enable advanced VPC configuration option.

  • You can leave the default Listener Configuration. Select at least one or more available public subnets to achieve high availability of your load balancer. If a subnet was chosen already, then it gets replaced with the currently selected subnet in the AZ.

  

• Step 3: Assigning the required security groups in a VPC for your Classic Load Balancer:

  • Start by creating a new security group on the Assign Security Groups page. A security group contains a rule that allows traffic to the configured port. On the page, you need to give a name and description. You can also leave the default name and description.

  

• Step 4: Enabling the Health Checks on the EC2 instances

  • The Ping Protocol will be set to HTTP while the Ping Port will be set to 80 on the Configure Health Check page.
  • You need to replace the default value with a single forward slash ("/") on the Ping Path option, which will tell the Classic Load Balancer (CLB) to frequently send health check queries to your web server home page.
  • The Advanced Details can be left with the default values.

  

• Step 5: Registering the EC2 instances with the Classic load balancer

  • Choose the EC2 instances that you want to register with the Classic Load Balancer from the Add EC2 Instances page. You can enable cross-zone load balancing and connection draining. Connection draining in CLB can be defined as the process where Auto Scaling shall wait for the outstanding number of requests to first complete before it starts to terminate instances.

• Step 6: Optional Step to Tag the Classic load Balancer

  • For adding the tags to your Classic Load Balancer, mention the key and a value for that tag via the Add Tags page, where multiple additional tags can also be specified. After this, you need to choose Review and Create.

• Step 7: Creating the Classic Load Balancer and verifying it:

  • After you choose to create the load balancer on the Review page, you will be notified that the Classic Load Balancer is created. Select the new Classic Load Balancer whose status can be checked from the Description tab. If the instances are not in service, they might still be in the registration process.
  • When at least one of the EC2 instances gets in service, start testing the CLB by pasting the copied string from the DNS name into the address field of any internet-connected web browser. If you see the default page, you are good to go as the Classic Load Balancer is working now.

• Step 8: Optional step to Delete the CLB

  • As you start getting charged for each hour or partial hour that you keep the CLB running, it's important to delete the Classic Load balancer when it's no longer needed.
  • You can simply delete the CLB by selecting the Delete option under the Action tab once you open the specific Load Balancer. Once the CLB get deleted, the EC2 instances associated will continue to run, and you get billed for them. Hence, you need to stop or terminate the EC2 instances as well when not in use.

Differences Between Classic Load Balancer and Application Load Balancer

The Classic Load Balancer operates for both Layer 4 and 7 whereas the Application Load Balancer operates for Layer 7 of the OSI model, and the Network Load Balancer distributes traffic based on Layer 4.

The Classic Load Balancer is described as a connection-based balancer where the requests are forwarded by the load balancer without “looking into” any of these requests as these requests are just forwarded to the backend section whereas the Application Load Balancer is described as a connection that works on a Layer 7 OSI model and allows the traffic distribution toward backend instances based on the information inside the HTTP requests header. The connection gets terminated at the ALB when the connection pools are toward the backend instances. There is also a possibility of opening multiple connections toward the backend instances which are eventually utilized for forwarding the requests.

Some more differentiating points to note are:

• With the Classic Load Balancer you cannot enable the content-based routing and also cannot allow requests to be routed to different applications behind a single load balancer whereas, for the Application Load Balancer, you can do that.
• You must note that the Application Load balancer is not an improved version of the Classic Load balancer and is made on a completely new platform which is a fully-managed, scalable, and highly available load balancing platform. You also get the ability for a path-based routing feature, which helps you to add up to 10 different applications behind a single Application Load Balancer.
• With Classic Load Balancer, you can only use one port at a time whereas, with Application Load Balancer, you get to register with multiple ports.
• Both the Classic Load Balancer and the Application Load Balancer have listeners that define the protocol and port, where the load balancer listens for incoming connections. Here, each of the load balancers can have a minimum of one listener and can support up to a maximum of 10 listeners.

Below is a tabular format to distinguish between the Classic Load Balancer and the Application Load Balancer:

Analysing the Three Different Load Balancers

Based on your application needs, you get the flexibility to choose a suitable load balancer. It is often recommended to use the Application Load Balancer when you need flexible application management while for extreme performance you can opt for Network Load Balancer which also supports the static IP. For existing applications already built within the EC2-Classic network, it is highly recommended to use the Classic Load Balancer.

Below are some of the comparison metrics between the different types of load balancers:

Use Cases of Classic Load Balancer

Now we shall dive into a few use cases of Classic Load Balancer.

• We can improve hybrid cloud network scalability with the high availability and scalability offered by Classic Load Balancer.
• With the Classic Load Balancer, we can balance across the AWS and on-premises resources using a single load balancer also.
• You can modernize your applications with serverless and containers.
• To meet the exponentially growing demand without any complex configurations or API gateways, you can easily and quickly scale your modern applications
• You can also retain your existing network appliances and implement the Classic Load Balancer without worrying about any spike breaking your users' seamless experience as the Classic Load Balancer is capable of handling that load as well.
• You can seamlessly deploy the network appliances from your preferred vendor along with taking advantage of the scalability and flexibility offered by the cloud.

Companies Using Classic Load Balancer

Now as we understood the Classic Load Balancer and its features and pricing options, we shall be looking at which companies have started using Classic Load Balancer to unleash its advantage for their use cases.

The above image refers to some of the talked about companies that have been using the Classic Load Balancer and unleashing its benefits.

Terminix:
By integrating the Classic Load balancer, onboarding a new component that used to take days can now be done in minutes on AWS.

Second Spectrum:
The direct-pod internet protocol target registration from AWS Classic Load Balancer Controller enabled Second Spectrum to clean up and consolidate their configuration into a simple-to-use Kubernetes input.

NuData Security:
NuData is using Classic Load Balancing to ensure high availability and scalability for the API services it offers. Along with this, the built-in elasticity offered by the Load Balancers ensures NuData Security’s flagship product, NuDetect easily authenticates its users and prevents any fraudulent activity.

Dream11:
With the implementation of the Classic Load Balancer (CLB) which has become the core piece of the infrastructure, helps Dream11 achieve high availability and scalability as per their traffic needs. They are using 100+ load balancers which process more than 65 billion requests per day across all the microservices.

Verizon:
With the Classic Load Balancers, helps Verizon to meet the requirements during peak seasons to ensure the best and most seamless customer experience. They can provide a 10X scale to their services, meeting peak demand for applications running on EC2.

Pricing Structure of Classic Load Balancer

As we studied, Elastic Load Balancing offers primarily four types of load balancers, which have features like high availability, automatic scaling, and robust security support for the applications.

When the pricing for these services is considered, AWS allows you to pay for what you use with these offerings. When you start with the AWS Free tier for Elastic Load Balancing, you first need to sign-up (if you are a new customer of AWS). For all the new AWS customers, AWS offers 750 hours per month which is shared between Classic and Application load balancers; 15 GB of data processing for Classic Load Balancers.

The prices for Classic Load Balancer vary based on the AWS Region in which it gets deployed, where the us-east-1 (Northern Virginia) and us-west-1 (Oregon) are the least expensive, and the sa-east-1 (Sao Paulo) region is the most expensive.

Now let's get back to understanding the pricing structure for the Classic load balancer:

Classic Load Balancer:

You get charged for each hour or partial hour for which a Classic Load Balancer is running and for utilization of each GB of data transferred through the load balancer.

For example, for the us-east-2 (Ohio) region, the charges are as follows:

• $0.025 per Classic Load Balancer hour or partial hour.
• $0.008 per GB of data that is processed by a Classic Load Balancer.

All the prices charged by AWS are exclusive of any applicable taxes and duties, which can include the VAT and applicable sales tax. Also, Amazon EC2 service fees are charged and get billed separately.