I've recently started a new role where I've inherited an Elastic Load Balancer (ELB) setup. Currently, all the targets are showing as unhealthy because of some misconfigured health checks. However, the application that's exposed to the internet still seems to be functioning normally, as it routes requests to these unhealthy targets. Is this behavior normal, or am I misunderstanding what the purpose of the health checks is? In other projects outside of AWS, unhealthy targets typically mean that the service would return a 50x error due to a lack of available targets.
3 Answers
I’m dealing with something similar on an EKS-managed ALB, and my targets are often marked unhealthy too. It’s a bit of a headache, but I’m not sure if it’s worth the effort to fix them. It seems to work fine regardless.
From what you've described, it sounds like your targets might be returning HTTP status codes in the 200-499 range. That's potentially why the ELB continues to route traffic there. If your health check status shows a timeout, consider implementing a specific health endpoint like '/health' that reliably returns a '200 OK'. This could help optimize your ELB configuration.
It's actually expected behavior! With an Application Load Balancer (ALB), if all targets are unhealthy, it still routes traffic to them anyway, which is referred to as ‘fail open’. This means that the load balancer won't block requests, even though there's a health issue with the targets. Just make sure to check the health check configuration to understand why they’re failing.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures