Instructor: So let's talk about Health Checks
in Route 53.
So health checks are a way for you to check
the health of mainly public resources,
although there's a way for us to do it
for private resources as well, as we'll see in this lecture.
So the idea is that, for example,
we have two Load balancers in different regions
and they're public load balancers, okay?
And behind the scenes,
we have our application running in both of them.
So we're running into a multi-region setup
because we want high availability, and so on,
at the region level.
Then we're going to use Route 53 to create DNS records.
So that's when users access our URL, for example,
mydomain.com, then they get redirected to, for example,
the closest load balancer they have.
So this would be the case with a latency type of record.
But we want to make sure that, if one region is down,
then we don't send our users to that region,
obviously, right?
So to do so,
we're going to create health checks from Route 53.
So we'll create health checks on the one in us-east-1,
and we will create a health check on our instance
in eu-west-1.
Well, with these two health checks,
we're going to be able to associate them
with our Route 53 records.
And the reason we do so is to get automated DNS failover.
So we have three health checks that are possible.
The ones I just showed you, which are the health check
that monitor an endpoint, which is a public endpoint.
So it could be an application, a server,
or another AWS resource.
It could be a health check
that monitors other health checks,
also called a calculated health check,
or it could be a health check
that monitors a CloudWatch Alarm,
which gives you more control and is helpful for private
resources as we'll see in this lecture.
Finally, these health checks have their own metric
and you can view them in CloudWatch metrics as well.
So let's look at how health checks work
with a specific endpoint.
So if we have a health check for eu-west-1, for an ALB,
then the health checkers of AWS
are coming from all around the world.
So it's not just one health checker.
It's about 15 health checkers from all around the world.
And they're all going to send requests
into our public endpoint to wherever routes we set.
And then if it gets 200 OK code back or the code we defined,
then the resource is deemed healthy.
So about 15 global health checkers
will check the endpoint health,
and then you can set a threshold for healthy or unhealthy.
You can set an interval,
so we have two options.
It could be either 30 seconds for regular health checks
or every 10 seconds, which is a higher cost,
which is what's called a fast health check.
It supports many protocols, so HTTP, and HTTPS, and TCP.
And the rule is that if over 18% of the health checkers
say that the endpoint is healthy,
then Route 53 will consider it healthy,
otherwise it's deemed unhealthy.
And you have the ability to choose
which locations you want to use for the health checks.
Now the health checks will only pass if you have the status
2xx or 3xx status code back from the load balancer
and the health check has a cool capability.
So if it is a text-based response,
then the health checkers can check the first 5,120 bytes
of the response to look for some specific texts
in the response itself.
Finally, very important from a network perspective,
if you want for it to work, obviously,
the health checkers must be able to access your
Application Balancer or whatever endpoints you have.
And so therefore you must allow incoming requests
coming from the Route 53 health checkers' IP address range.
And you can find this address range at the URL
in the bottom right of the screen.
Now the second type of health checks we have
are calculated health checks.
And so this is to combine the results
of multiple health checks into a single health check.
And so if you look at Route 53,
with three EC2 instance,
we can create three health checks.
They're all going to be children health check,
and they can all monitor each EC2 instance one by one.
And then we can define a parent health check,
which is going to be defined
on all these child health checks.
And so the conditions to combine all these health checks
could be an OR, an AND, or a NOT.
You can monitor up to 256 child health checks,
and you can specify how many of the health checks
need to pass to make the parent pass.
So the use case for this,
for example, if you want to have
a parent health check to perform maintenance
on your website without causing
all the health checks to fail.
And so how do we monitor the health of a private resource?
So in case you want to monitor something private,
it's going to be difficult because
while all the Route 53 health checkers
live on the public web, they're outside of your VPC,
so they cannot access private endpoints.
So if it's a private VPC or an on-premises resource.
And so the way we can do it, though,
is to create a CloudWatch Metric
and assign a CloudWatch Alarm on it.
And then you can assign the CloudWatch Alarm
into the health checker.
So the idea is that we're going to monitor
the health of our EC2 instance in a private subnet
with a CloudWatch Metric.
And then if the metric is breached,
we're going to create a CloudWatch Alarm on it.
And when the alarm goes into the alarm state,
then the health checker is going to be
automatically unhealthy
and therefore will have created exactly what we want,
which is a health check on a private resource,
which is the most common use case on how to do it.
So that's it for this lecture.
I hope you liked it and I will see you in the next lecture.