Let's talk about Sticky Sessions,
also called Session Affinity
for your elastic load balancer.
So it's possible to implement what's called "stickiness"
or "sticky sessions"
And the idea is that the client,
doing two requests to the load balancer,
will have the same instance
in the backend to respond to the request.
So the idea is that for example,
you have an ALB with to EC2 Instances
and you have three clients,
if the client 1 makes a request
and it goes through the first EC2 Institute,
that means that when it does a second request
to the load balancer, it will go to the same instance,
which is a different behavior where usually,
the application balancer will do a spread
of all the requests across all the EC2 instances.
Now for Client 2,
if it goes to the ALB and talks to the second instance
then all the requests will go there
and same for Client 3, okay?
So this is the behavior that can be enabled
for the Classic Load Balancer
and the Application Load Balancer
and how it works; while there is a cookie
that is sent as part of the request from the clients
to the Load Balancer
and it has stickiness, and it has an expiration date,
that means that when the cookie expires,
then the clients may be redirected
to another EC2 Instance.
Use case for this, is to make sure
that the user is connected to the same backend instance
in order not to lose his session data.
Which can take some important information,
such as; the login of the user, for example.
But if you enable stickiness,
it may bring imbalance to the load
over the backend EC2 Instances
in case some instances have a very, very sticky user.
Okay, now to go a little bit deeper.
How about the cookie itself?
Well, there are two types of cookie that you can have
for Sticky Sessions.
The first one is Application-based Cookie
and the second one is Duration-based cookie.
So for application based cookies,
well, it's a custom cookie that is generated by the target,
So by your application itself,
and you can include any custom attributes that you want
required by the application.
The cookie name must be specified individually
for each target group, okay.
And you must not use the following names;
So, AWSALB, AWSALBAPP, AWSALBTG
because they are already reserved for use
by the ELB itself.
Or, it could be an application cookie
and this time will be generated by the load balancer itself.
And the cookie name used by the ALB will be AWSALBAPP, okay?
Now, the second type of cookies is Duration-based cookie
and it's the cookie generated by the load balancer.
And the name is AWSALB for the ALB and AWSELB for the CLB.
Okay, and the idea is this one will have an expiry
based on a specific duration
and the duration is generated by the load balancer itself.
Okay, whereas before,
while there is an application based cookie,
so the duration can be specified by the application itself.
So that's how it works, okay.
You don't need to remember exactly the name of the cookies
or the fact that you have custom and application,
but remember there's application-based cookies and
duration based cookies and they have a specific name
and this will be coming in to accounts
when we talk about CloudFronts.
Okay, so if I look at my load balancer right now
and I open it in a new tab, as you can see,
it goes between my three instances
in my Load balancer so that's perfect,
but now I'm going to enable Sticky Sessions.
So to do so, I'm going to, at the target group level,
open my target group, and then action
and I will can edit the attributes of my target group.
And in the bottom, I have a stickiness or sticky sessions.
And as we can see,
we have two types of stickiness available to us, okay.
We have the load balancer generated cookie,
which is a duration type of stickiness.
So I can say between one second and seven days,
or I can have an application-based cookie
between one second to seven days again,
but this time I need to specify the cookie name
that is sent by the app to the load balancer.
So it could be MYCUSTOMAPPCOOKIE.
And then this is what the load balancer would be using
to perform the stickiness, okay.
So that's it for a stickiness.
As we can see, if we just have
a load balancer generated cookie,
and we set the stickiness duration to be equal to say;
one day and I will save this change.
So now let's have a look,
so I'm going to go and open the debugger as well
so we can have a look at the network and see what happens.
So if you have a look at the network
and then I refresh this page, as we can see
I'll refresh multiple times okay,
you get access to the same instance.
So, 7-176 is the one that's coming back, back
and back and back.
And now, what's going to happen
is that when you look at the get requests
made to the load balancer.
I'm very, very sorry for the font size here.
I don't think I can really increase it,
but if you go to cookies, as you can see here,
there's a response cookie, okay.
That is saying; that your cookie expires tomorrow,
here is the path and here's the value of the cookie.
And then in the Request Cookie,
when the browser makes a request to the load balancer,
it sends again, the cookie, it has right here.
And so, because of the cookie being past Instance,
this is how stickiness works, okay.
So, just a bit of a deeper dive into how stickiness works,
but that's it for this lecture.
I hope you liked it.
And by the way, to access the web developer tools,
you click on web developer and then web developer tools,
and it just uses a short cut for that,
and it's the same on Chrome and Firefox.
And then you go to Network
and you get access to your information around your request.
Okay, and finally just go back to your target group
and then you edit the attributes itself
and you can disable a stickiness
to come back to a normal behavior,
which should be good to go.
So that's it for this lecture, I hope you liked it.
And I will see you in the next lecture.