Welcome to Day 72 of the #100DaysOfDevOps Challenge! Today we will see the Health checks in AWS.
What Are Health Checks?
In load balancing, health checks are routine tests that the load balancer performs on registered targets to ensure that they can handle requests. If a target fails the health check, the load balancer will cease to send traffic to that target, rerouting it to other healthy targets.
Health checks are vital to maintaining the stability and efficiency of the system, and they play a crucial role in avoiding routing requests to malfunctioning components.
AWS provides different approaches to address these issues. Health checks are a way AWS users use “resource status monitoring” to verify their services like EC2 instances are running or not.
A few different types of health checks AWS users can configure/use are::
EC2 health checks
ELB health checks
Custom health checks
We can use these different types of health checks in services like Auto Scaling, R53 and application endpoint monitoring. Let us quickly take a look at these services quickly before I describe what we learned while using these services.
Auto Scaling:
“Amazon EC2 Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application. You create collections of EC2 instances, called Auto Scaling groups.”
You can specify the minimum number of instances in each Auto Scaling group, and Amazon EC2 Auto Scaling ensures that your group never goes below this size. You can specify the maximum number of instances in each Auto Scaling group, and Amazon EC2 Auto Scaling ensures that your group never goes above this size.
Auto Scaling groups use health checks to keep up with the group configuration defined. EC2 status checks are default for Auto Scaling, if an instance fails these status checks, Auto scaling considers instance unhealthy and replaces it. If ASG has LB or target groups configured, then you can configure ELB health checks as a way to determine instance’s health. Note that attaching LB or target group to ASG will not enable this configuration default, you need to define explicitly.
Apart from LB/target group checks, if you have own EC2 health check system, custom health checks , are the way to go with ASG scaling configuration.
R53
Amazon Route 53 health checks monitor the health and performance of your web applications, web servers, and other resources. Each health check that you create can monitor one of the following:
The health of a specified resource, such as a web server
The status of other health checks
The status of an Amazon CloudWatch alarm
Based on business needs, users can pick the type of health check they would like to configure. For example, at regular intervals that you specify, Route 53 submits automated requests over the internet to your application, server, or other resource to verify that it’s reachable, available, and functional.
Status of other health checks approach is useful in cases like, when you have multiple resources that perform the same function, such as multiple web servers, and your chief concern is whether some minimum number of your resources are healthy. You can create a health check for each resource without configuring notification for those health checks.
What did we learn?
The key lessons learned are, while configuring R53 health checks, security groups could make your life complicated (specially if you want to keep your application access to your company IPs).
Load balancers make your life easy while may add some bill: To discover the availability of your EC2 instances, a load balancer periodically pings, attempts connections, or sends requests to test the EC2 instances. These tests are called health checks. The status of the instances that are healthy at the time of the health check is In Service.
Load balancer accepts incoming requests
Configure instance security group to allow requests only from LB security group
Map load balancer to private DNS (or) configure LB security groups to limit to whatever IP you would like to
Non ELB health checks could be complicated:: Users could choose non-alias records (just EC2 instance) approach for reasons like reduce aws bill , specially for their dev/qa environments — things will become little challenging in this setup. If you’re routing traffic to resources that you can’t create alias records for, such as EC2 instances, you create a record and a health check for each resource. Then you associate each health check with the applicable record.