Instructor: Okay, so let's have a look
at a few features you need to know,
going into the SysOps exam.
So, the lifecycle hooks is a way for you
to hook into the lifecycle of an ASG instances.
So that means, whenever it's being initiated and terminated.
So by default, as soon as you create an instance,
it goes into service right away.
So it goes from pending to in service.
But you can set up an lifecycle hook for that effect.
And so it can go into some extra steps.
So after pending, it can go into a pending wait state
as part of your lifecycle hook, okay?
And in that state, you can define a script
to run on the instance as they start.
For example, for some initial setup.
So when you're done with the initial setup
of your EC2 instances,
you make them go into a pending proceed state.
And then after that, they will be moved
into the in service states.
So this lifecycle hook really allows you
to perform some kind of custom logic
between the pending and the in service states.
Then, you can also perform some action
before the instance is terminated.
So for example,
you want to pause the instance
before they're terminated for troubleshooting,
and what this will give you is the opportunity,
for example, to take the logs out of your instances.
So let's say that instance goes from in service
to terminating, then in part of your lifecycle hook, okay,
you can go into the terminating wait state, okay.
And then when you're there,
you can execute again, some scripts,
or get some logs out, or do whatever you want,
or even get some information out, take an AMI,
whatever you want, really.
Or take an EBS snapshot,
and then go into terminating proceed.
And then after this, it will go into the terminated states.
And then, the use-cases for all these lifecycle hooks
is really to do cleanup, log extraction,
or special health checks, before your instance is started
and goes in service.
And to integrate the scripts into these lifecycle hooks,
there's EventBridge, SNS, and SQS.
So whenever there's a lifecycle event trigger,
one, a message can be sent to these three destinations.
And if it goes into even EventBridge, for example,
it can invoke the Lambda function
for you to perform any kind of scripting you want,
on top of things.
Okay, so very quickly, there's launch configuration,
and launch templates.
So, both allow you to specify the AMI,
the instance type, a key pair, security groups,
and any other parameters to launch your EC2 instance,
which has tags and user-data, okay.
And they're both used by your ASG to launch instances.
But you cannot edit them.
So whenever you wanted to create a new launch configuration,
you actually create a new one, and launch template,
you have to create a new version.
So launch configuration must be recreated every single time.
They're part of their legacy of AWS,
so they are not used anymore, really.
And launch templates are newer,
so they can have multiple versions,
which is a much cleaner way
of evolving your launch templates.
They can create parameter subsets,
so you can have launch templates
based on other launch templates
for configuration reuse and inheritance.
You can provision both on-demand and spot instances
as part of your launch templates,
or a mix, to have a fleet that's going to be optimized.
You cannot do this with launch configuration.
It supports placement groups, capacity reservation,
dedicated hosts, and multiple instance types.
And you can use the T2 unlimited burst feature.
So this is the recommended thing to use,
going forward by AWS.
Next, you can look at your SQS with auto-scaling.
So how to scale, and it's gonna group,
based on an SQS queue status.
So, in this example we have an SQS queue,
and a bunch of EC2 instances processing messages from it.
And what you want to do, is to scale your ASG
based on whether or not you have more messages
in your SQS queue.
So for this, you can create a CloudWatch metric.
For example, on the queue length.
So the metric name is approximate number of messages.
And whenever that queue length is too big,
that means you have too many messages to process.
Then you can create an alarm,
and that alarm will go into CloudWatch alarm,
and would be triggering a scaling policy
on your ASG.
Now for your ASG, your multiple health checks.
So, to make sure you have the high availability,
and you need to have at least two instances
in your ASG, okay, in multi-AZ ASG.
And then you can do some health checks,
such as the EC2 status checks.
So, to make sure that the underlying software
and hardware of your EC2 instances are still functioning,
which is enabled by default.
But also the ELB health check.
So this is to make sure that your application,
if linked to a target group and an ALB will be checked,
will be having its health checked by the ELB as well.
And in case, while the ELB figures out
that your instance is unhealthy,
then your ASG will terminate it.
And there's one last type of health check,
which is called the custom health check,
which is to send the instance health
to the ESG manually, or automatically,
using the CLI or the SDK.
So there is an API call for you
to set the instance health directly on your ASG.
That's why it's called the custom health check.
So, whenever a health check is not passing,
then the instance will be deemed unhealthy.
And a new instance will be launched
after terminating an unhealthy one.
There will not be a reboot of unhealthy hosts for you.
So, if the instance is failing its EC2 status check,
then it will not reboot the instance.
It will just terminate it and launch a new one.
So, good to know CLI is set instance health.
So this is the API call that's being used
for the custom health checks.
And terminate-instance-in-auto-scaling-group,
as well as another one that you should be using.
Finally, some common troubleshooting around your ASG.
So if you have already, some instances running in your ASG,
but you cannot launch any new EC2 instances,
it could be for example,
that while your auto-scaling group has reached a limit
that you set by your maximum capacity parameter,
in which case you have more instances,
you need to increase the maximum capacity
for you as you to scale out more.
Another also common problem
for new instances not being launched,
is that you have a capacity issue in the AZ.
And so therefore, because the ASG cannot find capacity,
then the instance cannot be launched.
Then, if launching a specific EC2 instance is failing,
maybe the security group does not exist.
So it might've been deleted in the backend.
So, have a look for this.
Or the key pair does not exist.
It might've been deleted as well.
And if there is issues for your ASG to launch instances
over 24 hours, then it will suspend the processes
of auto-scaling, which is a suspension that's automatic
for you to debug, okay?
So that's it for an overview of the things you need to know,
going into the exam as a SysOps.
I hope you liked it, and I will see you in the next lecture.