AWS-Elastic Load Balancer Tutorial

Elastic Load Balancing automatically distributes your incoming application traffic across multiple targets, such as EC2 instances. It monitors the health of registered targets and routes traffic only to the healthy targets. Elastic Load Balancing supports three types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers.

Table of Contents 

  • Benefits of Load Balancer
  • Introduction to different types of Load Balancers
  • Classic Load Balancing.
  • Application Load Balancer (ALB)
  • Attaching a Load Balancer to Your Auto Scaling Group

  • Use Path-Based Routing with Your Application Load Balancer

  • Deploying applications with AWS ECS Cluster and ALB
  • Monitoring : CloudWatch Metrics Monitoring for Application Load Balancer

  • Log Monitoring : Create Access Logs for Application Load Balancer
  • Security : Encrypting data in transit with SSL/TLS

Print

Benefits of Load Balancer

A load balancer distributes workloads across multiple compute resources, such as virtual servers. Using a load balancer increases the availability and fault tolerance of your applications.

You can add and remove compute resources from your load balancer as your needs change, without disrupting the overall flow of requests to your applications.

You can configure health checks, which are used to monitor the health of the compute resources so that the load balancer can send requests only to the healthy ones.

There are multiple load balancing services available, with three types provided by AWS: classic, application, and network.

Classic Load Balancer

This is really only an option for those with applications in Amazon’s earlier version of their current VPC—the EC2-Classic network. This connection-based network essentially just forwards on requests as they come into the backend, allowing for virtually zero control and scale. Although some applications are still in need of CLB and some entities choose to continue to use it, CLB will most likely continue to be phased out over time, especially as most new AWS updates/features will be focused on ALB and NLB.

Application Load Balancer

ALB allows for incoming requests to be distributed to the backend depending on their corresponding header; that is, all traffic is routed based on the original sender’s IP address. Working on the seventh layer of the OSI model and using a round-robin algorithm, requests are not simply sent along to one backend instance but intervened and sorted into various instances per their individual headers. Multiple connections can also be opened in order to handle increased requests as needed. Traffic routing for specific situations and IP addresses, such as hybrid cloud, disaster recovery, and on-premise data centers, can easily be handled as well since the HTTP header for each incoming request can be changed.

Network Load Balancer

This is the newest kid on the block and was introduced by AWS to handle high loads—to the tune of tens of millions of requests per second—with high throughput and low latency. NLB utilizes a flow-hash algorithm on the fourth layer of the OSI model and can route incoming requests to any target group. Due to its ability to handle static IP addresses, NLB also enables you to connect a single Elastic IP address through a chosen subnet.

Although most new implementations of load balancing do not include Classic Load Balancers, there are still reasons some need it. These include, per Amazon’s own CLB page, support for EC2-Classic, TCP and SSL listeners, and sticky sessions using application-generated cookies. But the real interest is in the possible use cases for ALB and NLB.

Application Load Balancers are used for HTTP and HTTPS traffic and enable advanced routing, SSL/TLS termination, and visibility for microservices, containers, and other application architectures. ALB serves distributed architectures best, wherein HTTP header details need to be read; for this reason, ALB allows for great flexibility but is not suitable for encrypted requests.

Network Load Balancers handle only TCP packets and cannot access the details of an HTTP request in the same way as ALB. However, if end-to-end encryption is required, then NLB is the best option as it simply sends traffic—TCP packets—directly to the web server reducing latency and ensuring security from the client to the server. NLB is useful for applications that require fixed IP addresses and high-performance routing.

Both ALB and NLB can handle traffic to dynamic ports as well. The chart below shows a comparison of features for each ELB from AWS itself:

chart

You can select the appropriate load balancer based on your application needs. If you need flexible application management, then we recommend you to use Application Load Balancer. If extreme performance and static IP is needed for your application, then we recommend you to use Network Load Balancer. If you have an existing application that was built within the EC2-Classic network, then you should use Classic Load Balancer.

Classic Load Balancing.

This more closely resembles traditional load balancing, but virtual devices replace physical hardware to evenly distribute your incoming requests and ensure clean, fast user experience.

The Classic ELB has a number of features available to help provide high availability, monitoring, and better security for your application stack.

The AWS Classic Load Balancer (CLB) operates at Layer 4 of the OSI model. What this means is that the load balancer routes traffic between clients and backend servers based on IP address and TCP port.

