The 20-second delay you're experiencing on the first request is occurring during the connection establishment phase, specifically between the "DNS lookup" (0.008 seconds) and "Connect" (21.122 seconds) stages. This indicates the delay is happening when establishing the TCP connection to your Application Load Balancer, not during DNS resolution.

This pattern - where the first request takes significantly longer but subsequent requests are fast - typically points to a few possible causes:

Connection establishment delay: The first request may be experiencing a delay in establishing the initial connection to the load balancer or from the load balancer to your EC2 target. Since subsequent requests are fast, this suggests connection reuse is working properly after the initial connection is established.

Target initialization: Your Tomcat application on the EC2 instance may need time to initialize or "warm up" on the first request. Even though the target group shows as healthy, the health check may be hitting a lightweight endpoint while your actual application endpoint requires more initialization.

Network path issues: There could be network connectivity issues in the path between the client and the load balancer, or between the load balancer and your EC2 instance. Since you mentioned SSL is terminated at the ALB and forwarded as HTTP on port 8080, check if there are any security group rules, network ACLs, or routing configurations that might be causing delays on initial connections.

To further troubleshoot, I recommend bypassing the load balancer and testing directly against your EC2 instance's private IP address from within the VPC. This will help isolate whether the issue is with the load balancer itself or with your application. Also, check CloudWatch metrics for your load balancer's TargetResponseTime to see if excessive values are being recorded during these first requests.
Sources
Troubleshoot latency on calls or requests to Amazon ECS tasks | AWS re:Post