3

I created two different versions of the auto-scaling group template.

The first template doesn't auto-assign a public IP to the EC2 instances on creation, so there is only a private IP assigned to the EC2 instance when created. The target group health checks continuously fail as Unhealthy for the EC2 instance though.

However, in the second template of the ASG in the Network Configuration section I set a public IP to be auto-assigned to the EC2 instance. Then the target group health checks pass no issue.

The public IP auto-assignment is the only difference between the two templates. When creating the ASG from the templates I am selecting the public subnets (meaning they route traffic to the IGW) of the VPC I am working with. I have also tried private subnets with the same issue. The VPC for the EC2 instances is the same as the application load balancer.

The security groups for the ALB and EC2 instances both allow all incoming traffic on port 80.

Since the load balancer and EC2 instances are in the same VPC I assumed the target group would be able to resolve the health checks without needing to assign a public IP to the EC2 instances.

I'm not understanding why it's required to have a public IP assigned to the EC2 instances.

Alex F
  • 2,086
  • 4
  • 29
  • 67
  • I imagine the load balancer is external, right? – Paolo Sep 22 '22 at 17:52
  • @Paolo that is correct. – Alex F Sep 22 '22 at 18:06
  • What is the Security Group configuration for the Outbound rules on the Load Balancer and the Inbound rules for the EC2 instances? – John Rotenstein Sep 23 '22 at 00:36
  • Outbound allows all traffic on all ports. Inbound for the EC2 instances allow all traffic on port 80. – Alex F Sep 23 '22 at 13:05
  • Have you ensured the target groups are in the same VPC as the EC2 instances? If not, AWS networking will require a public EC2 IP to establish connectivity for a health check. – Kunal Nagpal Sep 26 '22 at 12:20
  • @KunalNagpal yes the target groups are in the same VPC as the EC2 instances. – Alex F Sep 26 '22 at 12:35
  • Did you try to create an Elastic Ip ? – Sayf-Eddine Sep 27 '22 at 22:31
  • Can you verify if route tables associated with subnet(s) mentioned allow VPC ip to local traffic? I'm assuming the route table only has an IGW rule for 0.0.0.0 and no rules for vpc ip range (for ex: 10.0.0.0/16 -- local) – acsrujan Sep 29 '22 at 12:00
  • @acsrujan The route table is setup with an IGW for 0.0.0.0 like you said but also local traffic through the VPC subnet of 10.0.0.0/24. – Alex F Sep 29 '22 at 13:28
  • Would you mind sharing some details of the setup? From the information so far, it should work. There's most likely a small human/config error we'd be unable to spot without visibility. Least likelihood is if application or instance firewall has anything to block the private IP addresses. You can launch reachability analyser if we're sure of network to blame. – acsrujan Sep 30 '22 at 04:33
  • Can you share your template and possibly screenshots of route table, security group(s), and ASG configuration? – Ben Whaley Oct 01 '22 at 15:51

1 Answers1

2

I suspect the issue is that your launch template has userdata code that fetches artifacts from the internet for bootstrapping. Without a public ip assigned to it, the EC2 instance is not be able to bootstrap properly and as a result the web server does not start, resulting in a failed health check.

You should create an EC2 AMI so that your EC2 instances will no longer need to fetch artifacts from the internet upon boot. This way, they will always work regardless of the settings of the network interface associated to the instance.

Paolo
  • 21,270
  • 6
  • 38
  • 69