Elastic Load Balancer Service
In this post, I will focus on what the AWS Elastic Load Balancer service is and does. The main function of an Elastic Load Balancer, commonly referred to as an ELB, is to help manage and control the flow of inbound requests destined to a group of targets by distributing these requests evenly across the targeted resource group.
These targets could be a fleet of EC2 instances, Lambda functions, a range of IP addresses, or even Containers.
The targets defined within the ELB could be situated across different Availability Zones for additional resiliency or all placed within a single Availability Zone.
Let’s suppose you have just created a new application, which is currently residing on a single EC2 instance within your environment, and this is being accessed by a number of users. At this stage, your architecture can be logically summarized as shown.
If you are familiar with architectural design and best practices, then you would realize that using a single instance approach isn’t ideal although it would certainly work and provide a service to your users. However, this infrastructure layout brings some challenges. For example, the single instance where your application is located can fail, perhaps from a hardware or software fault. And if that happens, your application will be down and unavailable to your users.
Also, if you experience a sudden spike in traffic, your instance may not be able to handle the additional load based on its performance limitations.
As a result, to strengthen your infrastructure and help remediate these challenges, the unpredictable traffic spikes and high availability, et cetera, you should introduce an Elastic Load Balancer, an additional instance that’s running your application into the design as shown.
As you can see, in this design, the AWS Elastic Load Balancer will act as the point for receiving incoming traffic from users and evenly distribute the traffic across a greater number of instances.
By default, the ELB is highly available as this is a managed service provided by AWS.
And so, they ensure its resilience so we don’t have to. Although it might seem that ELB is a single point of failure, the ELB is in fact comprised of multiple instances managed by AWS. Also in this scenario, we now have three instances running our application.
Now let me revisit the challenges we discussed previously. If any of these three instances fail, the ELB will automatically detect the failure based on defined metrics and divert any traffic to the remaining two healthy instances.
Also if you experience a surge in traffic, then the additional instances running your application would help with the additional load.
One of the many advantages of using ELB is the fact that it is managed by AWS, and it is, by definition, elastic. This means that it will automatically scale to meet your incoming traffic as the incoming traffic scales both up and down.
Types of ELBs
If you are system administrator or DevOps engineer running your own load balancer by yourself, then you would need to worry about scaling your load balancer and enforcing high availability. With an AWS ELB, you can create your load balancer and enable dynamic scaling with just a few clicks. Depending on your traffic distribution requirements, there are three ELBs available within AWS to choose from.
Firstly, the Application Load Balancer: This provides a flexible feature set for your web applications running the HTTP or HTTPS protocols. The Application Load Balancer operates at the request level, and it also provides advanced routing, TLS termination, and visibility features targeted at application architectures, allowing you to route traffic to different ports on the same EC2 instance.
Next, there is a Network Load Balancer. This is used for ultra-high performance for your application while at the same time managing very low latencies. It operates at connection level, routing traffic to targets within your VPC, and it’s also capable of handling millions of requests per second.
Finally, the Classic Load Balancer. This is primarily used for applications that were built in the existing EC2 Classic environment and operates at both the connection and request level.
We’ll now talk a little bit about the components of an AWS ELB and some of the principles behind them.
Listeners: For every load balancer, regardless of the type used, you must configure at least one listener. The listener defines how your inbound connections are routed to your target groups based on ports and protocols set as conditions. The configurations of the listener itself differs slightly depending on which ELB type is selected.
Target groups: A target group is simply a group of resources that you want your ELB to route requests to, for example a fleet of EC2 instances. You can configure your ELB with a number of different target groups, each associated with a different listener configuration and associated rules. This enables you to route traffic to different resources based upon the type of request.
Rules: Rules are associated to each listener that you have configured within your ELB, and they help to define how an incoming request gets routed to which target group.
As you can see, your ELB can contain one or more listener. And each listener can contain one or more rules, and each rule can contain more than one condition, and all conditions in the rule equal a single action.
An example rule could look as follows where the if statement resembles the conditions and the then statement acts as the action if all the conditions are met.
So, depending on which listener request was responded to by the ELB, a rule based upon a priority listing would be associated containing these conditions and actions. If the request came from within the
10.0.1.0/24 network range, which is the first condition, and was trying to carry a
HTTP PUT request, the second condition, then the request would be sent to the target group entitled
Group1, which is the action.
- Health checks: The ELB associates a health check that is performed against the resources defined within the target group. These health checks allow the ELB to contact each target using a specific protocol to receive a response. If no response is received within a set of thresholds, then the ELB will mark the target as unhealthy and stop sending traffic to that target.
- Internal or Internet-facing ELBs: There are two different schemes that can be used for your load balancers, either internal or Internet-facing.
- Internet-facing, as the name implies, the nodes of the ELBs that are defined as Internet-facing are accessible via the Internet and so have a public DNS name that can be resolved with public IP address. This would be in addition to an internal IP address as well. This allows the ELB to serve incoming requests from the Internet before distributing and routing the traffic to your target groups, which in this instance could be a fleet of web servers receiving HTTP or HTTPS requests. When your Internet-facing ELB communicates with its target group, it will only use the internal IP address, meaning that your target group does not need public IP addresses.
- An internal ELB only has an internal IP address. This means that it can only serve requests that originate from within your VPC itself. For example, you might have an internal load balancer sitting between your web servers in the public subnet and your application servers in the private subnet.
- ELB nodes: During the creation process of your ELBs, you’re required to define which Availability Zone you’d like your ELB to operate within. For each Available Zone selected, an ELB node will be placed within that Availability Zone. As a result, you need to ensure that you have an ELB node associated to any Availability Zones for which you want to route traffic to. Without the Availability Zone associated, the ELB will not be able to route traffic to any targets within that Availability Zone even if they are defined within the target group. This is because the nodes are used by the ELB to distribute traffic to your target groups.
- Cross-Zone Load balancing: Depending on which ELB option you select, you may have the option of enabling and implementing Cross-Zone load balancing within your environment. Let’s presume you have two Availability Zones activated for your ELB with each associated load balancer receiving equal amount of traffic. One Availability Zone has six targets, and the other has four as shown. When Cross-Zone load balancing is disabled, each ELB and its associated AZ would distribute its traffic with the targets within that Availability Zone only. As we can see from the image, this results in an uneven distribution of traffic for each target across the Availability Zones. With Cross-Zone load balancing enabled, regardless of how many targets are in an associated Availability Zone, the ELBs would distribute all incoming traffic evenly between all targets, ensuring each target across the Availability Zones have an even distribution.
Application Load Balancer
If you are familiar with the open systems interconnection model, the OSI model, then you won’t be surprised that the ALB operates at layer seven, the application layer. The application layer of the OSI model serves as the interface for users and application processes to access network services.
Everything at this layer is application specific. The application layer of the model helps to provide network services to the applications. And examples of the application process or services it offers are http, ftp, smtp and nfs.
As you can see AWS suggests you use the application load balancer if you need to provide a flexible feature set including advanced routing and visibility features aimed purely for application architectures such as microservices and containers when used in HTTP or HTTPS.
Before configuring your ALB, it’s good practice to set up your target groups. As explained earlier that a target group is simply a group of resources that you want your ALB to route requests to. You might want to configure different target groups depending on the nature of your requests. For example, let’s say you had in internet-facing ALB, you might want to target group allocated to handle and process HTTP port 80 requests and a different target group configured to process requests from the secure HTTPS protocol using port 443. In this scenario, you could configure two different target groups and then route traffic, depending on the request, to different targets through the use of listeners and rules.
Network Load Balancer
Between the ALB and the NLB, the principles are the same as to how the overall process works, so to load balance incoming traffic from a source to its configured target groups. However, whereas the ALB work to the application level analyzing the HTTP header to direct the traffic, the network load balancer operates at Layer 4 of the OSI model enabling you to balance requests purely based on the TCP and UDP protocols.
As such, a request to open a TCP or UDP connection is established to load balance the host in the target group. The listener supported by the NLB include TCP, TLS and UDP. The NLB is able to process millions of requests per second making the NLB a great choice if you need ultra high performance for your application. Also if your application logic requires a static IP address, then the NLB will need to be your choice of elastic load balancer.
Unlike the application load balancer that has cross-zone load balancing always enabled, for the NLB this can either be enabled or disabled. When your NLBs are deployed and associated to different availability zones, an NLB node will be provisioned in these availability zones. The node then uses an algorithm which uses details based on the sequence, the protocol, source port, source IP, destination port and destination IP to select the target in that zone to process the request. When a connection is established with a target host, then that connection will remain open with that target for the duration of the request. Let me now provide a demonstration on how to configure and set up a network load balancer.
Classic Load Balancer
The classic load balancer supports TCP, SSL/TLS, HTTP, and HTTPS protocols. However, it does not offer as wide a range of features as the other load balancers. It is considered best practice to use the ALB over this classic load balancer unless you have an existing application running in the EC2-Classic network.
Now, many of you will be unfamiliar with the EC2-Classic platform, and this is because it is no longer supported for newer AWS accounts. In fact, any account created after the 12th of April 2013 will not support EC2-Classic.
The EC2-Classic platform was originally introduced when the first release of EC2 was made generally available a number of years ago. The EC2-Classic platform enabled you to deploy your EC2 instances in a single flat network shared with other customers instead of inside a VPC. Although the classic load balancer doesn’t provide as many features as the application load balancer, it does offer the following which the ALB does not. It supports EC2-Classic, it supports TCP and SSL listeners, and it has support for sticky sessions using application-generated cookies.
Again, the classic load balancer works in much the same way as the other load balancers already discussed, and again, cross-zone load balancing can either be enabled or disabled.
ALB is the most feature-rich. However, the NLB supports some significant differences to that of the ALB, such as support for static IPs, EIPs, and preserving source IP addresses. Check the comparison table to decide which one meets your needs.