by INVOKE Team
Monitoring is key component in infrastructure teams every day job. This can be for different purposes like:
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::
These health checks serve different purposes and help services like Auto Scaling, R53 and application endpoint monitoring to manage the AWS resources. Let us take a quick look at these services before I describe what we learned while using these services.
This means allocating more CPU than baseline performance. AWS uses “CPU Credits” to calculate how much more capacity it can assign to this EC2 instance.
“ 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.
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:
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.
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).
If your application is public facing application, setup will be simple:
If your application is private facing application, setup will be little complicated:
When Route 53 checks the health of an endpoint, it sends an HTTP, HTTPS, or TCP request to the IP address and port that you specified when you created the health check. For a health check to succeed, your security group must allow inbound traffic from the IP addresses that the Route 53 health checkers use. R53 has health checkers in locations around the world.
Another solution, use ELB (alias record) instead of just EC2 instance. If cost is not a concern, this is a little cleaner solution.
One other solution is, configure security group to allow communication from IP address ranges that are associated with Route 53 health checkers . This saves cost as well as keeps application private. The disadvantage with this approach is, maintenance headache. These R53 health checker IP address ranges could change anytime. You need to validate and update the security group with new IP range frequently (whenever they change).
Have any questions on cloud savings? Talk to us, we could help you.
Using schedulers to save cloud hosting costs? you should read the blog AWS EC2 Schedulers - not good enough tool to reduce AWS bill
READY TO SAVE ON CLOUD COSTS? Get Started for free