AWS Elastic Load Balancer: Traffic exposes

What is Load Balancing?

Load balancing is a technique that distributes network or application traffic across several servers. This can improve performance, reliability, and availability.

Load balancers work by receiving requests from clients and then routing them to one of the servers in the pool. The load balancer uses a variety of factors to determine which server to send a request to, such as the server’s load, availability, and health.

In Amazon EC2, Elastic Load Balancing (ELB) is the load balancing service provided by AWS.

Elastic Load Balancing

Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones.

It monitors the health of its registered targets, and routes traffic only to the healthy targets.

Elastic Load Balancing scales your load balancer capacity automatically in response to changes in incoming traffic.

How does Elastic Load Balancing work?

• Clients make requests to your application.
• The listeners in your load balancer receive requests matching the protocol and port that you configure.
• The receiving listener evaluates the incoming request against the rules you specify, and if applicable, routes the request to the appropriate target group. You can use an HTTPS listener to offload the work of TLS encryption and decryption to your load balancer.
• Healthy targets in one or more target groups receive traffic based on the load-balancing algorithm, and the routing rules you specify in the listener.

The benefits of load balancing:

• Improved performance: Load balancing can improve performance by distributing traffic across multiple servers. This can help to reduce latency and improve response times.
• Increased reliability: Load balancing can increase reliability by ensuring that no single server is overloaded. If one server goes down, the load balancer can redirect traffic to the remaining servers.
• Improved availability: Load balancing can improve availability by ensuring that your applications are always available. If one server goes down, the load balancer can redirect traffic to the remaining servers.

ELB can be created, accessed, and managed by using AWS Management Console, AWS Command Line Interface, AWS SDKs, and Query API.

Elastic Load Balancing supports the following types of load balancers:

1- Application Load Balancers

2- Network Load Balancers

3- Gateway Load Balancers

4- Classic Load Balancers

There is a key difference in how the load balancer types are configured:

• With Application Load Balancers, Network Load Balancers, and Gateway Load Balancers, you register targets in target groups, and route traffic to the target groups.
• With Classic Load Balancers, you register instances with the load balancer.

Cross-zone load balancing

The nodes for your load balancer distribute requests from clients to registered targets.

When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.

When cross-zone load balancing is disabled, each load balancer node distributes traffic only across the registered targets in its Availability Zone.

• With Application Load Balancers, cross-zone load balancing is always enabled at the load balancer level.
• At the target group level, cross-zone load balancing can be disabled.
• With Network Load Balancers and Gateway Load Balancers, cross-zone load balancing is disabled by default. After you create the load balancer, you can enable or disable cross-zone load balancing at any time.

When you create a Classic Load Balancer, the default for cross-zone load balancing depends on how you create the load balancer. With the API or CLI, cross-zone load balancing is disabled by default. With the AWS Management Console, the option to enable cross-zone load balancing is selected by default.

Now let us understand the different types of ELB provided by AWS:

Application Load Balancer

Here is the official documentation of the Application Load Balancer.

ALB Functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model.

It intelligently distributes incoming HTTP and HTTPS traffic to target instances, containers, or IP addresses based on the rules and configurations set by the user.

Network Load Balancer

Here is the official documentation of the Network Load Balancer.

NLB functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second.

NLB operates at the transport layer (Layer 4) of the OSI model and is designed to handle TCP, UDP, and TLS traffic.

It is highly scalable, offers low latency, and is suitable for applications that require high performance and extreme scalability.

Gateway Load Balancer

Here is the official documentation of the Gateway Load Balancer.

A Gateway Load Balancer operates at the third layer of the Open Systems Interconnection (OSI) model, the network layer.

It listens for all IP packets across all ports and forwards traffic to the target group that’s specified in the listener rule.

It maintains the stickiness of flows to a specific target appliance using a 5-tuple (for TCP/UDP flows) or 3-tuple (for non-TCP/UDP flows).

Classic Load Balancer

Here is the official documentation of the Classic Load Balancer.

CLB operates at both the application layer (Layer 7) and transport layer (Layer 4) of the OSI model and is ideal for applications that require basic load-balancing features.

CLB provides basic load-balancing capabilities for distributing incoming traffic across multiple Amazon EC2 instances.

Here is the link which gives the product differentiation and pricing of the different ELBs provided by AWS.

Application LoadBalancer:-

Key Components of an Application Load Balancer

1. Load Balancer:

• Serves as the primary contact point for clients.
• Distributes incoming application traffic to various targets, like EC2 instances, across multiple Availability Zones, enhancing overall application availability.

2. Listeners:

• Responsible for handling connection requests from clients.
• Operate on specified protocols and ports that you configure.
• Rules defined for each listener guide how the load balancer routes requests to its registered targets.
• Rules include a priority, one or more actions, and conditions. Actions are executed when rule conditions are met.
• It’s crucial to define a default rule for each listener, and additional rules can be optionally configured.

3. Target Groups:

