‫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.