Instructor: So now let's talk about
auto scaling group scaling policies.
And we have two different kinds,
we have the dynamic scaling policies first.
And so within the dynamics scaling policies,
we have three kinds, we have the target tracking scaling,
which is pretty easy.
It's the most simple and easy to set up.
And the idea is that you wanna say, for example,
I want to track the average CPU utilization
of my autoscaling groups across all my EC2 instances
to stay at around 40%.
This is when you want to have a default baseline
and wanna make sure that you're always available.
Simple and step scaling is more involved.
So you set up your own CloudWatch alarms
and when they're triggered so reasonable,
when the CPU goes over 70% for your ASG as a whole,
then add two units of capacity.
And then you would set up a second rule saying,
hey, in case the CPU utilization goes to less than 30%
as a whole within my ASG, then remove one unit.
But you would have to set up your CloudWatch alarms
as well as the steps which is,
how many units you wanna add at a time
and how many units you want to remove at a time.
And finally scheduled actions,
which is to anticipate scaling
based on the known users patterns.
For example, you're saying that,
hey, I know that there's going to be a big event
at 5:00 PM on Fridays
because when people are gonna be done with work
and they're going to use my application,
and therefore you want you to increase the min capacity
automatically of your ASG to 10 at 5:00 PM
every single Friday.
This is a scheduled action
where you know scaling in advance.
And there's a new kind of scaling,
which is called predictive scaling.
So with predictive scaling,
you continually have a forecast being made
by the autoscaling service in AWS.
And it will look at the load
and we'll schedule scaling ahead.
So what will happen is that
the historical load is going to be analyzed over time
and then forecast is going to be created.
And then based on that forecast,
they will be scaling actions being scheduled ahead of time,
which is a quite a cool way of doing scaling as well.
And I think this is the future
because this is machine learning powered,
and this really is a hands-off approach
to automatic scaling for ASG.
So some good metrics with scale on is a big question.
So it depends really on what your application is doing
and how it's working,
but usually here are a few.
So number one is CPU utilization
because every time your instance receive a request,
usually they will do some sort of computation
and so it will use some CPU.
And so if you look at the average CPU utilization
across all your instances and it goes higher,
that means that your instances are being more utilized
and so it would be a good metric to scale on.
Another metric to scale on,
it's more like application specific,
but it is a request counts per targets,
which is based on your testing.
You know that your EC2 instances
operate at an optimal request
of 1000 per request per target at a time
and so maybe this is the target you want to have
for your scaling.
So here's an example.
You have an auto scaling group with three EC2 instances,
and your lb is currently spreading the instance request
across all of them.
So right now the value of the request
counts per target metric is three
because each EC2 instance on average
has three requests outstanding.
Next, if your application is network bound,
so for example, there's a lot of uploads and downloads
and you know that network is going to be a bottleneck
for your EC2 instances,
then you may want to scale on the average network in or out
to make sure that if you reach some certain threshold,
then you're going to scale based on that.
Or any custom metrics that you push to CloudWatch,
you can set up your own metrics
that are going to be application specific
and based on that, you can set up your scaling policies.
Now, what else would you need to know about scaling policies
is what's called the scaling cooldown.
So the idea is that after there is a scaling activity,
so whenever you add, or you remove instances,
you are entering the cool-down period,
which is by default five minutes or 300 seconds.
And during that cooldown period,
the ASG will not launch or terminate additional instances.
And the reason behind this reasoning is that
you allow four metrics to stabilize, okay,
for your new instance to enter into effect
and to see what the new metric will become.
So the idea is that
when there is a scaling action that occurs,
the question is, is there a default cooldown in effects?
If yes, then ignore the action.
If no, then proceeded with the scaling action
which is to launch or terminate instances.
And so in advice to you, is to use a ready-to-use AMI
to reduce the configuration time for your EC2 instances
in order for them to request
or to be serving the requests faster.
So if you don't spend time configuring your EC2 instance,
then they can be in effect right away.
And then because there can be active way faster
then the cooldown period can be decreased,
and you can have a more dynamic scaling up and down
of your ASG.
And of course you need to make sure
to enable something like detailed monitoring for ASG
to get access to lower level two metrics every one minute,
and to make sure that you have these metrics
being updated fast enough.
So that's it for this lecture.
I hope you liked it,
and I will see you in the next lecture.