-: So let's have a look at status checks.
So status checks on your EC2 instances
are automatic checks done by AWS for you
that will identify hardware and software issues
with your EC2 instances.
So there are two types.
The first type is a system status check,
and this will be a monitoring of problems that will happen
with the systems of AWS directly.
For example, a software or a hardware issue
on the actual physical host that will be used,
that will be the one that your EC2 instance is placed on.
Or for example,
if your host has a loss of system power and so on.
To have an overview of these issues,
the place to look at is the personal health dashboard.
And this will give you information around any scheduled,
critical maintenance by AWS
that will affect your institute instance host,
and therefore you need to act on it.
So a way to act on it is to stop and start your instance.
So let's have a look.
As we can see here, we have a host 1.
This is hidden to us, okay,
but this is what happens in the data center of AWS.
And our easy two instance is launched onto this Host 1.
Then, say that AWS has a hardware failure.
Then this system status check
will be going from zero to one
and what we have to do is to stop
and start the EC2 instance.
So anytime you stop an EC2 instance,
and then you start it again.
So not a reboot, right?
But a stop and a start.
Then internally what's going to happen
is that your EC2 instance will automatically be migrated
to a different host within AWS,
which also explains why it will get
a new difference public IP,
because this will be the public IP
of the host that you're on.
So this is a different host migration.
So it goes from a Host 1 to Host 2.
And because we'll just stop and start it,
then we know that it's moved
and the Host 2 does not have any issues.
And so therefore we've solved our hardware failure problem.
The second type of problem is an instance status check.
This is to monitor software
and network configuration of your instance.
For example, the network configuration becomes invalid,
there's exhausted memory, this kind of stuff.
In which case, to just resolve this issue,
you should just reboot the EC2 instance
or change the instance configuration.
So these are the two types of status checks
on your EC2 instance,
but there is a way for you to automate the recovery
and look at CloudWatch metrics.
So CloudWatch Metrics are: StatusCheckFailed_System,
StatusCheckFailed_Instance,
or StatusCheckFailed if you want to regroup
these two issues in one metric.
So option one is choose a CloudWatch Alarm
to recover your EC2 instance.
So there is an action called recover instance.
And when it's being used by CloudWatch Alarm,
it will recover the instance by using the same private IP,
the same public IP, the same EIP,
the same metadata and the same placement group.
You can also send a notification
because it's a CloudWatch Alarm, likely to SNS.
So your EC2 instance
will be monitored by CloudWatch Metrics,
for example, for the status checked failed system metric.
The CloudWatch Alarm will be triggered
on top of your CloudWatch Metric in case it goes to one,
and the action of your CloudWatch Alarm
will be to recover your EC2 instance
by placing it somewhere else.
You can also send a notification to Amazon SNS,
as I just said.
The option two, which is a bit less conventional,
is to use an auto scaling group
with a min, max and desired of one.
And within health check to check for the status check
of your EC2 instance,
what will happen is that in case there is an issue
with your EC2 instance,
it will be terminated by your auto-scaling group.
And therefore, because we have a min,
max and desired to one,
a new EC2 instance will be launched
within your same auto-scaling group.
So in this case, you don't have the same EBS volumes,
you don't have the same private IP,
you don't have the same elastic IP,
but at least your instance is back up and running.
And if you automate things well,
then you could maybe regain back its states.
Okay, so these are two options.
Obviously option one's going to be much preferred
if you have emphasis on one specific EC2 instance.
So that's it for this lecture, I hope you liked it
and I will see you in the next lecture.