AWS recently added two additional features to Route 53 health checks, which are HTTPS support and string matching. Lets see what these features do and how would it help a DevOps Engineer.
To begin with, Route53 Health checks have hitherto supported TCP and HTTP end-points. In both the options, Route53 would try to establish a TCP connection which needs to be successfully connected within four seconds. In case of a HTTP end-point, Route53 would expect a HTTP 200 or greater (but less than 400) status code in the response within two seconds after connecting in order to conclude that the resource is healthy.
HTTPS support to Route 53 will simplify resource health check over SSL. Similar to HTTP health check, Route 53 tries to establish a TCP connection to the resource over the port 443(default). Prior to HTTPS support, web servers with SSL enabled had to serve at least one page over HTTP for the health check to pass, but not anymore.
Now in HTTP or HTTPS health check, you can also specify a string which Route 53 needs to look for in the response, in order to conclude that the instance is healthy. I see a wide range of opportunities for a DevOps Engineer here to improve the availability of the application.
You could potentially have an application status check page(say status.php) as a Route53 health check end point. In this page you could initially perform a check on the status of the server, application, database connectivity and other relevant internal health checks and update a string which would indicate that the server is healthy. Route53 would inturn look for this string in order to conclude that the resource is healthy. This way a DevOps engineer could improve the availability by including various status checks as a single operation and provide the same as input to Route53. Note that the string needs to appear within the first 5120 bytes of the response body.
So in a
nutshell, these new features to Route53 make a DevOps engineer’s life much easier.