AWS ELB

Hello everyone, I think it’s been a long time that we had a discussion on AWS topics. So today I came up with a new and exciting concept called AWS Elastic Load Balancer(ELB). Before getting into this topic first let us discuss some usecase scenario like in which situation this Load Balancer will help us.

Suppose, you are running an application and everything is working fine as of now. But in future if the number of users to your application will be increases then the traffic also will increase. If traffic is increasing then do you think that your application will be able to serve all requests at a time or parallel ?, even if it serve all requests then what about the latency which means the response duration between the user and the server ?. Another issue is if any instance fails then all requests to that instance will be terminated, then we should have to down the server until and unless that instance is recovered from the failure or another new instance is created. I think everyone faced one common issue while searching for some most popular websites, that is “Not able to reach the server”. This error or message will come because of so many reasons like destination server is not sending packets etc. but the most common reason is when the application is reaching maximum number of requests means when overloading occurs.

So like that there are so many problems will generate when our application is reaching more number of requests. The best and simple solution for solving all those issues is using AWS ELB. Let’s discuss in detail about ELB.

What is AWS ELB ?

Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions. It can handle the varying load of your application traffic in a single Availability Zone or across multiple Availability Zones.

In other words or simple words, Elastic Load Balancer will distributes the traffic evenly across multiple Availability Zones. For example we deployed 4 instances in two AZ’s like A and B instances in one AZ and C and D instances in second AZ and if we place a ELB on top of AZ’s then whatever the requests will come, then the ELB will distributes that requests evenly across multiple AZ’s like in our example it will distribute 50% of the traffic to one AZ and 50% of the traffic to other AZ. So like that based on the number of instances that we have in multiple AZ’s, it will automatically distribute the traffic evenly.

Also ELB won’t allow anonymous or malicious requests, it is highly secured.

Architecture of AWS ELB

Image source: https://aws.amazon.com/blogs/devops/introducing-application-load-balancer-unlocking-and-optimizing-architectures/

In the beginning of this article we have discussed like what if an instance fails and how ELB will help us to solve this issue. Here we have a concept called ELB HealthChecks.

How ELB HealthChecks works ?

The ELB HealthCheck is used by AWS to determine the availability of registered EC2 instances and their readiness to receive traffic. Any downstream server that does not return a healthy status is considered unavailable and will not have any traffic routed to it.

The load balancer checks the health of the registered instances using either the default health check configuration provided by Elastic Load Balancing or a health check configuration that you configure.

The load balancer sends a health check request to each registered instance every interval seconds, using the specified port, protocol, and ping path. Each health check request is independent and lasts the entire interval. The time it takes for the instance to respond does not affect the interval for the next health check. If the health checks exceed UnhealthyThresholdCount consecutive failures, the load balancer takes the instance out of service. When the health checks exceed HealthyThresholdCount consecutive successes, the load balancer puts the instance back in service.

An HTTP/HTTPS health check succeeds if the instance returns a 200 response code within the health check interval. A TCP health check succeeds if the TCP connection succeeds. An SSL health check succeeds if the SSL handshake succeeds.

Ping protocols: TCP, HTTP, HTTPS and SSL.

Ping port: The port to use to connect with the instance, as a protocol:port pair. If the load balancer fails to connect with the instance at the specified port within the configured response timeout period, the instance is considered unhealthy.

Ping port range: 1 to 65535

Ping path: The destination for the HTTP or HTTPS request. An HTTP or HTTPS GET request is issued to the instance on the ping port and the ping path. If the load balancer receives any response other than “200 OK” within the response timeout period, the instance is considered unhealthy.

Response Timeout: The amount of time to wait when receiving a response from the health check, in seconds. Valid time is 2 to 60 seconds.

HealthCheck Interval: The amount of time between health checks of an individual instance, in seconds. Valid time is 5 to 300 seconds.

Unhealthy Threshold: The number of consecutive failed health checks that must occur before declaring an EC2 instance unhealthy.

Healthy Threshold: The number of consecutive successful health checks that must occur before declaring an EC2 instance healthy.

How ELB works ?

A load balancer accepts incoming traffic from clients and routes requests to its registered targets (such as EC2 instances) in one or more Availability Zones. The load balancer also monitors the health of its registered targets and ensures that it routes traffic only to healthy targets. When the load balancer detects an unhealthy target, it stops routing traffic to that target. It then resumes routing traffic to that target when it detects that the target is healthy again.

You configure your load balancer to accept incoming traffic by specifying one or more listeners. A listener is a process that checks for connection requests. It is configured with a protocol and port number for connections from clients to the load balancer. Likewise, it is configured with a protocol and port number for connections from the load balancer to the targets.

