Hi ACP Admin,
From your post I understand that you are running your websites on EC2 instances behind an NLB. And in attempting to connect to this target via the NLB you are seeing inconsistent behavior when using different listeners on the NLB. You specifically mention not being able to connect after adding a listener that is using port 80. You also mention that you are using the NLB as follows "User (port/443) -> NLB (SSL offload) -> Auto SG -> EC2]". However it is not clear from your post whether you are able to connect when using this flow "User (port/443) -> NLB (SSL offload) -> Auto SG -> EC2]". You also inquire whether there is an alternative workaround other than having the instance keep getting terminated by Autoscaling. For troubleshooting issues on an NLB I recommend reviewing our documentation here. As the exact nature of your issue is not quite clear I also recommend the following steps to assist you in troubleshooting this issue.
- Check that Targets are passing the NLB healthchecks. If the targets are failing you can check the steps under a "A registered target is not in service" in the referenced documentation.
- Check the target's Security Group to confirm that the NLB IPs and Client IPs are allowed inbound to the Target Instance. Note: NLB does not have it's own security group and that it is only secured using the Security Group of the Target instance. Along with the security group you will also need to check the "Client IP Preservation" attribute of the NLB's Target group. If this setting is enabled then the Target instance sees the actual client IP connecting to it and not the NLB IPs. This would mean allowing both the NLB's IPs(for healthchecks) as well as the actual source client IPs in the targets Security Group. If "Client IP Preservation" is disabled then you only need to allow the load balancer IPs inbound to the target instance.
- Check the Route Tables associated with the NLB subnets. If the NLB is intended to be publicly accessible then the Route Table associated with the NLB subnets requires a default rout 0.0.0.0/0 pointing to an IGW.
- Check the NACLs associated with the NLB and Target subnets and ensure that the required traffic is being allowed inbound and outbound. With regards to an alternative to having Autoscaling keep terminating the instance, I recommend removing the Load Balancer from the Autoscaling group. Once it is detached you can launch your target instance behind the NLB and troubleshoot the connectivity issue with the different listeners. Once this issue is resolved you can then look into attaching the NLB to your Autoscaling group once again.
 Troubleshoot your Network Load Balancer https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html
 Detach a load balancer https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html#as-remove-load-balancer
Horizontal Scaling concerns, SSL issue with NLBasked 5 months ago
Load Balancer [NLB] - Listeners - Inconsistentasked 7 months ago
Internet facing NLBasked 8 months ago
AWS NLB security groupasked 9 months ago
API Gateway Private Integration with multiple NLB listenersAccepted Answerasked 3 years ago
Why can an instance in a target group not reach itself via NLB?Accepted Answerasked 2 years ago
using of NLB for HAasked 2 months ago
How to configure listeners for more than 50 ports in NLBasked a month ago
Is it possible to setup a NLB forwarding to ALB having NLB endpoint secured?asked 12 days ago
EKS NLB target groups protocol change to httpsAccepted Answerasked 22 days ago