Issue with NLB pointing to ALB with target as EC2 instance

When you have an NLB in front of an ALB pointing to EC2 instances, a 502 error typically indicates that the ALB couldn't establish a successful connection with the target EC2 instance. This single 502 error could cause prolonged loading times for several reasons:

1. Connection pooling behavior: The ALB maintains a single back-end connection with each EC2 instance, regardless of how many clients are connecting through it. If this connection encounters an issue (resulting in a 502), the ALB may need to establish a new connection, which takes time.

2. Connection limits: Your EC2 instance or application server (like Tomcat) might have connection limits configured. If these limits are reached, new connection attempts will be refused, causing delays as the ALB attempts to establish new connections.

3. TCP connection management: When using an NLB with an ALB, the NLB must use a TCP listener (not TLS) when the target is an ALB. The ALB then handles the HTTPS termination. If there are any issues in this connection chain, it can cause delays.

4. Health check recovery: After a 502 error, the load balancer might temporarily mark the target as unhealthy, requiring successful health checks before routing traffic back to it, causing delays.

5. Connection timeouts: The ALB has idle timeout settings that determine how long a connection can remain inactive before being closed. If these settings aren't aligned with your application requirements, it could lead to premature connection closures and subsequent delays.

To resolve this issue:

• Check your EC2 instance's resource utilization during high traffic
• Review your application server's connection limits and timeout settings
• Ensure security groups allow proper traffic flow between all components
• Consider increasing the resources allocated to your EC2 instance
• Verify that health check settings are appropriate for your application
  Sources
  Using HTTPS with an NLB communicating securely via an ALB to the EC2 | AWS re:Post
  Does ALB maintains single back-end connection with each ec2 instance or different back-end connections for each client? | AWS re:Post
  Connection to NLB Timing Out | AWS re:Post

From what you described, that single 502 error from the ALB likely means your EC2 app either didn’t respond in time, crashed, or closed the connection unexpectedly. Even if it happened just once, it can create a cascading effect—especially if the backend service is overloaded or stuck. That’s probably why your site seemed to “hang” or load slowly after that.

Also worth noting: NLB doesn’t really “understand” if the ALB behind it is unhealthy—it just forwards packets. So if your NLB isn’t doing health checks, it might keep sending users to an ALB that’s routing traffic to a struggling EC2 instance. That can cause intermittent slowness or page hangs even after the first failure.

some notes:

Set up health checks at the NLB level pointing to the ALB (or a health endpoint). Checked EC2 logs to see if the app was crashing or running out of resources. Tuned ALB timeouts and deregistration delay, so bad instances were drained properly. Would recommend digging into CloudWatch metrics and the app logs to see what happened around the time of that 502—it’s usually just the symptom, not the root cause.