Under standing Aws Load Balancer

Load Balancing refers to efficiently distributing incoming network traffic across a group of backend servers. The group of servers are called server farm or server pool. Most popular load balancers include nginx, mod_jk with apache httpd. Installing a load balancer is quite easy with some configuration. Most of the time, these load balancers are used when there is heavy access from users to an application. One can replace the existing infrastructure with bigger ones which are not too economical. Another way is to use a smaller multiple infrastructure, run the application in those infrastructure and 

Aws on the other hand provides a load balancer to make our applications high available by distributing traffic across multiple instances and traffic is routed based on the health checks performed on the server farm.

The application load balancer works on application layer ( layer 7) or Transport Layer ( Layer 4) of the OSI model. Requests are passed to the backend server farm based on the information inside the HTTP requests header. It is also possible to modify the HTTP headers that contain X-forwarded-for field containing the client IP address. So whenever there is a request from the user, the request goes to the load balancer and then the request is held, load balancer create pool of connections already to the backend server farm and by using one of the connections from the pool, the original request is forwarded to the backend instances and same goes while sending data to the user. 

The requests are observed by the load balancer and based on the port and protocol, the request is forwarded to backed server farm and this forwarding happens only to the healthy instance identified by the load balancer.

Aws provides different types of load balancers,

Classic Load Balancer

Application Load Balancer

Network Load Balancer

Let's talk about each of them in detail,

Classic Load Balancer - These load balancers distribute upcoming traffic to different Ec2 instances in multiple availability Zones. The Classic load balancer is a connection-based balancer where requests are forwarded by the load balancer without “looking into” any of these requests. They just forward to the backend section. Another feature with these is that a new instances can be added to the existing instances without disrupting the flow of requests. This load balancer works on both request level as well as the connection level. 

The classic load balancer (CLB) operates at the Transport Layer ( Layer 4) of the OST model which means the load balancer routes traffic between clients to servers based on the IP address and TCP port. 

Though it is possible to have a single server behind a Load balancer, it is best to have a pool of servers behind the load balancer. The server farm running backed can be running in multiple Availability Zones within a region to support high availability. With this case if one Az is unavailable, the load balancer can route traffic to other Az’s.

There are few cases of load imbalance from classic load balancer with the default configuration of classic load balancer and if there are an uneven number of servers in the backend. It is recommended to maintain an equal number of target instances in each Availability Zone.

Application Load Balancer - With the classic load balancer, we cannot enable content-based routing or path based routing. Aws came up with the Application load balancer that does these. ALB is a fully managed, scalable and highly available load balancing platform. 

This Load balanced is basically implemented for Web applications with HTTP and HTTPS protocols. With this, content and path based routings are enabled thus allowing requests to be routed to different applications behind a single load balancer.

We can add up to 10 different applications behind a single Application Load Balancer ( ALB ) with a Path based routing feature. Another advantage is that has native support for micro services and container based architectures. Another advantage with the ALB over CLB is that CLB can be used with one port at a time, where as ALB supports multiple ports.

Host Based Routing : let's say we have 2 web sites “jagadish.com”  and “jagadish.admin.com”. Both of these websites are hosted on two Ec2 instances. Now if we want to route requests coming from different users to these different websites, we can create using ALB. this is not possible using the CLB.

Path Based Routing : Similarly when we have a single website with 2 different paths like “jagadish.com/blog” and “jagadish.com/page” and want requests to be routed, an ALB can be used here which is not possible by CLB.

Network Based Balancer ( NLB) -The Network load balancer on the other hand operates on the network layer of the OSI model. One of the main advantages of using NLB is during the sudden spikes in the application access.

Let's say we have an application running on multiple Ec2 instances and ALB is used to route traffic. Now another feature is launched in the application and traffic is increased with millions of requests. In this case ALB may not be able to handle the sudden spike in traffic. This is where NLB comes into the picture. NLB has the capability to handle a sudden spike in traffic since it works at the connection level. Since it works at the connection level, it is capable of handling millions of requests per second securely while maintaining ultra low latencies.

• NLB Provides the Support for static IP addresses for the load balancer.
• Provides support for registering targets by IP address which includes target outside the VPC for the Load Balancer.
• Provides support for monitoring the health of each service independently.

Monitoring Load Balancer - Since Load Balancer are managed services, we don't have a way to login to them by ssh and see what's happening. We can use CloudWatch Metrics & Alerts and also access logs for monitoring load balancers.

Metrics like “HealthyHostCount”, “Latency” and “Rejected Connection Count” can be monitored to understand how Load balancer is working.

Load Balancer logs are generated every 5 minutes and stored in S3. We will pay the s3 expenses but we won't pay for data transfer to the S3. Access logs don't not guarantee that every request will be written to that.Some records may be missing and Amazon does warn that “Elastic Load Balancing logs requests on a best-effort basis.”

in the next article, we will see a demo on how to use the Load Balancer in Aws.