Setting up your ELB Healthcheck

To effectively route traffic to your various instances Amazon’s Elastic Load Balancer(ELB) needs to know which of your instances are available. The configuration for how this is done is via the ELB healthcheck value. As the health check can directly impact your uptime you’ll want to select the right value, but what will that be for your specific case?

The first choice you’ll want to make is between TCP, HTTP, and HTTPS. This choice selects the protocol that will be used to communicate between the ELB and the app instances to determine their health. Each protocol has its strengths and weaknesses that we will explore below.

TCP

The TCP check is the most basic and is configured with a specified port. The ELB will attempt to open a TCP connection to the specified port on your application instances. If the connection is accepted the instance is considered healthy. In contrast with other healthcheck values, no consideration of content is used to make this determination. This means that the TCP option is the most likely to report an instance as healthy, but also an instance reporting a 500 error to users could still be considered healthy.

HTTP

The HTTP check uses the HTTP protocol to connect to a specified port, normally set to port 81 but may differ based on customizations to your environment, on each of your application instances and then checks the specified health check path for a 200 response code. This means that a 301 or 302 redirect, a 404 file not found, and a 500 error would all mark the instance as unhealthy. While this option requires consideration of the health check path, as error pages are not considered healthy, you’ll minimize the chance of an end user seeing an error page. This is the option that will be the best fit for most sites.

If you choose to go with HTTP (or HTTPS) monitoring you’ll need to select a health check path as part of the configuration. This defaults to just the / of your application. Because the health check url needs to respond with a 200 code, it will need to be a path that is not redirected elsewhere such as to www, or to a specific domain name from an ip address. You can choose to check a static page but a page that accesses your resources can lead to more robust monitoring. For example, if you’re using ruby the check path for fitter happier makes a great choice of health check path.

HTTPS

The HTTPS check uses the HTTPS protocol to check for a valid response on the specified health check path at the specified port on each of your application instances. Like the HTTP check this check also looks for a 200 response code and will mark and instance as unhealthy if it doesn’t get one. This protocol has the same strengths and weaknesses of the HTTP protocol. However you’ll want to keep in mind that if you have an SSL certificate terminated at the ELB level, it may be possible you will not have an SSL certificate on the application instances, and thus an HTTPS based health check would not be decoded at the instance level and will fail. To avoid this trouble the SSL certificate would need to be installed directly to the environment via our dashboard.

In conclusion, the choice of which ELB health check protocol is right for you will depend upon the specifics of your application. If you’d like the instances to always be added to the ELB regardless of the HTTP response then TCP protocol is the right choice for you. If you are handling the SSL decryption directly on your instance rather than at the ELB then the HTTPS check may be right for you. However unless you’re addressing a specific concern for your application the HTTP protocol makes a great choice.