Let's break down the most likely reasons your registered EC2 instance is showing as Unhealthy in your target group, along with actionable troubleshooting steps:

1. Security Group or Network ACL Blocking Traffic #

This is the most common culprit. AWS Load Balancers need clear communication paths with your EC2 instance over the health check port (80 in your case):

• EC2 Instance Security Group: Ensure it allows inbound traffic on port 80 from your load balancer's security group (or the CIDR range of the ALB's subnets). Avoid opening port 80 to 0.0.0.0/0 unless necessary—lock it down to trusted sources only.
• Load Balancer Security Group: Verify it permits outbound traffic to port 80 (your EC2 instance's listening port).
• Network ACLs: Check subnets hosting both the ALB and EC2 instance. Ensure inbound rules allow traffic from the ALB to EC2 on port 80, and outbound rules allow return traffic (typically ephemeral ports 1024-65535) from EC2 to the ALB.

2. EC2 Instance's HTTP Service Isn't Running or Responding #

An instance marked "running" doesn't guarantee its web service is functional:

• Log into your EC2 instance and check if the HTTP service (Apache, Nginx, etc.) is active:

  # For systemd-based systems (Amazon Linux 2, Ubuntu 18.04+)
  sudo systemctl status httpd  # replace with nginx if using that
  

• Confirm the service is listening on port 80:

  ss -tulpn | grep :80
  

• Test the health check path directly on the instance to verify it returns a valid 2xx/3xx status code:

  curl -I http://localhost/
  

  If this returns a 4xx, 5xx, or no response, your web service or path is misconfigured.

3. Health Check Path Misconfiguration #

Your target group pings HTTP:80/, but:

• The root path (/) might not exist on your web server, returning a 404 error. Check your web server's document root to ensure there's a valid index file (like index.html or index.php).
• The path might redirect to HTTPS (returning a 3xx code), but your health check is set to HTTP. If your service forces HTTPS, update the ping target to HTTPS:443/ (and ensure port 443 is open in security groups/ACLs).

4. Availability Zone Mismatch #

The error message "None of these Availability Zones contains a healthy target" points to a potential AZ alignment issue:

• Confirm your load balancer is deployed in the same Availability Zones as your EC2 instance. If the ALB only exists in us-east-1a but your EC2 is in us-east-1b, the ALB can't reach the instance.
• Check that your target group includes the Availability Zone where your EC2 instance resides (verify this in the target group's "Attributes" tab under "Availability Zones").

5. EC2 Instance Resource Constraints #

If your instance is under extreme load, it might fail to respond to health checks in time:

• Check CloudWatch metrics for the instance: look for high CPUUtilization, low MemoryUtilization, or exhausted DiskSpaceUtilization.
• Log into the instance and use tools like top or htop to identify resource bottlenecks (e.g., a runaway process consuming all CPU).

6. Health Check Threshold Context #

Your configuration uses a Healthy threshold of 10—this means the instance needs 10 consecutive successful checks to be marked healthy. If you just registered the instance, it might still be in this validation window. However, since it's already marked Unhealthy (triggered after only 2 failed checks), this is likely not the root cause.

内容的提问来源于stack exchange，提问作者user999627