Elastic Load Balancing supports three types of load balancers:

• Application Load Balancers
• Network Load Balancers
• Classic Load Balancers

There is a key difference in how the load balancer types are configured. With Application Load Balancers and Network 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.

A target group tells a load balancer where to direct traffic to : EC2 instances, fixed IP addresses; or AWS Lambda functions, amongst others. When creating a load balancer, you create one or more listeners and configure listener rules to direct the traffic to one target group.

Application Load Balancer

An Application Load Balancer makes routing decisions at the application layer (HTTP/HTTPS), supports path-based routing, and can route requests to one or more ports on each container instance in your cluster. Application Load Balancers support dynamic host port mapping.

After the load balancer receives a request, it evaluates the listener rules in priority order to determine which rule to apply, and then selects a target from the target group for the rule action. You can configure listener rules to route requests to different target groups based on the content of the application traffic. Routing is performed independently for each target group, even when a target is registered with multiple target groups. You can configure the routing algorithm used at the target group level. The default routing algorithm is round robin; alternatively, you can specify the least outstanding requests routing algorithm.

A load balancer serves as the single point of contact for clients.

A listener checks for connection requests from clients, using the protocol and port that you configure.

Each target group routes requests to one or more registered targets, such as EC2 instances, using the protocol and port number that you specify.

Image source: AWS Docs

Network Load Balancer

A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP connection to the selected target on the port specified in the listener configuration.

In other words, AWS Network Load Balancer (NLB) is an AWS tool that distributes end user traffic across multiple cloud resources to ensure low latency and high throughput for applications. When a target becomes slow or unavailable, the Network Load Balancer routes traffic to another target.

Image source: AWS Docs

Classic Load Balancer

Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances and operates at both the request level and connection level. Classic Load Balancer is intended for applications that were built within the EC2-Classic network.

A Classic Load Balancer makes routing decisions at either the transport layer (TCP/SSL) or the application layer (HTTP/HTTPS). Classic Load Balancers currently require a fixed relationship between the load balancer port and the container instance port.

For example, it is possible to map the load balancer port 80 to the container instance port 3030 and the load balancer port 4040 to the container instance port 4040. However, it is not possible to map the load balancer port 80 to port 3030 on one container instance and port 4040 on another container instance. This static mapping requires that your cluster has at least as many container instances as the desired count of a single service that uses a Classic Load Balancer.

Image source: https://teke42.wordpress.com/2018/03/07/load-balancing-with-aws-and-ansible/

To know more about types of load balancers, click here.

NOTE: Sometimes attackers are trying to access our wensite they made our website unavailable to end users those attacks are called DOS or DDOS attacks. To know more about this attacks and what are the AWS best practices DDOS resiliency, read this white paper.

We have a new concept called Cross-Zone Load Balancing which will help us like each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.

Cross-Zone Load Balancing

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

With Application Load Balancers, cross-zone load balancing is always enabled.

With Network Load Balancers, cross-zone load balancing is disabled by default.

When you create a Classic Load Balancer, the default for cross-zone load balancing depends on how you create the load balancer.

When cross-zone load balancing is enabled ?

Each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.

If cross-zone load balancing is enabled, each of the 10 targets receives 10% of the traffic. This is because each load balancer node can route its 50% of the client traffic to all 10 targets.

Image source: AWS Docs

When cross-zone load balancing is disabled ?

Each load balancer node distributes traffic only across the registered targets in its Availability Zone.

Each of the two targets in Availability Zone A receives 25% of the traffic. Each of the eight targets in Availability Zone B receives 6.25% of the traffic.

Image source: AWS Docs

AWS ELB Related Services

1. Amazon EC2
2. Amazon EC2 Auto Scaling
3. Amazon Certificate Manager
4. Amazon CloudWatch
5. Amazon ECS
6. Amazon Global Accelerator
7. Route 53
8. AWS WAF

To know more about related services, click here.

AWS ELB Use Cases

1. Achieve better fault tolerance for your applications
2. Automatically load balance your containerized applications
3. Automatically scale your applications
4. Using Elastic Load Balancing in your Amazon Virtual Private Cloud (Amazon VPC)
5. Hybrid load balancing with Elastic Load Balancing
6. Invoking Lambda functions over HTTP(S)

Benefits

1. Highly Available
2. Elastic
3. Secure
4. Flexible
5. Robust monitoring and auditing
6. Hybrid load balancing

That’s it guys, I have covered everything about AWS ELB and how ELB will be benefited for your application. I hope everyone understood about ELB now, still if anyone has any suggestions or doubts, do comment here or contact us at any time. We as a team are always ready to help you out at any situation.

Thank you!!!