Hi all! Course starts today , in connection with which we held a 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.
, 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 even know this:
- useful if you plan to take AWS certification exams;
- this is an easy way to distribute the load between servers;
- it's an easy way to add Lambda to your service (ALB).
Conducted an open lesson , system engineer in a marketing company for the development and support of sites.
Introduction
What is an Elastic Load Balancer can be seen in the diagram below, where the simplest example is presented:
Load Balancer accepts requests and distributes them among instances. We have one separate instance, we have Lambda functions, and we have an AutoScaling group (group of servers).
AWS ELB Types
1. Consider the main types:
Classic Load Balancers. The very first load balancer from AWS, works both at the 4th and at the 7th OSI layer, HTTP, HTTPS, TCP and SSL are supported. It provides basic load balancing across multiple Amazon EC2 instances and works at both the request and connection levels. 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 the EC2βClassic network. In principle, no one bothers us to create it:
2. Network Load Balancer. Suitable for high load, works at OSI layer 4 (can be used in EKS and ECS), TCP, UDP and TLS are supported.
Network Load Balancer directs traffic to targets in Amazon VPC and is capable of handling millions of requests per second at ultra-low latency. In addition, it is optimized to handle sudden and fluctuating traffic patterns.
3. Application Load Balancer. Works at layer 7, has Lambda support, supports header and path level rules, HTTP and HTTPS are supported.
Provides advanced request routing focused on the delivery of applications built on modern architectures, including microservices and containers. Directs traffic to targets in the Amazon VPC based on the contents of the request.
For many users, the Application Load Balancer replaced the Classic Load Balancer in the first place, because TCP is not as common as HTTP.
Let's create it too, as a result of which we will already have two load balancers:
Load Balance Components
Common Load Balance Components (inherent 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 load balancer;
- security groups
β access control to the balancer. In fact, this is a high-level firewall.
- subnets
- subnets within your VPC (respectively, and availability zones). Subnets is specified at creation. While VPCs are limited by region, Subnets are limited by availability zones. When you create a Load Balancer, it's best to create it on at least two subnets (helps if one Availability Zone has issues);
- listeners
β your balancer protocols. As mentioned earlier, for Classic Load Balancer it can be HTTP, HTTPS, TCP and SSL, for Network Load Balancer it can be TCP, UDP and TLS, for Application Load Balancer it can be HTTP and HTTPS.
Example for Classic Load Balancer:
But in the Application Load Balancer we see a slightly different interface, and generally different logic:
Load Balancer v2 Components (ALB and NLB)
Now let's take a closer look at the balancers of the 2nd version of the Application Load Balancer and Network Load Balancer. These balancers have their own component features. For example, there was such a thing as Target Groups - instances (and functions). Thanks to this component, we have the opportunity to specify which of the Target Groups we want to send traffic to.
In simple terms, in Target Groups we specify the instances where traffic will come. If in the same Classic Load Balancer you just immediately connect the intenses to the balancer, then in the Application Load Balancer you first:
- create a Load Balancer;
- create a Target group;
- direct by the required ports or Load Balancer rules to the required Target Groups;
- assign instances in Target groups.
This logic of work may seem more complicated, but in fact it is more convenient.
The next component is Listener rules (rules for routing). This already applies only to the Application Load Balancer. If in the Network Load Balancer you simply create a Listener, and it sends traffic to a specific Target group, then in the Application Load Balancer everything .
Now let's say a few words about the next component - elastic IP (static addresses for NLB). If the rules for routing Listener rules concerned only Application Load Balancer, then Elastic IP concerns only 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 an 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 that instance is terminated or stopped, you can immediately associate a new EC2 instance with an Elastic IP address. However, your current application will not crash, as applications see the same IP address even if the real EC2 has changed.
Here on the topic of why Elastic IP is needed. Look, we see 3 IP addresses, but they won't stay here forever:
Amazon changes them over time, maybe every 60 seconds (but less often in practice, of course). This means that IP addresses can change. And in the case of Network Load Balancer, you can just bind an IP address and specify it in your rules, policies, etc.
Draw conclusions
ELB automatically distributes incoming traffic to multiple targets (containers, Amazon EC2 instances, IP addresses, and Lambda functions). ELB is capable of distributing fluctuating traffic within a single Availability Zone or across multiple Availability Zones. The user can choose from three types of balancers that provide high availability, autoscaling, and good protection. All of this is important to ensure the fault tolerance of your applications.
The main advantages:
- high availability. The service agreement assumes 99,99% availability for the load balancer. For example, multiple availability zones ensures that traffic is processed only by healthy entities. As a matter of fact, it is possible to balance the load throughout the region by redirecting traffic to healthy targets in different availability zones;
- safety. ELB works with Amazon VPC to provide a variety of security features, including integrated certificate management, user authentication, and SSL/TLS decryption. All together provides centralized and flexible management of TLS settings;
- elasticity. ELB can handle sudden changes in network traffic. And deep integration with Auto Scaling gives the application enough resources if the load changes, and manual intervention is not required;
- flexibility. You can use IP addresses to route requests to your application's targets. This provides the flexibility to virtualize targeted applications, thus allowing multiple applications to be hosted on the same instance. Since applications can use a single network port and have separate security groups, communication between applications is simplified when we have an architecture based on, say, microservices;
- monitoring and audit. You can monitor applications in real time using Amazon CloudWatch features. We are talking about metrics, logs, request tracking. In simple terms, you will be able to identify problems and pinpoint performance bottlenecks quite accurately;
- hybrid load balancing. The ability to load balance between on-premises resources and AWS using the same load balancer makes it easy to migrate or extend on-premises applications to the cloud. Failover using the cloud is also simplified.
If you are interested in the details, here are a couple of useful links from the official Amazon website:
- .
Source: habr.com