Health checks failed with these codes: [502]

Question

I'd like to mention that I'm not an experienced tech person, but I've been trying to learn AWS through an online course and I'm stuck at a particular point:

I've created two target groups made up of two EC2 linux instances each, and some simple code as part of the user data for each instance.

#/bin/bash
yum update -y
yum install httpd -y
systemctl start httpd
systemctl enable httpd
cd /var/www/html
echo "This is an INSTANCE" > index.html

I then created an Application load balancer with an HTTP listener (port 80). The ALB has been associated with subnets that use a security group that definitely have public access (I've used the same security group for other exercises that have public access)

But every time, both target groups show a description of "
Health checks failed with these codes: [502]". I've tried everything I can think of and I've even tried doing some research, but couldn't figure it out.

Before anyone gets irritated, I haven't used Stack overflow before, so if this is a duplicate thread, I apologize, but in the other threads I saw, there were other, more complex conditions.

Does anyone have any ideas?

Answer 1

The title of HTTP 502 error is Bad gateway.

I encountered the same error and it was due to the fact that the health checks were configured over different protocol (HTTP) then the target group protocol (HTTPS).

Additional possible reasons are mentioned here:

HTTP 502: Bad gateway

Possible causes:

 - The load balancer received a TCP RST from the target when attempting to establish a connection.

 - The load balancer received an unexpected response from the target, such as "ICMP Destination unreachable (Host unreachable)", when attempting to establish a connection. Check whether traffic is allowed from the load balancer subnets to the targets on the target port.

 - The target closed the connection with a TCP RST or a TCP FIN while the load balancer had an outstanding request to the target. Check whether the keep-alive duration of the target is shorter than the idle timeout value of the load balancer.

 - The target response is malformed or contains HTTP headers that are not valid.

 - The load balancer encountered an SSL handshake error or SSL handshake timeout (10 seconds) when connecting to a target.

 - The deregistration delay period elapsed for a request being handled by a target that was deregistered. Increase the delay period so that lengthy operations can complete.

 - The target is a Lambda function and the response body exceeds 1 MB.

 - The target is a Lambda function that did not respond before its configured timeout was reached.

(*) Additional resource - How do I troubleshoot and fix failing health checks for Application Load Balancers?

Answer 2

Your scripts were never run because the User Data needs to start with #!, but your script only starts with a #.

If there is no #!, then it will not be executed as a script.

When debugging a Load Balancer situation, a good process is:

• Try accessing the instances directly, to confirm that they are responding as web servers. If not, login to the instance and examine /var/log/cloud-init-output.log to see if the User Data generated any errors.
• Check the Security Groups to confirm that they are configured correctly, which is typically:
  • A Security Group on the Load Balancer (ELB-SG) that permits inbound web traffic from the Internet
  • A Security Group on the Amazon EC2 instances (App-SG) that permits inbound web traffic from ELB-SG. That is, App-SG specifically references ELB-SG.

Also, please note that systemctl works correctly on Amazon Linux 2, but not "Amazon Linux" (v1).