Now that we've configured our launch configuration, which again,
is going to define what we're launching and the configurations for those instances,
we now have to define an Auto Scaling group or where we're
going to launch those instances, and when to launch them as well.
So, we can see on the screen here,
our launch configuration is already populated to Web Server.
So, we're going to go ahead and give this Auto Scaling group a name.
We're going to call it webservers.
Our group size is going to start with two instances.
This is so that we can have instances across Availability Zones,
one in each to start at a minimum.
Next, I'll change the VPC to be our directory VPC.
Then for the subnets,
I'm going to select both of our public subnets that we created.
If we scroll down to the Advanced Details section,
we also have to select for
the load balancing to receive traffic from one or more load balancers.
This is because we've created an ELB in our VPC.
We're going to call this target group webservers.
Next, we can configure the scaling policies.
So, for scaling policies,
what we're talking about here,
is you can set up a scaling policy with CloudWatch that whenever
your instance capacity reaches a certain limit or any other metric that you would like,
you can add more instances to the pool, which would deploy
more EC2 instances into your Auto Scaling group.
So, we can do that right here.
So, what we want to do is use scaling policies to adjust the capacity of this group.
We want to scale between two and four instances.
Two is the min and four is the max.
We'll name this Scale Up.
Our metric type is going to be the Average CPU Utilization.
Our target value is going to be 60 percent.
Instances are going to need 300 seconds to warm up before scaling.
We can go ahead and click Next now to configure notifications.
You can configure notifications when scaling events happen.
This is optional.
So, for now, we're just going to skip past it.
We can configure tags as well,
but we're going to skip past that for now too.
Next, we will review.
Here, we can see we have our Auto Scaling group defined.
You'll notice that we skip through some of the configurations.
That's because these are optional.
By default, we can keep it simple, and go ahead and just create our Auto Scaling group.
So, I'll click Create Auto Scaling group. All right.
Our Auto Scaling group has been successfully created.
So, now all that's left to test is we need to stress
our application and make sure that our application does scale.
So, to do that, I'm going to open up a new tab.
I'm going to paste the endpoint for our elastic load balancer.
Here's our application.
I'm going to go back to that info page.
You'll notice down here that we built in a stress CPU feature.
This is going to mimic the load coming onto our servers.
Then we can watch our servers scale with that Auto Scaling policy.
So, as the CPU utilization goes up,
our Auto Scaling policy will be triggered, and our server groups will grow in size.
So, I'm going to go ahead and select 10 minutes for our stress CPU. All right.
Some time has passed,
we've stressed our application, and if we take a look at CloudWatch,
we can see what happened.
So, let's click on CloudWatch.
If you look here, we can see our Alarm Summary.
So, we stressed our system and I'm going to
click on this graph to show you guys what happened.
So, we stressed our system.
You can see here the spike in CPU.
So, we went over 60 percent CPU utilization across instances.
That was our threshold to launch new instances into the pool.
So, we launched two new instances into our Auto Scaling group.
Then you can see the load started to come down.
Because we've launched more instances into our Auto Scaling group,
there were more hosts to accept traffic from our elastic load balancer,
and the average CPU utilization then went down across our servers.
All right. So, let's exit this and go look at
the EC2 instances that were launched into the Auto Scaling group.
So, I'm going to close this.
I am going to go to the EC2 Dashboard.
From here, I'm going to scroll down to Target Groups and select webservers,
which was our Auto Scaling group.
I'm going to select targets, and we can now see that we have
four healthy targets in our Auto Scaling group. All right.
So, now we have an environment with an Auto Scaling policy and our launch configuration.
We've set up an alarm in CloudWatch,
that whenever our CPU utilization goes over 60 percent,
we're going to launch more instances into that group.
Okay, Blaine. Can you draw some things out for us to help us visualize this?
Great. So, let me just recap exactly what you just saw.
You had your EC2 instances.
Again, they're part of the Auto Scaling group.
They're identical, they're launched as part of the launch configuration.
As they were put under stress,
they all reported down to the CloudWatch engine,
saying their CPUs are overloaded.
CloudWatch went into an alarm state and told the Auto Scaling engine,
"Give me more EC2 instances."
As they each came online,
they all reported back to the elastic load balancer,
they got traffic, ending up
giving us all the scalability we need.
Now, if we wait around long enough, what we would see is,
as the CPU load dropped off, then one by one,
they would each get terminated,
because we no longer need them,
bringing our state all the way back down to the basic two we need,
the minimum number for this particular group.
All of that done without any human intervention.
I love the automation. Back to you, Morgan.
Thanks, Blaine. All right.
So, we've use CloudWatch to monitor our EC2 instances.
When our instances went over that threshold,
we had an alarm in CloudWatch that triggered our Auto Scaling policy.
For more information on CloudWatch, visit aws.amazon.com.
