Elastic Load Balancers fundamentals for the AWS Solutions Architect Associate Certification

Chapter 4: Load Balancers Fundamentals.

This chapter will review one of the most critical services that AWS EC2 provides, Elastic Load Balancing, and the scalability in the Amazon Web Services Cloud. We will study all the types of Elastic Load Balancers and their main features. Let’s go with it!

Elastic Load Balancers for the AWS Solutions Architect Associate Certification.

Remember that all the chapters from the course can be found in the following link.

These are the main points that we are going to discuss in this chapter:

1. Scalability
2. Elastic Load Balancers
3. Load Balancer Types
4. Health Checks
5. Stickiness
6. Cross-Zone Load Balancers
7. Typical Exam Questions

SCALABILITY

When we talk about Load Balancers, we must first define the concept of scalability. Scalability in cloud computing refers to increasing or decreasing IT resources as needed to meet changing demands. Imagine that our server is running out of CPU. We don’t have to worry about it; we just scale to increase it. We can scale in two different ways:

1. Vertical → You scale by adding more power (CPU, memory, storage…) to an existing machine.

• Scale-Up → You add more power, i.e., “t2.nano” instance to “t2.medium”.
• Scale-Down → You decrease the power, i.e., “t2.medium” instance to “t2.nano”.

2. Horizontal → You scale by adding more computers to the system. This is also called elasticity.

• Scale-Out → You add more instances, i.e., 1x “t2.nano” to 3x “t2.nano”.
• Scale-In → You reduce the number of instances, i.e., 3x “t2.nano” to 1x “t2.nano”.

Scale up vs. Scale down.

Thanks to scalability, we can achieve high availability, which protects against different types of failures to keep your business running without downtime.

To understand the concept of high availability, let’s imagine that we have a server running in an Availability Zone, and for whatever reason, it stops working. If we only had the application in this Availability Zone, we could not bring it up. In the case of high availability, we could have our application replicated in several Availability Zones. If there is a failure in one, the other will continue working.

Once we’ve understood these concepts, let’s talk about Load Balancers.

ELASTIC LOAD BALANCING

Load Balancers automatically distribute incoming application traffic across multiple targets, such as Amazon EC2 instances. It can handle the varying load of your application traffic in a single Availability Zone or across multiple Availability Zones. The one from AWS is called Elastic Load Balancer (ELB).

Load Balancer distributes incoming application traffic across multiple targets.

Some benefits of the Load Balancers:

• Highly available → Elastic Load Balancing automatically distributes incoming traffic across multiple targets in multiple Availability Zones and ensures only healthy targets receive traffic.
• Secure → It provides robust security features, including integrated certificate management, user authentication, and SSL/TLS decryption.
• Elastic → Capable of handling rapid changes in network traffic patterns and meeting varying levels of application load without requiring manual intervention.
• Flexible → Elastic Load Balancing also allows you to use IP addresses to route requests to application targets.
• Robust monitoring & auditing → It allows you to monitor your applications and their performance in real-time with Amazon CloudWatch metrics, logging, and request tracing.
• Hybrid load balancing → Elastic Load Balancing offers the ability to load balance across AWS and on-premises resources using the same load balancer.

Load Balancer distributing traffic across multiple Availability Zones.

Remember in the previous section when I said that it was essential to know that a Security Group can allow traffic from another Security Group? A typical approach is to put your instances behind an Elastic Load Balancer and block the traffic unless you access it from the Load Balancer. Let’s see it with a diagram:

How Security Groups block traffic if you don’t access through the ELB.

In this example, we have configured the Security Group of the above instance only to accept traffic coming from the Load Balancer’s security group. Therefore, if the user accesses through the Load Balancer, he will access the instance. On the other hand, the Security Group will block the traffic if the user tries to access the instance directly. Let’s look at how you would configure the Security Groups:

• Load Balancer Security Group (SG1) → We are going to accept inbound traffic from anywhere, both from HTTP (80) and HTTPS (443):

Load Balancer typical Security Group.

• Instances Security Groups (SG2 & SG3) → We will only accept traffic from SG1.

EC2 typical Security Group.

LOAD BALANCER TYPES

1. Classic Load Balancer (DEPRECATED) → Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances and supports TCP (layer 4) & HTTP/HTTPS (layer 7). Classic Load Balancer is intended for applications built within the EC2-Classic network, but it’s not really used nowadays.

2. Application Load Balancer → Supports HTTP/HTTPS/WebSockets and protocols from layer 7. We can use Health Checks for this layer. The main difference with the Classic Load Balancer is that in the previous case, we needed several Classic Load Balancers if we had several applications, while with the Application Load Balancer, we would only need one as it supports routing to several target groups. You can redirect depending on the following:

• The URL.
• Depending on the hostname.
• Depending on the queryString & Headers.

Just as an example of the URL redirect, if our application had the routes /posts and /users, we could redirect the users to different instances depending on the value of the request.

Instances are grouped inside target groups. A target group tells a load balancer where to direct traffic to. When creating a load balancer, you create one or more listeners and configure listener rules to direct the traffic to one target group. Target groups can contain:

• EC2 instances
• Lambdas
• Private IP Addresses
• ECS tasks

For example, I could configure rules in the Load Balancer so that all the requests to the route /users go to the first Target Group, and all the requests to the route /categories go to the second target group. We will see it later, but just for you to know, health checks are done at the target group level.

Target Groups in Application Load Balancers.

3. Network Load Balancer → It supports TCP and UDP protocols from layer 4, so we would have health checks for this layer. It has only one static IP per AZ and can support Elastic IP (useful for whitelisting specific IPs). It does not have a free tier. Use it when you want to have a static IP or when you want to have Extreme performance. This Load Balancer will be transparent to EC2 instances, so the instances will have to accept traffic from everywhere.

4. Gateway Load Balancer (NEW) → It operates at layer 3 (Network Layer for IP packets) , and it distributes the traffic to your third-party virtual appliances by deploying, scaling, and managing them. You can, for example, analyze your network traffic with firewalls, intrusion detection and prevention systems before it reaches your application. For your EC2 instances, this Load Balancer will be transparent (same as the Network Load Balancer). EC2 instances and private IP addresses are the possible Target Groups.

HEALTH CHECKS

Configuring health checks for the AWS Elastic Load Balancer (ELB) is critical to ensure that your cloud applications run smoothly.

They enable the load balancer to know if the instances are available to reply to requests. With active health checks, the load balancer periodically sends a request (to a route like /health or port) to each registered target to check its status, expecting a 200 request. Otherwise, the instance is unhealthy.

Health checks are done at the target group level.

STICKINESS

Allowing Stickiness in Load Balancers will redirect the client to the same instance. It routes requests from the same client to the same target.

How Stickiness works.

An example of its utility could be redirecting the user to the same instance to avoid losing his session data. The problem is that it might unbalance the load of EC2 instances. We can activate it in the target groups:

Configure Stickiness duration in AWS.

CROSS-ZONE LOAD BALANCERS

With this option, each Load Balancer will distribute the load among all the instances of all the Availability Zones that we have.

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.

As shown in the following picture, the ELB from the left is also distributing content to EC2 instances of Availability Zone B. If cross-zone load balancing is enabled, each of the ten targets receives 10% of the traffic. Each load balancer node can route 50% of the client traffic to all ten targets.

Cross-Zone Load Balancer.

SSL/TLS CERTIFICATE & SERVER NAME INDICATION

SSL certificates enable websites to move from HTTP to HTTPS, which secures connections from a web server to a browser. You can get your certificate with the AWS Certificate Manager service and attach it directly to the Load Balancer to allow HTTPS connections.