For example, an ELB at a given IP address receives a request from a client on TCP port 80 (HTTP). It will then route that request based on the rules previously configured when setting up the load balancer to a specified port on one of a pool of backend servers. In this example, the port on which the load balancer routes to the target server will often be port 80 (HTTP) or 443 (HTTPS).

The backend destination server will then fulfill the client request, and send the requested data back to the ELB, which will then forward the backend server reply to the client. From the client’s perspective, this request will appear to have been entirely fulfilled by the ELB. The client will have no knowledge of the backend server or servers fulfilling client requests.

classic1

Next, choose a name for your load balancer. Here I’ve used the name classicbalancer1. By default your load balancer will have a rule to forward incoming traffic on port 80 to port 80 on your EC2 instances.

classic2

Just like your EC2 instances, your load balancers belong to security groups which dictate which ports they are allowed to receive data on. For our load balancer to work, it has to be in a security group that allows connections on port 80. You can choose a security group you already have. Alternatively, select Create a new security group and AWS will automatically create a group with the rules you need.

classic3

You won’t see anything on next page unless you’re setting up your load balancer to accept traffic on port 443 (HTTPS). If you are setting up HTTPS on your load balancer, this is the page where you set up your SSL certificate. You need to set up an SSL certificate in order to use HTTPS.

classic4

The load balancer will ping your webserver every 30 seconds to check to see if it’s responding. This is called the health check. When the load balancer is managing traffic for multiple instances, if one of the instances fails for some reason, it will reroute traffic to the other instances.

We’ll make the load balancer ping /index.html to see if our server is alive. Make sure that the route you put in here will send a 200 OK response when a GET request is made to it. Otherwise the load balancer will think your webserver is broken and won’t forward any traffic to it.

Response Time — Amount of time the LB is gonna wait for response from health check(2 sec-60 sec).

Interval — Time between two consecutive Health Checks(5 sec — 300 sec)

Unhealthy Threshold — Number of Consecutive health check failures before declaring an Ec2 Instance as being Unhealthy.

Healthy Threshold — Number of Consecutive successful health check before declaring an Ec2 Instance as being healthy.

classic5

Next you get to decide what EC2 instances will be in the load balancer. If you choose multiple instances, the load balancer will attempt to split traffic equally between them. But you can just add one instance and the load balancer will do its job just forwarding traffic to that one instance.

classic6

You can now pass through the Add Tags stage, and move on to the Review stage.

classic7

After you launch your load balancer, you can see it on the Load Balancers tab of the EC2 console. Under the description tab you can see a DNS name for your load balancer. Navigate to that URL in your browser to see your website.

classic8

Navigate to the DNS name you received.

http://classicbalancer1-1090789222.us-east-1.elb.amazonaws.com/

classic9

If you get an error going to that URL, a common problem is the load balancer thinks your server isn’t working. If your instance is listed as OutOfService in the Instances tab, that means your instance isn’t responding to the load balancer’s health check.

classic10

If you need to enable website from loadbalancer DNS add the HTTP port listening from load balancer security group.Edit the ec2 security group as below where sg-07eb357c4482b3696 is load balancer security group.

classic12

We can test the loadbalancer from webserver using below command

# curl -v classicbalancer1-1090789222.us-east-1.elb.amazonaws.com

or

# curl -I classicbalancer1-1090789222.us-east-1.elb.amazonaws.com

classic13

Application Load Balancer (ALB) 

Application Load Balancer is very similar to CLB, the main difference is that it does path based routing. For routing to different paths, create a target group for each application and create a different rule for each target group.

ALB Features:-

  1. Content-Based Routing
  2. Host-based Routing
  3. Path-based Routing
  4. Containerized Application Support with EC2 Container Service
  5. HTTP/2 Support, HTTPS Support
  6. WebSockets Support
  7. Native IPv6 Support
  8. Sticky Sessions
  9. High Availability

AWS Application Load Balancer (ALB) operates at Layer 7 of the OSI model. At Layer 7, the ELB has the ability to inspect application-level content, not just IP and port. This lets it route based on more complex rules than with the Classic Load Balancer.

In another example, an ELB at a given IP will receive a request from the client on port 80 (HTTP) / 443 (HTTPS). The Application Load Balancer will process the request, not only by receiving port, but also by looking at the destination URL.

The Application Load Balancer will be aware of each of these URLs based on patterns set up when configuring the load balancer, and can route to different clusters of servers depending on application need. Rules can also be added at a later time as you add new functionality to your stack.

