NLB target group stuck in "Initial" health status with message "Target registration is in progress"

Thank you for this response.

I think I've checked off all of the above. The problem seems to be between the ALB target group and the ALB. I don't think the NLB is the issue here. I say this mainly because it's the target group that indicates that it's in an "Initial" health status. It's almost like the NLB is "doing nothing" because the target group isn't ready yet, but I can't see why the target group isn't able to reach the ALB.

Technically, it's the NLB that is registering the target. The target group is just a way to configure traffic routing for a load balancer, but by itself a target group doesn't do anything. For example, even though health checks are configured for the target group, they only get done when the target group is used by a load balancer, and the source IPs of the health checks will be those of that load balancer. The target registration of an ALB should be expected to get stuck at that stage when the NLB can't reach the ALB.

However, if you have already confirmed that network connectivity is properly set up and the target group is pointing to the port that the ALB is listening on, then if the ALB is an internet-facing one, you could try creating a temporary ALB of the internal type and pointing the NLB's target group to it. It might be that the public IPs of the existing ALB (if it has them) might confuse the NLB when stacked with the ALB.

Thanks so much, @Leo K. I have noticed that until the TG is attached to the NLB it seems to be doing nothing.

I guess my whole problem is that the state doesn't change to anything definitive. It doesn't flip to unhealthy or healthy ... it just remains indefinitely in that "Initial" state which isn't terribly helpful from a debugging perspective.

I have been trying various permutations of listeners in combinations of HTTPS and HTTP using both the internal port (application natively runs on port 3000) as well as the internet facing 443. I've even thrown port 80 in for good measure but the behavior is always the same.

I will try to create an internal ALB just to test your theory.

Thanks again!

So, I think I found my problem. I was trying to avoid provisioning an Elastic IP address for every availability zone, so I was trying to get things working using just 1 Elastic IP and 1 availability zone. That didn't go well.

When I enabled all 6 zones, things worked much better. The target group now lists itself as healthy, but now I'm uncertain of 2 things:

1. I don't seem to be able to find the static IP addresses associated with my NLB (I allowed AWS to assign the IPs during NLB creation).
2. I'm not sure, from a billing perspective, if allowing AWS to manage the IP addresses is any different than managing them myself.

Forgive my ignorance on these topics ... I know just enough to get myself into trouble. :D

I'm certainly no AWS guru.

Thanks in advance!