AWS ELB Target Group Health Check with nginix

In my last article I configured an nginx server to redirect HTTP traffic to the HTTPS listener on an AWS Application Load Balancer—by the way, an Application Load Balancer is not a Classic Load Balancer. You can read more about that here.

That caused an issue with my target group health check. When I created my target group, I configured the health check to check the root url of my instance and expect a status code 200. However, because my nginx server is now returning a 301 status code, the health check isn’t receiving the status code it’s expecting and, thus, considers my instance to be in an unhealthy status.

First, I reviewed the health check settings I had configured. I added 301 to the Success codes property of the health check. I read about Health Check Settings in Amazon’s documentation and, while there’s no entry for “Success codes” in the docs, I found something very similar called “matcher.” Specifically, the docs have this to say about the matcher setting:

The HTTP codes to use when checking for a successful response from a target. You can specify values or ranges of values between 200 and 499. The default value is 200.¹

That sounds like a description I would have expected to see for the Success codes setting so I figured simply adding 301 to this setting would be sufficient. Turns out that the health check was failing. The response code was a 400!

After spending a good amount of time reading the AWS docs, Stack Overflow, and this particular serverfault thread², I determined that creating an nginx virutal server with a specific path reserved for the health check would enable it to find a healthy target.

nginx virtual server with dedicated status path

Add the following server block to the nginx.conf file. In my case, this is located at /etc/nginx/nginx.conf:

  server {
    listen 80 default_server;
    location /health-check {
      access_log off;
      return 200;
      add_header Content-Type text/plain;
    }
  }

Next, restart the nginx server. In my case:

  sudo service nginx restart

At this point, the nginx server is listening on port 80 and any requests to the /health-check route will recieve a 200 status code. This should satisfy the AWS Health Check.

Update health check settings

Now that our nginx server has a dedicated route for the health check and will return an HTTP 200 status code, we need to update our health check settings.

1. Navigate to Target Groups.
2. Select a target group.
3. Select Health checks tab.
4. Select Edit.
5. Edit the Path setting to match the location route defined in the nginx.conf file.
6. Click Save.

Done and done. The health check is now polling the target at /health-check and expecting a 200 response which it will recieve. It may take a few minutes for the status of the target to be updated to healthy depending on the Healthy threshold and Interval you configured.

References