Designing Compute Solutions in AWS – Elastic Load Balancers

ELB helps to ensure that your application is highly available and scalable by distributing incoming traffic across multiple resources. It can also help to improve the performance of your application by evenly distributing traffic across your resources and automatically scaling them to meet demand. The Elastic Load Balancing Service (ELB) provides the Application Load Balancer for HTTP/HTTPS workloads and the Network Load Balancer for TCP/UDP workloads. The Gateway Load Balancer can deploy and manage third-party load balancer virtual appliances such as Nginx, Cisco, and Broadcom.

For each load balancer ordered, you are charged a small monthly fee, plus data transfer charges based on the number of Load Balancer Capacity Units (LCUs) used every hour. The LCU is the hourly aggregate total of incoming traffic requests based on new and active connections, consumed bandwidth, and the number of listener rules evaluated.

Application Load Balancers (ALB)

The ALB operates at layer 7, the application layer. The application layer serves as the interface for users and application processes to access network services. Examples of application processes or services it offers are HTTP, FTP and SMTP.

Application load balancers deploy SSL offloading performing decryption on the incoming connection request; SSL traffic is terminated on the load balancer sending the decrypted request to the registered target.

Application load balancers support load-balancing containers running the same service on the same EC2 instance where the containers are hosted. When Amazon EC2 Container Service (ECS) task definitions are launched multiple times on the same EC2 instance, the containers are running duplicates of the same service; the dynamic port mapping process assigns a random port to each container task.

When an EC2 instance that is registered with a load balancer is tagged as unhealthy by failing its health checks, the connections to the instance are closed through a process called connection draining. From the point of view of the load balancer, the connection draining process keeps existing connections open until the client closes them but prevents new requests from being sent to the instances that are tagged as unhealthy. Connection draining removes select EC2 instances from a load balancer target group when maintenance is required. An EC2 instance that is in the process of deregistering will not accept new connection requests.

Application Load Balancer allows you to offload the authentication process so the load balancer can authenticate users as they request access to cloud applications. ALB integrates with AWS Cognito, which allows both web-based and enterprise identity providers to authenticate through the ALB.

Network Load Balancers (NLB)

ELB Network Load Balancer (NLB) is a load balancing service that distributes incoming traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses, in one or more AZ. Network Load Balancer provides TCP and UDP load balancing at Layer 4 of the OSI stack. NLB uses a flow-based algorithm to distribute traffic to the targets in a target group. This means it distributes traffic based on the number of connections rather than on the amount of data transferred. The NLB can scale to handle millions of requests per second at very low latencies. It can also integrate with EC2 Auto Scaling, Amazon ECS, and AWS ACM. NLB supports end-to-end encryption using TLS.

  • Application Load Balancer Routing uses round robin, or you can select outstanding requests algorithm.
  • Network Load Balancer Routing uses flow hash algorithm.
  • Classic Load Balancer Routing uses round-robin algorithm.

For every request that arrives at an ELB, the load balancer establishes two connections: one with the client application, and another one with the target destination. To make sure that these connections are only kept alive for as long as they are in use, your load balancer has an idle timeout period that monitors the state of these connections. An ELB idle timeout is the number of seconds that a connection has to send new data to keep the connection alive. Once the period elapses and there has been no transfer of new data, the load balancer closes the connection. This allows new connections to be established without using up all your connection resources. For network operations that take a long time to complete, you should send at least one byte of new data before your idle timeout elapses to maintain the connection. The default idle timeout for load balancers is set at 60 seconds, but do note that having a longer idle timeout might make it easier to reach the maximum number of connections for your load balancer.

Multi-Region Failover

An NLB supports failover across AWS regions using Amazon Route 53 health checks, allowing organizations to create a highly available, globally distributed load-balancing solution that can route traffic to the optimal region based on the health of the targets in each region.

An NLB must be created in each AWS region where traffic will be load balanced. Then create a target group in each region that contains the regional targets to which to route traffic. Enable cross-zone load balancing for each NLB so traffic is distributed across the targets in each AZ.
Next, create an Amazon Route 53 health check for each target group. You can use the default health check configuration or customize the health check settings to meet your specific requirements.
Finally, create a Route 53 record set that points to the NLB in each AWS region. Choices are a weighted record set, or a latency-based record set to specify the routing policy for the record set. With a weighted record set the proportion of traffic that should be routed to each region is controlled based on the weights assigned to the record set. With a latency-based record set, Route 53 routes traffic to the region that provides the lowest latency for the end user.

Classic Load Balancers

The Classic Load Balancer (CLB) in AWS, supporting TCP, SSL/TLS, HTTP, and HTTPS protocols, can be enhanced by integrating with EC2 Auto Scaling for dynamic instance management, improving health check configurations for better reliability, employing SSL/TLS best practices for security, enabling sticky sessions for stateful applications, and leveraging CloudWatch for comprehensive monitoring and logging. While these enhancements can improve CLB’s performance and reliability, migrating to modern load balancers like ALB or NLB is advisable for advanced features, better scalability, and improved integration with current AWS services.

Using ELB and Auto Scaling Together

It’s easy to associate your EC2 Auto Scaling Group to an Elastic Load Balancer.

The ELB allows you to dynamically manage load across your resources based on target groups and rules.

EC2 autoscaling allows you to elastically scale those target groups based upon the demand put upon your infrastructure.

Let’s assume you have EC2 auto-scaling configured but no ELB. How are you going to evenly distribute traffic to your EC2 fleet? Combining an ELB and Auto Scaling helps you to manage and automatically scale your EC2 Compute resources both in and out. When you attach an ELB to an auto-scaling group, the ELB will automatically detect the instances and start to distribute all traffic to the resources in the auto-scaling group


ALB is the most feature-rich, however, NLB supports some significant differences to that of the ALB, such as support for static IPs, EIPs, and preserving source IP addresses.

CloudAcademy – Designing Compute solutions in AWS
Mark Wilkins – AWS Certified Solutions Architect – Associate (SAA-C03) Cert Guide (Certification Guide)
Jon Bonso – AWS Certified Solutions Architect Associate SAA-C03-Tutorials Dojo