• Route requests to one or more registered targets, such as EC2 instances.
• Defined by the protocol and port number specified.
• Targets can be registered with multiple target groups for added flexibility.
• Health checks are configurable on a per target group basis.
• Health checks assess the well-being of all targets within a group specified in a listener rule for the load balancer.

How Application Load Balancer Works:

• Content-Based Routing: ALB can route traffic based on content, examining HTTP/HTTPS headers, allowing for advanced routing decisions.
• Path-Based Routing: It can route requests based on the URL path, directing traffic to different backend services.
• Host-Based Routing: ALB supports routing based on the host header, enabling serving multiple applications from the same load balancer.
• Containerized Applications: ALB is well-suited for containerized applications, efficiently managing traffic within a containerized environment.

Why Application LB has More Functions Compared to Network LB:

• Layer 7 vs. Layer 4: Application LB operates at Layer 7 (application layer), offering more advanced routing based on content, while Network LB operates at Layer 4 (transport layer), focusing on routing based on IP addresses and ports.
• Content Awareness: ALB understands the content of the traffic, making it ideal for modern applications with dynamic routing needs.
• Flexible Routing: ALB’s ability to route based on various factors like path, host, and content provides greater flexibility compared to Network LB.

Tasks

Task 1: Launch 2 EC2 instances with an Amazon Linux and use User Data to install the Apache Web Server. Modify the index.html file and Launch

Create two EC2 instances with the following details:

Name: Apache-Server

Application and OS Images (Amazon Machine Image): Amazon ec2 AMI

Instance type: t2.micro

Key pair (login): Select the key pair you want.

Network Settings: Check the boxes “Allow HTTPS traffic from the Internet” & “Allow HTTP traffic from the Internet”

Advanced details:

Scroll down to the User data box and type these commands:

#!/bin/bash
sudo su
yum install httpd -y
systemctl start httpd
echo "Hello, Nivas..!Great day " >/var/www/html/index.html

Same things do in second instance only change some part which ig given below

#!/bin/bash
sudo su
yum install httpd -y
systemctl start httpd
echo "Welcome to DevOps World..!" >/var/www/html/index.html

Remember that select different-different Avalibality zone for both instance.

→ After we will create a Target Group Go to AWS Console and search Target Group open and click on create target group

Give target name accourding your and after scroll down and click on next

Select the instance which have you created

Scroll down and click on create create target group

Our target group is created

After all these things we need to create a load balance and attached to target group

Click on create Application Load Balancer

Give the name of Load Balancer accourding to your

create new security group and assign

Select target group which you have created and after scroll down and click on create

After copy the DNS Name and open in new tab

and refresh again and again

And we have created an ALB, and created the load!

Key Differences: ALB vs NLB

• OSI Layer: Application Load Balancer (as the name implies) works at the Application Layer (Layer 7 of the OSI model, Request level). Network Load Balancer works at the Transport layer (Layer 4 of the OSI model, Connection level).
• Routing: NLB just forward requests whereas ALB examines the contents of the HTTP request header to determine where to route the request. So, an ALB support advanced request (content-based) routing.
• Static IP: ALB doesn’t provide support for static IP addresses whereas NLB provides support for zonal static IP addresses (in each AZ).
• PrivateLink (Endpoint services): NLB provides support for PrivateLink with VPC Endpoints Service integration whereas ALB doesn’t support PrivateLink. Only NLB can be used directly as PrivateLink.
  Elastic Load Balancing now supports forwarding traffic directly from NLB to ALB. With this feature, you can now use AWS PrivateLink and expose static IP addresses for applications built on ALB.
• AWS Load Balancer Controller for Kubernetes: controller provisions ALB when you create a Kubernetes Ingress and NLB when you create a Kubernetes service of type LoadBalancer.
• Application availability: NLB cannot assure the availability of the application. This is because it bases its decisions solely on a network and TCP-layer variables and has no awareness of the application at all. Generally, NLB determines availability based on the ability of a server to respond to ICMP ping or to correctly complete the three-way TCP handshake. ALB goes much deeper and is capable of determining availability based on not only a successful HTTP GET of a particular page but also the verification that the content is as was expected based on the input parameters.
• When considering the deployment of multiple applications on the same host sharing IP addresses (virtual hosts), NLB will not differentiate between Application-A and Application-B when checking availability (indeed it cannot unless ports are different) but ALB will differentiate between two applications by examining the application layer data available to it. This difference means that NLB may end up sending requests to an application that has crashed or is offline, but ALB will never make that same mistake.
• Security: ALB and NLB, both support Security Groups. (Updates on Aug 10, 2023, Network Load Balancer now supports security groups)

In this blog, I have discussed how to create an AWS Application Load Balancer and use it to balance the load between two web servers. If you have any questions or would like to share your experiences, please leave a comment below. Don’t forget to read my blogs and connect with me on LinkedIn and let’s have a conversation.

To help me improve my blog and correct my mistakes, I am available on LinkedIn as www.linkedin.com/in/iamnivas Do reach me and I am open to suggestions and corrections.