Why ALB executes healhcheck URLs with connection close request header? Can't we allow it to use HTTP/2?

The Application Load Balancer (ALB) executes health check URLs with the "Connection: close" header and uses HTTP/1.1 for a few important reasons:

1. Health checks are designed to be independent and stateless. By using "Connection: close", the ALB ensures that each health check request is a separate connection, which helps in accurately assessing the target's health without relying on persistent connections.

2. While HTTP/2 is supported for client-to-ALB communication, health checks are typically performed using HTTP/1.1. This is because health checks are meant to be simple and consistent across different target types and configurations.

Regarding your specific setup:

1. The health check frequency of 6 times per minute is normal and configurable. You can adjust the health check interval in the target group settings if needed.

2. The connection failures you're experiencing (2-3 out of 15 requests) are likely not related to the health checks. Instead, they may be caused by the interaction between your application, the ALB, and the client. The premature connection closures could be due to mismatched timeout settings or how your application handles connections.

3. Your timeout settings (70 seconds on ALB, 120 seconds on ECS) seem appropriate. However, you might want to investigate if your application is closing connections prematurely or if there are any network issues between the ALB and your ECS tasks.

As for why the ALB removes the Connection header:

The ALB manages connections between clients and targets independently. It terminates the incoming connection from the client and creates a new connection to the target. This allows the ALB to perform its load balancing functions effectively. When the ALB forwards requests to your application, it typically doesn't include the original Connection header to maintain this separation.

To troubleshoot your issues:

1. Review your application logs to see if there are any errors related to connection handling.
2. Consider using AWS X-Ray or other tracing tools to identify where exactly the connection failures are occurring.
3. Ensure your application is correctly configured to handle the connection management done by the ALB.
4. If the issues persist, you may want to contact AWS support for more detailed investigation.

Remember that while HTTP/2 is supported between clients and the ALB, the communication between the ALB and your targets (ECS tasks) typically uses HTTP/1.1, which is why you see this protocol in your health checks.
Sources
Is it possible for alb listener to support both http2 and http1.1 ? | AWS re:Post
Health checks for Application Load Balancer target groups - Elastic Load Balancing
How Elastic Load Balancing works - Elastic Load Balancing