Get best of the week

Load Balancing with AWS ELB

Hello everyone! The AWS for Developers course is starting today , and as a result, we have conducted the corresponding thematic webinar dedicated to the ELB review. We looked at the types of balancers and created several EC2 instances with a balancer. And also studied other examples of use.



After listening to the webinar , you will:

  • understand what AWS Load Balancing is;
  • Know the types of Elastic Load Balancer and its components;
  • Use AWS ELB in your practice.

Why be able to do this:

  • useful if you plan to take AWS certification exams;
  • This is an easy way to load balance between servers.
  • This is an easy way to add Lambda to your service (ALB).

An open lesson was conducted by Rishat Teregulov , a systems engineer in a marketing company for the development and support of sites.

Introduction


What is the Elastic Load Balancer, you can see in the diagram below, which shows a simple example:



Load Balancer accepts requests and distributes them across instances. We have one separate instance, there are Lambda functions and there is an AutoScaling group (server group).

AWS ELB Types


1. Consider the main types :

Classic Load Balancer. The very first balancer from AWS, works both on the 4th and 7th levels of OSI, HTTP, HTTPS, TCP and SSL are supported. It provides basic load balancing across multiple Amazon EC2 instances and works both at the request level and at the connection level. Let's open it (highlighted in gray):



This balancer is considered obsolete, therefore it is recommended for use only in certain cases. For example, for applications that were built on an EC2 ‑ Classic network. In principle, no one bothers us to create it:



2. Network Load Balancer. Suitable for high loads, works at OSI level 4 (can be used in EKS and ECS), TCP, UDP and TLS are supported.

The Network Load Balancer directs traffic to targets in Amazon VPC and is capable of processing millions of requests per second at ultra-low latency. In addition, it is optimized to handle traffic patterns with sudden and changing workloads.

3. Application Load Balancer . It works at the 7th level, has Lambda support, supports rules at the header and path level, supports HTTP and HTTPS.
Provides advanced query routing, focused on the delivery of applications built on the basis of modern architectures, including microservices and containers. Direct traffic to targets in Amazon VPC based on the content of the request.

For many users, the Application Load Balancer first replaced the Classic Load Balancer, because TCP is not so common, unlike HTTP.

Let's create it too, as a result of which we will already have two load balancers:



Load Balance Components


Common components of Load Balance (common to all balancers):

  • Access Logging Policy
- your ELB access logs. To make settings, you can go to Description and select the "Edit attributes" button:



Then we specify S3Bucket - Amazon object storage:



  • Scheme
- internal or external balancer. The point is whether your LoadBalancer needs to get external addresses in order to be accessible from the outside, or it can be your internal balancer;

  • Security groups
- access control to the balancer. This is essentially a high-level firewall.





  • Subnets
- subnets inside your VPC (respectively, and availability zone). Subnets is specified at creation. If VPCs are limited by region, then Subnets is limited by availability zones. When you create a Load Balancer, it is better to create it in at least two subnets (it helps if there are problems with one availability zone);

  • Listeners
- your balancer protocols. As mentioned earlier, for Classic Load Balancer it can be HTTP, HTTPS, TCP and SSL, for Network Load Balancer - TCP, UDP and TLS, for Application Load Balancer - HTTP and HTTPS.

Example for Classic Load Balancer:



But in the Application Load Balancer we see a slightly different interface, and generally different logic:



Components of Load Balancer v2 (ALB and NLB)


Now let's take a closer look at the balancers of the 2nd version of Application Load Balancer and Network Load Balancer. These balancers have their own component features. For example, a concept such as Target Groups - instances (and functions) has appeared. Thanks to this component, we have the opportunity to indicate which Target Groups we want to direct traffic to.





In simple terms, in Target Groups we specify the instances where the traffic will come. If in the same Classic Load Balancer you just immediately connect the intensities to the balancer, then in Application Load Balancer you first:

  • Create a Load Balancer
  • create a target group;
  • send the necessary Balancer ports or rules to the desired Target Groups;
  • in Target groups, assign instances.

This logic of work may seem more complicated, but in fact it is more convenient.

The next component is Listener rules . This applies only to the Application Load Balancer. If in Network Load Balancer you simply create a Listener, and it sends traffic to a specific Target group, then in Application Load Balancer it is more fun and convenient .



Now let's say a few words about the next component - Elastic IP (static addresses for NLB). If the Listener rules for routing applied only to the Application Load Balancer, then Elastic IP applies only to the Network Load Balancer.

Let's create a Network Load Balancer:





And just in the process of creation, we will see that we are given the opportunity to choose Elastic IP:



Elastic IP provides a single IP address that can be associated with different EC2 instances over time. If an EC2 instance has an Elastic IP address and this instance is completed or stopped, you can immediately associate a new EC2 instance with an Elastic IP address. However, your current application will not stop working, because applications see the same IP address, even if the real EC2 has changed.

Here is another user case on why Elastic IP is needed. Look, we see 3 IP addresses, but they will not stay here forever:



Amazon changes them over time, can do it every 60 seconds (but in practice, of course, less often). So, IP addresses can change. And in the case of Network Load Balancer, you can just bind an IP and specify it in your rules, policies, etc.



Draw conclusions


ELB automatically distributes incoming traffic across multiple targets (containers, Amazon EC2 instances, IP addresses, and Lambda features). ELB is able to distribute traffic with a changing load both in one availability zone and between several availability zones. The user can choose from three types of balancers, which provide high availability, auto-scaling, and good protection. All of this is important to ensure the resiliency of your applications.

The main advantages:

  • . 99,99 % . , , . , , ;
  • . ELB Amazon VPC, — , , SSL/TLS. TLS;
  • . ELB . Auto Scaling , , ;
  • . IP‑ . , . , , , , ;
  • monitoring and audit . You can monitor applications in real time using Amazon CloudWatch features. We are talking about metrics, logs, query tracking. In simple terms, you can identify problems and fairly accurately identify performance bottlenecks;
  • hybrid load balancing . The ability to balance workloads between on-premises resources and AWS using the same balancer makes it easy to migrate or expand on-premises applications to the cloud. Cloud failure is also simplified.

If you are interested in the details, here are a couple of useful links from the official Amazon website:

  1. Elastic Load Balancing .
  2. Features of Elastic Load Balancing.

More articles:


All Articles