The Application Load Balancer also integrates with EC2 Container Service (ECS) using Service Load Balancing. This allows for dynamic mapping of services to ports as specified in the ECS task definition. Multiple containers can be targeted on the same EC2 instance, each running different services on different ports. The ECS task scheduler will automatically add these tasks to the ALB.

Key ALB Concepts

There are some key concepts that you will need to know when configuring your ALB. The first is rules. Each rule specifies a conditiontarget group, and a priority.

  • Rules determine what action is taken when a rule matches a client request. Up to 10 URL-based rules can be defined in the ALB.
    • The condition is the path pattern you want the ALB to evaluate in order for it to route requests.
  • The target group is used to route requests to registered targets as part of an action for a rule. Target groups specify a protocol and target port. Health checks can be configured per target group. An ALB can route to multiple target groups.
    • Targets specify the endpoints and are registered with the ALB as part of a target group.
  • Priority tells the ALB in which order to evaluate the rules. Rules are numerically evaluated in order from lowest to highest value. When a rule matches a request, traffic will be routed to the specified target group.

Create an AWS Application Load Balancer by going to EC2 management console.

alb1

Select a name for loadbalancer. Here appload1

alb2alb3

Select the security group and security settings

You can create single certificate with multiple site domains from the AWS console. But if you use AWS CLI or API you can create and attach multiple certificates to HTTPS listener of the ALB . Please note: there is no option to attach multiple certificates to an ALB listener in AWS console.

alb4

Create a target group that will be attached to the ALB and route traffic from ALB to your container instances. You need to define port & protocol that ALB uses to route traffic to your targets in your target group and perform health checks on your targets (Instances).

alb5alb6

Provide the target ec2 instances for the ALB. Click on Add to Registered to add the targets

alb7

Review and launch the load balancer

alb8

Now we can access the load balancer using the DNS name here : appload1-1300085624.us-east-1.elb.amazonaws.com

alb9

Listener details can be found on listener tab

alb10

We can find the health of target webserver’s in Target Groups

alb11

Stickiness can be enabled by editing Attribute option in Target Group

alb12

Edit the security group of the target instances so that it has HTTP/HTTPS connection only to load balancer security group.

alb13

Attaching a Load Balancer to Your Auto Scaling Group

Amazon EC2 Auto Scaling integrates with Elastic Load Balancing to enable you to attach one or more load balancers to an existing Auto Scaling group. After you attach the load balancer, it automatically registers the instances in the group and distributes incoming traffic across the instances. To use an Elastic Load Balancing health check with your instances to ensure that traffic is routed only to the healthy instances.

You can use Auto Scaling to manage Amazon EC2 capacity automatically, maintain the right number of instances for your application, operate a healthy group of instances, and scale it according to your needs.

alb14

Create a launch configuration

Choose an AMI, then choose an instance type on the next page, and then choose Next: Configure Instance Details.

alb15

In Number of instances, type the number of instances that you want to launch, and then choose Launch into Auto Scaling Group. You do not need to add any other configuration details on the page.

Provide the launch configuration name, IAM Role (if any) , monitoring details IP Address type and the userdata information.

alb16alb17

Provide the security group details and make sure the HTTP request is only received from loadbalancer

alb18

Review the details of the launch configuration, and then choose Create launch configuration to choose a key pair and create the launch configuration.

On the Configure Auto Scaling group details page, the launch configuration you created is already selected for you, and the number of instances you specified in the Amazon EC2 launch wizard is populated for Group size. Enter a name for the group, specify a VPC and subnet (if required).

alb19

On the Configure scaling policies page, choose one of the following options, and then choose Review:

  • To manually adjust the size of the Auto Scaling group as needed, select Keep this group at its initial size. For more information, see Manual Scaling.
  • To automatically adjust the size of the Auto Scaling group based on criteria that you specify, select Use scaling policies to adjust the capacity of this group and follow the directions. For more information, see Configure Scaling Policies.

alb20

On the Review page, you can optionally add tags or notifications, and edit other configuration details. When you have finished, choose Create Auto Scaling group.

alb21

Once created we can review the launch Activity history

alb22.JPG

alb23

When you attach a load balancer, it enters the Adding state while registering the instances in the group. After all instances in the group are registered with the load balancer, it enters the Addedstate. After at least one registered instance passes the health checks, it enters the InServicestate. After the load balancer enters the InService state, Amazon EC2 Auto Scaling can terminate and replace any instances that are reported as unhealthy.

