AWS for beginners - Elastic Load Balancing

Let’s say that we have an application which runs on an AWS EC2 instance (i.e. a server).

As our application grows we launch more EC2 instances to manage the increasing traffic. We may even add the new instances to another availability zone to increase fault tolerance.

If the traffic is kept being routed to the same EC2 instance, there’s no point adding more instances. We’ll need something that distributes traffic across these instances. We need something that evenly balances the traffic.

1. What is a load balancer?

This is where Elastic Load Balancing comes into the picture.

Elastic Load Balancer (ELB) distributes the incoming traffic across multiple instances, and provides a single point of contact to our application.

This means that the user doesn’t directly connect to the multiple EC2 instances. The ELB will have a publicly available DNS name, and the registered EC2s will be hidden behind the ELB.

In order for the ELB to route traffic across EC2 instances, they have to be registered with the ELB, i.e. the load balancer has to be aware of the instances it needs to route the traffic to.

The ELB balancer is confined to a region, but it can serve EC2 instances in multiple Availability Zones within that region.

If the application is distributed across multiple regions, an ELB needs to be activated in each region, and AWS’s domain name service, Route 53 should be used.

2. How does ELB work?

The ELB is the single point of contact to the application.

As mentioned above, ELB has a public DNS name, which can be mapped to the name of our application.

Say that our app is served under www.myawesomewebsite.com. If the ELB is activated, all traffic directed to www.myawesomewebsite.com is sent to the ELB.

The ELB contains the list of private (i.e. publicly unavailable) IP addresses of all registered EC2 instances. The incoming traffic will be routed to the address of the least loaded healthy instance.

2.1. Listeners

In order for the user to reach the EC2 instances through the ELB, we need to add listeners to the ELB.

Listeners filter incoming traffic based on protocols and ports. For example, the ELB can be configured to listen to HTTP protocol port 80.

If the incoming traffic from the client arrives on port 80, then the ELB will forward the traffic to an EC2 instance. If the request comes on another port, the ELB will block the traffic, which won’t reach the instance.

This doesn’t mean though that every incoming traffic has to go through the load balancer. It can happen that we want to establish a direct connection to the EC2 instance through its public IP address. An example is when we as admins want to log on the server using SSH. But traffic from everyday users and clients should go through the ELB.

2.2. Health checks

As stated above the ELB performs regular health checks on the EC2 instances.

During these health checks the ELB verifies that the EC2 instance is live and responds to the connection requests.

By default, the ELB pings the EC2 instances every 30 seconds, and expects a response in 5 seconds. This can be considered as one health check. If two consecutive health checks fail (i.e. no response comes within 5 seconds), the ELB will qualify the instance as unhealthy.

When an instance becomes unhealthy, the ELB stops routing traffic to it, and will forward traffic to a healthy instance instead.

3. Types of load balancers

AWS offer three types of load balancers: Classic Load Balancer, Application Load Balancer and Network Load Balancer.

3.1. Classic Load Balancer (CLB)

The CLB operates at both network (transport) and application levels and the targets (e.g. EC2s) are added directly to the load balancer.

For CLSs, the listeners can be configured at both network (e.g. TCP) and application (e.g. HTTP) levels.

Although CLBs can still be created, AWS consider them as legacy, and recommend the use of the other two types of load balancers.

3.2. Application Load Balancer (ALB)

The location of the ALB in the AWS ecosystem can be seen in the first picture above.

ALBs work at the application level of the OSI model.

Here, when the listeners are configured, we need to specify target groups and rules.

EC2 instances belong to target groups, and health checks are performed on a target group basis. It’s possible to register an EC2 instance to multiple target groups.

Each listener comes with a default rule and we can also create other rules. The rules are prioritized, and when the traffic comes in, the rules will be evaluated in priority order, and the ALB will select one target (EC2) to route the traffic to.

3.3. Network Load Balancer (NLB)

NLBs work at the network level (Layer 4) of the OSI model, hence the name. They are high performance load balancers and can handle millions of requests per second.

Similarly to the ALB, NLBs can have target groups configured. They provide high availability, high throughput and low latency.

4 Monitoring

ELBs continually monitor the status of the EC2 instances during health checks. When an instance is found to be healthy, it will be marked as InService. The status of the unhealthy instances is OutOfService.

The easiest way to check the statuses is to log in to the console and have a look at the Load Balancers section. Or, alternatively, we can use the AWS CLI for this job.

It’s possible to receive information about the status of the ELB itself through CloudWatch, which is AWS’s monitoring system. ELBs send metrics about themselves to CloudWatch every minute.

Information about requests (client IP address, paths, server responses) sent to the load balancer can also be monitored through the access logs, which is an optional feature. It can be enabled by logging in to the console.

5. Conclusion

ELB is an extremely important part of the AWS architecture. They route traffic between the registered EC2 instances based on the instances’ load and health condition.

ELBs perform regular health checks on the EC2 instances. If an instance is determined to be unhealthy, the load balancer will stop routing traffic to that instance, and will select a healthy instance instead.

AWS provide three types of load balancers, which differ in the protocols they filter requests at and how the instances are registered.

Thanks for reading and see you next time.