It’s crucial to know when your public HTTP(S) APIs or web applications go down, even for a short moment. Interruption of service could be extremely detrimental to you or your company’s success, resulting in violated SLAs, unhappy customers. You’d prefer to know about it immediately, rather than the testing team, or customer itself.
Setting up an HTTP, HTTPS, and TCP health check on AWS is extremely easy, thanks to Route 53’s Health Check feature:
Route 53 health checks monitor the health and performance of your application’s servers, or endpoints, from a network of health checkers in locations around the world. You can specify either a domain name or an IP address and a port to create HTTP, HTTPS, and TCP health checks that check the health of the endpoint.
So Route 53 is the right tool for this simple job. Basically, it’s a service that will ping your endpoint from the internet every X seconds, from about 8 different cross-region instances(configurable regions), to make sure that your web site, API or other service is responding with a successful return code.
DNS failover: You can also use Route 53 health checks for DNS failover by associating health checks with any Route 53 DNS resource record set. This lets you route requests based on the health of your endpoints.
The Route 53 Health Check costs just $0.50/month for the basic setup, as per the Route 53 pricing page. That’s a very cool price since it’s a highly available and scalable service that would be a headache to set up on your own.
Please open the Route 53 Health Check management page in the AWS Console.
Click Create health check and you’ll be presented with a health check configuration screen.
Start by labeling your health check. This can be anything, but setting it to the domain or IP address that you will be monitoring will be useful in easily recognize it if you create more health checks in the future.
Specify endpoint by
Next, select IP Address or Domain Name, based on the type of resource you will be monitoring. If you have an API at api.mytest.com, you’d select Domain Name. If you have a load-balanced endpoint and want to monitor a specific server, choose IP Address.
Select the desired protocol. If you set up SSL for your endpoint, you should select HTTPS. Otherwise, leave the default HTTP option selected. Note that selecting HTTPS will cost you an additional $1/month for each endpoint.
IP Address or Domain Name
The hostname of your endpoint, either an IP or domain name.
80 for HTTP, 443 for HTTPS.
If your API resides in mytest.com/api, you’d specify api in the health check path. Furthermore, if you’d like to set up custom health checks of your own, you can define a custom route in your API, e.g. /health.
Here you can also make sure that your DB is UP, and/or the 3rd party APIs are not down, and so on. In case any of your custom health checks fail, just return an error code, Ex. 500 Internal Server Error, and Route 53 will send an e-mail alert to notify you automatically.
You’ll most likely not need to modify any of these, but if you want, the attributes are self-explanatory.
When you create a health check, and if you want to check the latencies, please tick the Latency graphs option, with this you can see the below values on CloudWatch graphs on the Route 53 console
The next step is to configure the e-mail alerts for when the health check fails. Route 53 uses CloudWatch and SNS to accomplish this.
Select “Yes” to create a CloudWatch alarm for this health check. Otherwise, the health check status will only be visible in the AWS Console.
Send notification to
Select “New SNS topic”, unless you already set up an SNS topic for your endpoint health check.
Choose something to identify the endpoint’s health checker.
Recipient e-mail addresses
Enter the e-mail address(es) which will receive the health check notifications.
Finally, click ‘Create health check’ to create the health check.
The last step is to confirm the SNS subscription for the health check alert e-mails.
Log into the recipient e-mails and click the confirmation links, otherwise, you won’t receive the alerts.
Wasn’t that easy? Now you’ll be notified when your/any endpoint goes down.
Note: You should do a test, to make sure that the health check actually works – if you can, take down your endpoint and see if you get notified, to emulate a real downtime situation.