Register the already created EC2 Instances to Target Group of ALB

alb24

With Application Load Balancers and Network Load Balancers, instances are registered as targets with a target group. When you plan to use your load balancer with an Auto Scaling group, you don’t need to register your EC2 instances with the load balancer or target group. After you attach a load balancer or target group to your Auto Scaling group, the group registers your instances with the load balancer or target group when it launches them.

Verify the webpage using DNS

alb25alb26

Use the following procedure to attach a load balancer to an existing Auto Scaling group.

On the navigation pane, under Auto Scaling, choose Auto Scaling Groups.

Select your group.On the Details tab, choose Edit.

Under Target Group choose the desired target group and change the health-check  type to ELB. Once done click save.

alb27

alb28

If the webservice is being stopped . The target instance in ALB becomes unhealthy state and it triggers the autoscaling to launch new instance and auto registers it in ALB target group.

Suspend and Resume Processes in Auto Scaling 

You can suspend and resume individual processes using the AWS Management Console.

To suspend and resume processes using the console

  1. Open the Amazon EC2 console
  2. On the navigation pane, under Auto Scaling, choose Auto Scaling Groups.
  3. Select the Auto Scaling group.
  4. On the Details tab, choose Edit.
  5. For Suspended Processes, select the process to suspend.

suspend.jpeg

To resume a suspended process, remove it from Suspended Processes.

suspend2.jpeg

Use Path-Based Routing with Your Application Load Balancer

You can create a listener with rules to forward requests based on the URL path. This is known as path-based routing. If you are running microservices, you can route traffic to multiple back-end services using path-based routing.

alb15

Here we have two webservers with sites running on different paths

eg: webserver1/hello/index.html

webserver2/welcome/index.html

On the navigation pane, under LOAD BALANCING, choose Target Groups.

Create a target group for the first set of targets as follows:

alb1

Specify a name, protocol, port, and VPC for the target group, and then choose Create.

On the health check settings tab give the path as /hello/

alb2.jpg

alb3.JPG

Once values are entered click create.

Create a target group for the second set of targets as follows:

On the health check settings tab give the path as /welcome/

alb4.JPG

Configuration of load balancer

On the navigation pane, under LOAD BALANCING, choose Load Balancers.

For Listeners, the default is a listener that accepts HTTP traffic on port 80. You can keep the default listener settings, modify the protocol or port of the listener, or chooseAdd to add another listener.

Select on the loadbalancer and click on listeners. Under HTTP section click on view/edit rules

alb5

click on add rule button to create the below rules

alb6.JPG

Insert rules as below for path  /hello/ and click on save.

alb7

Similarly configure the rule for /welcome/ path.

alb8

Complete the Configure Routing page as follows:

Navigate to Target groups and click on tg-hello target group.Register the target instance (webserver1) by clicking on Edit and Add to Registered on Targets Tab.

alb9.jpg

Similarly register the instance (webserver2) on target group tg-welcome

alb10

Test the loadbalancer by providing both paths (/hello & /welcome) along with DNS name

http://loadbalc-233887209.us-east-1.elb.amazonaws.com/welcome/

alb12.jpg

http://loadbalc-233887209.us-east-1.elb.amazonaws.com/hello/ 

alb14.jpg

Deploying applications with AWS ECS Cluster and ALB

Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster.Amazon ECS lets you launch and stop container-based applications with simple API calls, allows you to get the state of your cluster from a centralized service, and gives you access to many familiar Amazon EC2 features.

Please refer our detailed post on how to create an ECS Cluster, Attaching EC2 instances and monitoring and autoscaling with the help of ALB .Please refer the link below

https://dinfratechsource.com/2019/01/20/deploying-applications-with-aws-ecs-cluster-alb-and-auto-scaling-group/

Monitoring : CloudWatch Metrics Monitoring for Application Load Balancer

Elastic Load Balancing publishes data points to Amazon CloudWatch for your load balancers and your targets. CloudWatch enables you to retrieve statistics about those data points as an ordered set of time-series data, known as metrics.Elastic Load Balancing reports metrics to CloudWatch only when requests are flowing through the load balancer. If there are requests flowing through the load balancer, Elastic Load Balancing measures and sends its metrics in 60-second intervals.

