Okay, so now let's have a look
at automatic scaling for your ASG.
As you can see we have three categories,
dynamic scaling policies, predictive scaling policies,
and scheduled actions.
So let's start with the simplest.
So schedule actions
is when you want to schedule a scaling action in the future,
so you can create one
and then you say what you want the desired capacity
or the min or the max to be,
and then is it once every week, every hour,
is it's based on a specific schedule and so on?
And then a start time and an end time
if you wanted it to be done.
So this is pretty cool and this is allowing you to schedule
based on events that you can predict
and that you know in advance.
Because you know, for example
that you're going to run a big promotion next Saturday.
Next, predictive scaling policies
is where it's going to be machine learning driven.
So you need to scale it based on a forecast.
So you need to have a look at the actual policy
and the actual scaling based on the past
and then it will have a look at a metric to look at.
For example, CPU utilization or network in, network out,
the application load balancer request counts
or a custom metric that you want.
And then you want to, for example,
to have a target of 50% of CPU utilization for instance,
and then you can set up some additional settings,
but based on this,
and based on the actual scheduled utilization
for the past week, for example,
then a forecast is going to be created
and your ASG is going to be scaling based on that forecast.
So it's not something I can demonstrate with you
because I would need to enable this
for a very long time a week
and then make sure I have some usage on my application.
But at least you see that predictive scaling policy
is quite simple to set up,
you just specify the metric you want
and the target utilization,
and then some machine learning will be applied
for the scaling to happen.
So the one policy I can demonstrate to you
is the dynamic scaling policy.
So let's go ahead and create a dynamic scaling policy.
So here we have three options.
We have target tracking, step scaling and simple scaling.
So let's have a look at simple scaling first.
So here we have to specify a name than a CloudWatch alarm,
which is an alarm that can scale capacity
whenever it is being triggered.
So we need to create an alarm beforehand,
but we'll see this later on.
And so in case the alarm is being triggered
and what happens, maybe you want to add two capacity units,
or maybe you want to add 10% of your group.
And then add capacity units
in increments of at least two capacity units.
So this is a simple scaling policy.
So we can have a scaling policy that goes out
by adding instances,
or that goes in by removing instances here.
Or you can have a set to action as well.
And next we have step scaling.
So this is allowing you to set up multiple an alarm
and based on the alarm value to have different steps
to, for example, if the alarm is very, very high
in terms of the value, then add 10 capacity units.
But if it's high, but not too high, add one.
This is the idea behind step scaling,
but we'll set up a target tracking scaling policy
because this is going to create a CloudWatch alarms for us.
So here's the name target tracking policy
and it will track the average CPU utilization
of a target value of 40,
and then I will go ahead and create my policy.
So now what we're saying is that, hey,
the goal of this ASG
is to maintain the CPU utilization to 40.
And in case, then you go over,
then please add capacity units.
So to see this in action, we need to change a few things.
So right now the main end of the desired
is one which is good, but let's set the max capacity
to be three or two whatever happens.
The idea is that you want to give it a maximum
that is greater than the minimum
so that the capacity can go from one to two
and then to three.
And so the idea now is that we want the CPU utilization
of my autoscaling group to be at a target value of 40.
So if you have a look right now at the CPU utilization
is going to be zero, obviously.
So let's have a look at EC2
is going to be close to zero because,
well, my EC2 instance is not doing anything.
So what I want to do is to go to my EC2 instance,
and I'm going to stress it to make the CPU utilization
skyrocket to 100%.
So I'm going to connect to my EC2 instance,
using EC2 instance connect, and then connect to it
and then I'll Google install stress Amazon Linux 2.
Cause there's a few commands and here is the commands,
so I'll copy the first command in here,
and then I'll copy the second command to install stress.
Here we go.
So stress is installed.
And then I just run the command stress -C 4
and this is going to make the CPU go to 100%
by leveraging four CPU units by making four VCPUs
being used at a time.
So this should make my CPU go to 100%
and so what's going to happen is that
in my monitoring of my ASG in here,
what I wanted to happen is to go see the CPU tradition
to go to something very, very, very high.
And then in activities, I want to see a scaling action.
And so that means that I will go from one instance
to two instances.
So what I'm going to do is just pause the video until,
well, enough metrics are being captured
and until we can see that the CPU utilization
is at a very high value
and then we'll see how the target tracking policy works.
So now I went into activity and under Activity history,
it says that's a alarm has been triggered
and due to the target driving policy,
then the capacity went from one instance to two instances.
So if I go into instance management,
as you can see, now I have two EC2 instances
due to the scaling.
And if I go into monitoring
and look at the EC2 level monitoring,
as we can see the CPU utilization went to a very high value
and then four scaling happens.
So how do we know that the scaling happens?
So if you're going to Automatic scaling, as you can see,
there is a target tracking policy right here.
And what I want to show you is the backend.
So if we go into the CloudWatch service in here
and go into CloudWatch,
at the left hand side, I want to go into Alarms.
So we need to go into alarms.
As you can see, two alarms are created directly
by the target tracking policy.
And one of them is called AlarmHigh, which is to scale out,
so add instances.
And one of them is called AlarmLow,
which is to scale in so less instances.
And so this one is looking at if the CPU utilization
is more than 40% for three to the points
within three minutes, then go into the alarm states.
And this one is looking at if CPU utilization
is less than 20 eights for 15 data points, then scale in.
So this is the idea.
So this one was in alarm
and so due to the metric itself, going into the alarm state,
by having the CPU utilization
going over that limit right here,
well, it got triggered
and this made a scaling activity happen
from my autoscaling group,
which in turn made a new instance being in service.
And so now if I go here and I stop this command
and I'm not even sure that I can stop it,
but if I stop this command or let me just finish it
and to stop this command,
I can probably go to my EC2 instances and reboot it.
So I'm going to have a look at this one, I believe,
and I'm going to reboot it.
So reboot this instance,
and I'm going to also reboot that one just in case.
So this should make my CPU utilization go back to zero
and this would trigger a scale in action within 15 minutes.
So I'm going to yet again, pause the video in my ASG
and see if by any chance within the activity,
I see a scale in action happening.
So I will pause right now
and actually just because I wasn't quick enough
because the CPU still was high,
then the desired capacity went from two to three.
So as we can see yet another instance has been added.
So this really shows the power of autoscaling group
and now if I go into instance managements,
we'll have three EC2 instances,
and I'm going to have to wait a little while
until they're being terminated.
So now let's go back into activity and as you can see,
more activities have been going on.
So some instances have been terminated.
So because the alarm went from the lower CPU
and then the capacity was set from three to two
and then one more time from two to one.
And so if you go into your instance management,
as you can see, one instance was already terminated
and the other one is in the terminating phase,
as that means that's your target tracking policy is working.
And you can see this by going into this alarm right here.
And as you can see, the CPU utilization went up
and then it went down
and then as soon it's past this 28% threshold,
then it went to do the alarm state,
which means that your ASG we'll start removing instances.
So that really shows the power of target tracking policies.
When you're done, please make sure to delete this policy
and you'll be good to go for the cleanup.
That's it, I will see you in the next lecture.