You might have a problem with several apps running behind the Load Balancer, and you want a specific SSL certificate for each application. We can use “Server Name Indication” to solve this problem, which allows you to load multiple certificates on a web server.

TYPICAL EXAM QUESTIONS

We are designing an application that includes an Auto Scaling group of Amazon EC2 Instances running behind an Elastic Load Balancer. All the web servers must be accessible only through the Elastic Load Balancer, and none of them directly from the Internet. How should the Architect meet these requirements?

1. With a CloudFront distribution in front of the Elastic Load Balancer.
2. Denying traffic from the Internet in the web server’s security group.
3. Configure the web tier security group to allow only traffic from the Elastic Load Balancer.
4. Install a Load Balancer on an Amazon EC2 instance.

Solution: 3. To ensure that your web servers are only accessible through the Elastic Load Balancer (ELB), you would configure the security group for your web servers to only allow inbound traffic from the Elastic Load Balancer. In a Security Group, you cannot create deny rules. Besides, denying all internet traffic would also block legitimate traffic from your ELB.

Two web services on the same set of instances require each to listen for traffic on different ports. Which AWS service should we use to route traffic to the service based on the incoming request path?

1. Amazon Route 53.
2. Amazon CloudFront.
3. Application Load Balancer (ALB).
4. Classic Load Balancer (CLB).

Solution: 3. The Application Load Balancer operates at the request level (Layer 7), making it suitable for routing traffic based on application content, such as HTTP headers and the URL in the request, and distributing traffic across multiple targets or instances.

The Classic Load Balancer operates at both the request level (Layer 7) and connection level (Layer 4), but it does not support path-based routing like the Application Load Balancer.

A web application runs on several Amazon EC2 instances behind an Application Load Balancer (ALB). Which protocols can we use to do the health check? (Select TWO)

1. SSL.
2. TCP.
3. ICMP.
4. HTTP.
5. HTTPS.

Solution: 4, 5. The Application Load Balancer operates at the request level (Layer 7) and supports health checks using HTTP and HTTPS protocols. These health checks ensure that the instances are responding appropriately and are healthy enough to receive traffic. If an instance fails a health check, the ALB will stop sending traffic to that instance until it passes the health check again.

Application Load Balancer vs. Network Load Balancer.

We are designing a web application that runs on Amazon EC2 instances behind an Elastic Load Balancer. One requirement is that we must encrypt all the data in transit. How could we do that? (Select TWO)

1. Use a Network Load Balancer (NLB) with a TCP listener, then terminate SSL on EC2 instances.
2. Use sticky sessions with the Application Load Balancer (ALB).
3. Use an Application Load Balancer (ALB) with an HTTPS listener, then install SSL certificates on the ALB and EC2 instances.
4. Use a Network Load Balancer (NLB) with an HTTPS listener, then install SSL certificates on the NLB and EC2 instances.
5. Use an Application Load Balancer (ALB) with a TCP listener, then terminate SSL on EC2 instances.

Solution: 1, 3. You cannot use HTTPS in Network Load Balancer (NLB), as it works in layer 4. However, you can use an NLB with a TCP listener and terminate SSL on the EC2 instances. This means the NLB would pass through the SSL encrypted traffic to the EC2 instances where the SSL termination would happen.

Another, and more accessible option, is to use an Application Load Balancers (ALB), which supports SSL termination at the Load Balancer level. You would need to install SSL certificates on the ALB, and then it would handle the encryption and decryption of data, offloading that work from your EC2 instances.

More Questions?

• Do you want more than 500 AWS practice questions?
• Access to a real exam simulator to thoroughly prepare for the exam.
• You can download all of the AWS questions on PDF.

All of this and more at FullCertified!

FullCertified | Snowflake, AWS, and Azure Practice Exams

Thanks for Reading!

If you like my work and want to support me…

1. The BEST way is to follow me on Medium here.
2. Feel free to clap if this post is helpful for you! :)