You can view the CloudWatch metrics for your load balancers using the Amazon EC2 console. These metrics are displayed as monitoring graphs. The monitoring graphs show data points if the load balancer is active and receiving requests.

alb1.JPG

To view metrics filtered by load balancer, do the following:

Select your load balancer, and then choose the Monitoring tab.

alb2

To filter the results by time, select a time range from Showing data for.To get a larger view of a single metric, select its graph.

alb3.JPG

Create a CloudWatch Alarm Based on a CloudWatch Metric

Click on Create Alarm button on monitoring panel and select the metrics and threshold.

alb4

Log Monitoring : Create Access Logs for Application Load Balancer

Elastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client’s IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and troubleshoot issues.Access logging is an optional feature of Elastic Load Balancing that is disabled by default. After you enable access logging for your load balancer, Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket that you specify as compressed files.

Select the Edit attributes option in description section of Load balancer

alb5.jpg

Bucket Permissions

When you enable access logging, you must specify an S3 bucket for the access logs. The bucket must meet the following requirements.

Requirements

  • The bucket must be located in the same region as the load balancer.
  • The bucket must have a bucket policy that grants Elastic Load Balancing permission to write the access logs to your bucket. Bucket policies are a collection of JSON statements written in the access policy language to define access permissions for your bucket. Each statement includes information about a single permission and contains a series of elements.

The policy document should be similar to the following:

{
  "Id": "Policy1429136655940",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1429136633762",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-loadbalancer-logs/my-app/AWSLogs/123456789012/*",
      "Principal": {
        "AWS": [
          "797873946194"
        ]
      }
    }
  ]
}

On the Edit load balancer attributes page, do the following:

  1. Choose Enable access logs.
  2. For S3 location, type the name of your S3 bucket, including any prefix (for example, my-loadbalancer-logs/my-app). You can specify the name of an existing bucket or a name for a new bucket. If you specify an existing bucket, be sure that you own this bucket and that you configured the required bucket policy.
  3. (Optional) If the bucket does not exist, choose Create this location for me. You must specify a name that is unique across all existing bucket names in Amazon S3 and follows the DNS naming conventions. For more information, see Rules for Bucket Naming in the Amazon Simple Storage Service Developer Guide.
  4. Choose Save.

alb7

The access log files are compressed. If you open the files using the Amazon S3 console, they are uncompressed and the information is displayed. If you download the files, you must uncompress them to view the information.

alb11

Downloading the logs in EC2 Instance

alb10.JPG

Security : Encrypting data in transit with SSL/TLS

You can create a listener that uses encrypted connections (also known as SSL offload). This feature enables traffic encryption between your load balancer and the clients that initiate SSL or TLS sessions.

SSLALB.JPG

To use an HTTPS listener, you must deploy at least one SSL/TLS server certificate on your load balancer. The load balancer uses this certificate to terminate the connection and then decrypt requests from clients before sending them to the targets.

pic1.jpg

Open HTTPS rule and open port 443 for ALB Security Group

pic3

pic4

pic5

pic6

pic7

Create or Import an SSL/TLS Certificate Using AWS Certificate Manager

We recommend that you use AWS Certificate Manager (ACM) to create or import certificates for your load balancer. ACM integrates with Elastic Load Balancing so that you can deploy the certificate on your load balancer. To deploy a certificate on your load balancer, the certificate must be in the same region as the load balancer.

pic8

pic9

On the Request a certificate page, type your domain name. You can use a fully qualified domain name (FQDN) such as www.example.com or a bare or apex domain name such as example.com. You can also use an asterisk (*) as a wildcard in the leftmost position to protect several site names in the same domain.

pic10

pic11

Confirm the request via email

pic12

Unless you choose to opt out, your certificate will be automatically recorded in at least two public certificate transparency databases. You cannot currently use the console to opt out. You must use the AWS CLI or the API.

pic13

Add the HTTPS in listeners tab.

pic14

pic15

pic16

pic17

Open the Website using DNS name

pic18.jpg

Error is because certificate is issued for specific domain and different from  ALB domain. So we need to create a subdomain and link with ALB.

Navigate to Route53

pic19

If you’re already using Route 53, choose Hosted Zones in the navigation pane.

pic20

Click on the domain name.

pic21

You can create records using either the Amazon Route 53 console or the Route 53 API.

pic22

On the alias target sections select the ALB DNS name.

pic23

Then click on Create Button.

pic24

Open the website using the subdomain name

pic25

pic26

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: