Application availability, continuity of service, greater performance of the application – These are the things we would always require from a platform owner while designing the network and answer to this in AWS is called ELB (Elastic load balancing). This feature is similar to what we know as Load balancing. Let’s have a closer look on ELB:-
“A load balancer distributes incoming application traffic across multiple EC2 instances in multiple Availability zones. This increases the fault tolerance of your applications. Elastic load balancer detects unhealthy instances (servers those are running low memory, having high CPU, any hardware fault) and routes traffic only to healthy instances”.
Here is another example to elucidate the concept: – You have a website which is running on one instance (t2 micro or Nano). One a very fine day, hundreds and thousands of requests start hitting the web server running on single t-2 micro, and your website is likely to crash or respond slow very. In this situation, you are left with 2 options –
Option 1 – Upgrade your instance to maybe M5-large
Option 2 – Use multiple t2-micro instances and distribute the website traffic between them.
Option 2 is more rational solution which can be accomplished by Elastic Load Balancer, since upgrading instance to more resourceful instance may cost you much more and will still remain single point of failure.
Notable is that ELB uses health checks to detect which instances are healthy and directs traffic only across those instances.
Types of Elastic Load balancers:
- Application Load Balancer
- Network Load balancer
- Classic Load balancer
Let’s understand all the three load balancers by an example: –
Application Load balancer:
As it works on the Application layer, this type of Load balancing is provisioned only when we have a HTTP/ HTTPS traffic to address. It also provides advanced routing features such as host-based and path-based routing and works with containers and microservices
Suppose you have two entities under website IPWITHEASE.COM – 1st is api.ipwithease.com and 2nd is mobile.ipwithease.com. You can route incoming traffic based on the domain name specified in the “Host”. Hence Application based LB can easily distribute the incoming web traffic on both the entities due to its Host-based routing feature.
Suppose the website of your company is ipwithease.com and the company’s blog is hosted on ipwithease.com/blog. The operations team has decided to host the main website and the blog on different instances. Using ALB you can route traffic based on the path of the requested URL due to its path-based routing feature.
Network Load balancer:
In this case LB manages the connections based on TCP/ UDP request. Suppose your company’s website is running on four m4-xlarge instances and you are using an ALB to distribute the traffic among them. Your company launched a new product recently which got viral and your website starts getting millions of requests per second. In this case, the ALB may not be able to handle the sudden spike in traffic. This is where the NLB really shines. It has the capability to handle a sudden spike in traffic since it works at the connection level. It also provides support for static IPs.
Classic Load balancer:
This is the previous generation load balancer that was used for EC2-classic instances. It operates on both the request level and the connection level. But it doesn’t support features like host-based routing or path-based routing. Once configured, it distributes the load across all the registered instances regardless of what is present on the servers. Hence, it can only be used to distribute traffic to a single URL.