AWS Elastic Load Balancer (ELB) -- Sticky Session & ASG

1. Sticky Sessions (Session Affinity)

Enable Sticky Sessions

At the target group level. edit the attributes:

---

---

Refresh this page multiple times, as we can see, we get access to the same instance.

---

And we can see the cookie information as below:

---

The cookies is past to the instance, this is how stickness works.

2. Auto Scaling Group (ASG)

2.1 Create an ASG

Before creating an ASG, we need to terminate all the instances.
Then, we create a launch template.

---

---

---

---

Paste the script into User data

#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

---

Now back to the management console and select the template:

---

Use the VPC and launch it in 3 different AZs

---

Enable the "ELB" option here.

The idea here is that if the instance fails the health check of the ELB, then it will be marked as unhealthy as well in the auto scaling group.
And it will be terminated by the auto scaling group, then a new instance will be launched back.
This is to ensure that all the instances are healthy.

---

Leave these options as default, we will change them later on.

---

The auto scaling group is created and what it's going to do is that it's going to create 1 EC2 instance for us.

---

In the Active history there is a launching a new instance right here because the Auto Scaling Group has a capacity of 0 and we wanted 1 capacity.

So it's just increased the number of EC2 instances in our ASG to match the desired capacity.

---

In the tab of instance management we can see 1 EC2 instance was created by the ASG.

---

The EC2 instance is currently running and initializing

---

The EC2 instance is being registered into the target group which is linked to the ALB.

---

Then if we go to ALB and refresh, we will get the "hello world" response. That means everything is functioning.

---

2.2 Scaling Out

We can experience a scaling by editing the auto scaling group size:

---

Now it's launching a new EC2 instance, because we have changed the desired capacity from 1 to 2.

---

And after a while, it is going to be registered into our target group and add it.

---

2.3 Scaling Policies

We have 3 categories:

• Dynamic scaling policies
• Predictive scaling policies
• Scheduled actions

2.3.1 Create a Dynamic Scaling Policy

---

---

Now go to Details tab, edit the Group size and set the Maximum capacity as 3

---

Have a look at Monitoring tab, CPU Utilization of the EC2 instance is close to 0 because it's not doing anything.

---

So we are going to stress the instance to make the CPU utilization skyrocket to 100%.

Click the instance:

---

Then click Connect

---

Install the Stress

sudo amazon-linux-extras install epel -y

sudo yum install stress -y

---

---

Run this command to make the CPU go to 100%

stress -c 4

---

After a short while, we can see that CPU utilization is at a very high value and an alarm has been triggered:

---

---

Due to the target driving policy, then the capacity went from 1 instance to 2 instances, then to 3 instances.

---

---

---

If we go into the CloudWatch service, as we can see, 2 alarms are created directly by the target tracking policy.

---

If we can't stop the stress command, we can reboot the instances. This should make the CPU utilization go back to 0, and this would trigger a scale in action.

---

---