What is AWS Elastic Load Balancing (ELB)?

AWS Elastic Load Balancing (ELB) is a very useful service provided by Amazon. This article is about the uses of AWS ELB and how you can add and optimize virtual machines using AWS Elastic Load Balancing (ELB).

The load balancer and Auto-scaling working are the same. AWS ELB automatically divides your incoming traffic in multiple instances, such as EC2 instances and IP addresses, in one or more Availability Zones. AWS ELB leads traffic to healthier targets/instances. Elastic Load Balancing handles your load as your incoming traffic changes over time. It can automatically scale to the majority of workloads.

But auto-scaling creates or terminates instances if our given load increases or decreases.

If we do not create a load balancer and users search data from our server then it will provide data to the user. But, If some issues damage that server, then we will lose all data. So, that’s why we use a load balancer on our servers.

How to use Virtual Machines with Elastic Load Balancing (ELB)

For that, we have created two virtual machines/servers. Now, we will create a load balancer after the servers/virtual machines. When the user searches data from our servers, the first request will go to the load balancer, and now the load balancer will check which server is good and its load minimum. Then the load balancer will give the request to the minimum load server, and after that, take data from this server and will give a response to the user.

Now, in case, if one server will damage, then the load balancer will check which server is good, and have a low load on it, then gives a request to this server and takes data from this server. If you have also enabled auto-scaling, then auto-scaling will create a new instance because one server has been damaged. After creating the new instance, the load balancer will then distribute the load evenly between both instances.

Types of Load Balancer

Four types of load balancer are available in AWS;

1. Application Load Balancer (created 2016)
2. Network Load Balancer
3. Gateway Load Balancer
4. Classic Load Balancer (Previous Generation)

1.Application Load Balancer

• AWS launched this load balancer in 2016. It is only used for Application software. It works on the 7th layer of OSI. For example, suppose your task’s container definition specifies port 80 for an NGINX container port and port 0 for the host port. In that case, the host port is dynamically selected from the temporary port range of the container instance (e.g. 32768 to 61000 on the latest Amazon ECS-optimized Amazon Machine Image (AMI)).
• ALB supports HTTP and HTTPS protocols.

2.Network Load Balancer

• Network load balancer used for networking. It works on the 4th layer of OSI (Transport Layer). For example, if your task container definition defines port 80 for the NGINX container port and port 0 for the host port, dynamically move the host port from the temporary port range of the container instance. 
• It supports TCP, UDP, and TLS protocols.

3.Gateway Load Balancer

• Gateway load balancers allow you to deploy and manage virtual tools, such as internet firewalls, detection of interference and prevention systems, and deep packet inspection systems.

4.Classic Load Balancer

• It works on both the 4th and 7th OSI Model layers because this supports both layer’s protocols. For example, load balancer port 80 can be mapped to container example port 3030 and load balancer port 4040 to container example port 4040.
• It supports HTTP, HTTPS, TCP, and SSL protocols.

Load Balancer is always created in the VPC. If you use many subnets, then many availability zones are automatically created. 

Remember this:

• Public IP is not assigned to each of these instances; when we create a Load balancer, then AWS assigns a Public IP to the load balancer; that’s why now incoming or outgoing traffic will come and out through the Load Balancer. Load Balancer creates inside the VPC and instances create inside the subnet; that’s why incoming traffic, first of all, will go to the load balancer and load balancer calls the instances. Private IP is assigned with each instance. The load balancer can also use Private IP to give and take data from the instances.
• As we know, the load balancer is connected to EC2-servers / instances but does not use all incoming or outgoing traffic for the load balancer.

AWS ELB does not support ICMP Protocol

• If anyone can access data to these instances, but through the Ping/SSH/PUTTY, this incoming traffic will not use the load balancer even though this request will directly go to instance fetch data and then back response. Because the ICMP protocol is used for ping commands and ICMP protocol is not used in the load balancer. That’s why the Ping command will directly go to the instances.
• But you can see Load Balancer only supports these protocols HTTP, HTTPS, TCP, UDP, TLS, and SSL protocols. That’s why not all incoming or outgoing traffic use Load Balancer if incoming or outgoing is coming from the Ping/SSH/PUTTY.

Now, we will discuss more 3-points regarding ELB.

1. Listener
2. Target Group
3. Target

1:Listener

Two types of listeners are as follows:

• Front end listener
• Backend listener

Both listeners are available around the Load balancer, but these listeners are always invisible. We use a frontend listener to understand the user request. I mean the listener will check user requests (which user requests are HTTP, HTTPS, or TCP), and when the listener understands, it will send a request that relates to these servers or instances. But make sure the frontend listener will not send a request to the direct EC2 instances because these incoming requests are coming from the protocols. First, the Frontend listener will send a request to the backend listener, and then the backend listener sends a request to related servers for data.

If anyone wants to access data to these servers but through the Ping or SSH, this incoming traffic will not use the load balancer even if this request will directly go to instance fetch data and then back response. Because the ICMP protocol is used for ping commands and ICMP protocol is not used in the load balancer. That’s why the Ping command will directly go to the instances because this will not use by the load balancer.

2:Target Group

We can only 4-CIDR used in target IP. And these are fixed.

• 10.0.0.0/8
• 100.64.0.0/10
• 172.16.0.0/12
• 192.168.0.0/16

Which IP address Support ELB

Load balancer only supports IPv4. The load balancer can attach multiple availability zones but only one subnet in one availability zone; if you choose another subnet, the last subnet will be disconnected. 8 IP Addresses should always be available in ELB (Elastic Load Balancer).

How to manage load in each server

The load balancer always accesses through DNS, not by the IP address. Load Balancer will divide load in each availability zone. If one EC2 server is in one availability zone, the two EC2 servers are in another availability zone, and the fourth EC2 servers are in the third availability zone. Then the load balancer will divide the load in each availability zone.

For Example:

If your load is 100% in these availability zones, you know four EC2 servers are available in this third availability zone, two in the second availability zone, and one in the first availability zone. The load balancer will divide this load into these instances. Mean ELB will divide this load into 33%, 33%, and 33% availability zones.  You know four instances are in the third availability zone, and now four instances will handle just this 33% load.

You also know one instance is available in one availability zone, and then this 33% load will handle only one instance. That’s why this is not fair; we will use Cross Zone Load Balancing because on one side, four instances are handling just 33%, and on another side, just one instance handles 33% load.

Cross Zone Load Balancing

This type will distribute the load across each EC2 server, not into each availability zone.

For Example:

Total seven EC2 servers are available in these availability zones.

EC2 servers > 1+2+4 = 7

Load   > 33.3%+33.3%+33.3% = 100%

100/7 = 14.28%

This load is 14.28% that divides into each EC2 server/instance, not in the availability zone. Suppose one EC2 server is in one availability zone. In that case, this will manage only 14.28% load, in two EC2 servers are in the second availability zone, then this will manage only 14.28%+14.28% = 28.56% load, and in four EC2 servers are in the third availability zone, then this will manage 14.28*4 = 57.12% load.

This type works on the region and availability zone.

Read Also: How to Export/Import a MySQL database via SSH in AWS Lightsail WordPress