With AWS Auto Scaling Groups, you have a lot of options regarding how you scale, determining instance health, and where and how you launch your EC2 instances. One piece of the auto scaling configuration that I find myself frequently modifying from the default is the Health Check Type.

This property allows you to configure how your auto scaling group determines if an instance is healthy or unhealthy - in turn affecting if and when the instance is replaced. I find that the default value of EC2 is a bad indicator of application health in most cases, because even if the instance itself is healthy (namely, the instance is reachable, hasn’t crashed, etc.), your application may have died within the instance. With the EC2 health check, you really don’t know if your application can handle requests or is still performing it’s duties correctly.

If your application runs behind a load balancer, I highly recommend that you add the ELB to your auto scaling group’s configuration using the Load Balancers property like so:

Once your ELB has been associated with the auto scaling group, you can then instruct it to be used for the Health Check Type:

Of course you can also set these properties using the command-line or the various SDKs for better automation, especially if you have many auto scaling groups or you tear down and recreate environments frequently.

By setting the Health Check Type to ELB, we can be sure that if the ELB health check is failing, the instance will be terminated and a new one will take it’s place, giving you true failover in the event that your application goes down. As a bonus, if the EC2 instance itself goes down, you will still get the proper failover from an ELB health check because your application will be unreachable to the ELB, deemed unhealthy, and subsequently destroyed by the auto scaling group - the best of both worlds.