So now let's talk
about ECS Service Auto Scaling.
So as we can see, we can manually increase
the number of ECS tasks in our service.
But we can also automatically increase
or decrease the number of tasks.
For this, we can leverage the service
called the AWS Application Auto Scaling.
And we have three metrics we can scale on using the service.
We can scale on the CPU Utilization of the ECS Service.
We can scale on the Memory Utilization,
which is the RAM of the ECS Service.
Or, the ALB Request Count Per Target,
which is a metric coming from the ALB.
So only these metrics you have to remember.
Then, you can set up different kind of auto scaling.
You can set up Target Tracking to track
for a specific target for the three metrics shown above.
Or Step Scaling.
Or Scheduled Scaling,
if you wanted to scale your ECS Service ahead of time
thanks to predictable changes.
Remember, that scaling your service, your ECS Service,
at the task level is not equal to scaling your cluster
of EC2 instances if you are in the EC2 launch type.
And so therefore, that's why when you don't
have an EC2 auto scaling that's necessary,
when you don't have EC2 instances in the backend,
then using Fargate makes service auto scaling much easier
to set up, because everything is serverless.
And it's why I'm fan of Fargate.
And the exam is pushing you to use Fargate a lot.
So for the EC2 launch type,
how can we actually scale the EC2 instances
in the backend if we're using it?
So we have multiple ways of doing it.
We can use an Auto Scaling Group Scaling.
And so we scale our ASG, for example,
based on CPU Utilization.
And then we can add EC2 instance over time
if the CPU skyrockets.
Or, we can use the newer and more advanced feature
called the ECS Cluster Capacity Provider
that we've seen before in the hands-on.
And with this one, the Capacity Provider is very smart.
And as soon as you lack capacity to launch new tasks,
it's going to automatically scale your ASG.
So the Capacity Provider is paired
with a Auto Scaling Group.
And then when you're missing RAM or CPU,
there you go, EC2 instances are created.
And so the second option is the smarter way of doing things.
So if you have to choose between Auto Scaling Group Scaling
and ECS Cluster Capacity Provider,
please use ECS Cluster Capacity Provider
for your EC2 launch type.
So let's have a look at the service.
So we have a Service A with two tasks.
And we have CPU Usage.
And it's going to be auto scaled
by the AWS Application Auto Scaling.
But let's assume we have more users,
and therefore your CPU usage goes really up,
then your CloudWatch Metric,
which monitors the CPU Usage at the ECS service level again,
is going to trigger a CloudWatch Alarm,
which will trigger a scaling activity
in your Auto Scaling for your ECS service.
The desired capacity will increase
for your ECS Service, and a new task will be created.
And optionally, if this service is running
on the EC2 launch type,
then the ECS Capacity Providers
can help you scale your ECS cluster
backed by EC2 instances.