Long response time from ALB intermittently

From the information you shared a few things stand out:

• Your application logs show that the Express.js handler returns in < 1 second.
• However, the ALB Latency metric and access logs show about 21 seconds for the same requests, with HTTP 200 responses.
• Target group health is OK and the tasks are stable.
• In the ALB connection logs you see Failed:UnmappedConnectionError around the time when the 21-second responses occur.

This combination strongly suggests that the delay isn’t happening inside your ECS/Fargate task, but somewhere in the connection path (TLS negotiation or network) between the client and the ALB, or between the ALB and the target.

1. What UnmappedConnectionError means

In the ALB connection logs documentation, UnmappedConnectionError is described as an “unmapped runtime connection error”.

The AWS Knowledge Center article about SSL/TLS negotiation errors for Application Load Balancer goes further and explains that Failed:UnmappedConnectionError is logged when a TLS negotiation failure occurs in non-mTLS scenarios.

So this error code indicates that ALB saw a TLS/connection-level failure on that connection, but it is not a health check issue and not an application-level error from your Express service.

2. Confirm where the 21 seconds are spent

To stay precise and data-driven, you can use ALB access logs, connection logs, and CloudWatch metrics together:

• Check ALB access logs
  • Look at the fields:
    • time_taken – total time that ALB spent processing the request.
    • target_processing_time – time between when ALB sent the request to the target and when it received the first byte back (this corresponds to the CloudWatch metric TargetResponseTime).
  • If target_processing_time is < 1 second (matching your app logs), but time_taken is ~21 seconds, it means the delay happens before the request reaches the target or after the response leaves the target (for example, during connection establishment, TLS negotiation, network retries, or client-side behavior).
• Compare with CloudWatch metrics
  • Plot TargetResponseTime and Latency for the same period.
  • If TargetResponseTime remains normal but Latency spikes to ~21 seconds, that confirms the latency is outside of the target container.
• Correlate with connection logs
  • For the timestamps where you see high Latency, find the corresponding entries in connection logs (they are per connection, not per HTTP request).
  • If the connection log shows Failed:UnmappedConnectionError around the same time, that indicates a TLS/connection problem correlating with the high latency.

3. Things to verify (without guessing about the internal behavior)

Based on the official guidance for troubleshooting high latency on ALB and ECS, you can narrow this down by checking the following:

• Client ↔ ALB TLS negotiation
  • Confirm which security policy (TLS version and cipher suites) your ALB listener is using, and verify that your clients (browsers, SDKs, or any proxy in front) support that policy.
  • If there is an intermediate device (corporate proxy, WAF in front of ALB, etc.), check whether it is terminating TLS and then reconnecting to ALB, and whether it may be retrying handshakes, which could add extra seconds before a successful connection.
  • Use the TLS negotiation error KB as reference for systematically checking protocol/cipher mismatches or certificate issues.
• Network path between ALB and targets (IP mode target group), Even though your targets are healthy, intermittent network issues can still cause connection-level errors:
  • Verify security groups and network ACLs for both the ALB subnets and the IP targets to make sure there’s no intermittent deny/timeout scenario. The general ALB troubleshooting guide lists security groups/NACLs as a common cause when targets are slow to respond or fail health checks intermittently.
  • Make sure each subnet and Availability Zone used by the ALB has correct routing and that there is no unreachable subnet or misconfigured AZ which would cause connection attempts to time out before ALB falls back to a working path.
  • For IP-type target groups, double-check that you’re registering the correct IPs (and that there are no stale IPs that occasionally receive traffic but cannot respond).
• DNS resolution and client-side behavior
  • From the client side (or a test instance in the same Region), you can use curl with timing flags to measure DNS resolution, connect time, and TLS handshake time, as shown in the ALB/ECS latency troubleshooting guides.
  • If time_namelookup or time_connect or time_appconnect is high, that points at DNS or TLS negotiation as the bottleneck rather than your container.
• Idle timeout vs application keep-alive
  • Your ALB idle timeout (40 seconds) is lower than your Express keep-alive (60 seconds). This is the recommended direction: the backend should allow a slightly longer keep-alive than the load balancer’s idle timeout.
  • Because the observed delay (~21 seconds) is below 40 seconds, this specific problem is unlikely to be caused directly by the idle timeout setting.

4. Next steps

To move forward in a data-driven way (and keep the answer precise):

1. Confirm in your ALB access logs whether target_processing_time stays < 1 second during the 21-second time_taken.
2. Confirm in CloudWatch that TargetResponseTime is normal while Latency spikes.
3. Correlate those timestamps with connection logs to see whether the same connections have Failed:UnmappedConnectionError.
4. Based on what you see: If TLS handshake latency or TLS errors are involved, review the TLS policy, certificates, and any upstream proxies using the TLS negotiation error KB. If network-level delays are visible, review security groups/NACLs and subnet/AZ configuration as per the ALB/ECS latency troubleshooting guides.

If after these checks, TargetResponseTime is still consistently low while Latency remains high and you continue to see UnmappedConnectionError, I’d recommend opening an AWS Support case with:

• Recent ALB access log and connection log samples,
• CloudWatch metrics graphs (Latency, TargetResponseTime, RequestCount), and
• A curl timing output from a test client.

That will allow Support to correlate your specific connections with internal telemetry and identify the exact source of the 21-second delay.

Thank you.

Sources

ALB Access Logs Format https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

Target Group Attributes https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#target-group-attributes

Connection Idle Timeout https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#connection-idle-timeout

ECS Service Load Balancing https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html

Troubleshooting ALB https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

The intermittent 21-second delays you're experiencing with your Application Load Balancer (ALB) could be caused by several factors:

1. Connection idle timeout issues: While you've set the ALB keep-alive timeout to 40s and Express.js keep-alive to 60s, there might still be connection management issues. The "Failed UnmappedConnectionError" in your ALB connection logs suggests the ALB is having trouble mapping or maintaining connections properly.

2. Network ACL or Security Group restrictions: Your security groups or network ACLs might be restricting traffic between the ALB and your Fargate targets on the ephemeral ports (1024-65535). This could cause connection establishment delays.

3. Target connection issues: The ALB might be establishing a connection to your Fargate targets, but the targets might not be responding within the expected timeframe, causing the ALB to wait before timing out.

4. Content-length header mismatch: If your application is returning a content-length header that's larger than the actual entity body, the ALB might be waiting for the missing bytes, causing delays.

5. SSL handshake timeouts: If you're using HTTPS, there could be SSL handshake delays between the ALB and targets.

To troubleshoot:

• Check your security groups and network ACLs to ensure they allow traffic on ephemeral ports
• Monitor the HTTPCode_ELB_5XX and Latency metrics for patterns
• Enable access logs on the ALB to get more detailed information about the requests
• Verify your application isn't sending incorrect content-length headers
• Check if the issue occurs during periods of higher load, which might indicate capacity constraints

Since the issue is intermittent and your application logs show <1s responses, the delay is likely occurring between the ALB and your Fargate targets rather than within your application itself.
Sources
Troubleshoot a Classic Load Balancer: HTTP errors - Elastic Load Balancing
Troubleshoot your Application Load Balancers - Elastic Load Balancing