ALB Target Group Slow Start: Concurrent Latency Spikes During Target Warm-Up

Question

An Application Load Balancer target group with slow start enabled can exhibit elevated TargetResponseTime only when concurrent requests arrive shortly after targets are registered or transition from unhealthy to healthy. The latency often normalizes after the warm-up window, but CloudWatch metrics alone do not reliably separate the load balancer's intentional request ramp from actual target processing delays.

The core uncertainty is whether this concurrency-only latency reflects the documented slow start behavior—where the load balancer deliberately limits the request share sent to a target during warm-up—or a distinct backend constraint such as connection pool exhaustion or thread saturation that only surfaces under load. Slow start applies to initial target registration and healthy-state transitions, not to bursts against an already warm target group, and its attribute names and defaults can vary by region or console release.

When latency persists beyond the configured duration or appears on targets that have been healthy for an extended period, the root cause may lie outside the load balancer. Without correlating target health timestamps, slow start configuration, and request-level latency distributions, distinguishing between these layers remains difficult.

How can teams determine whether concurrent-only latency is caused by ALB slow start ramp versus backend saturation? What specific signals should be compared to make that distinction? Are there documented behavioral differences between ALB slow start and other load balancer types that affect this diagnosis?

Tasadduq Burney · Answer

Determine whether ALB slow start or backend saturation causes concurrent latency spikes
Compare TargetResponseTime spikes against TargetHealth transition timestamps and the configured slow_start_duration. Latency that begins when targets become healthy and ends within the slow-start window is most likely the ALB ramp. Latency that continues after targets have been healthy longer than that window indicates backend saturation or another target-layer constraint.
Confirmed behaviors

ALB slow start limits the request share sent to targets during initial registration or unhealthy-to-healthy transitions over a configurable duration, default 60 seconds.
Slow start does not apply to bursts against an already warm target group.
Backend saturation from connection pools, threads, CPU, or memory typically persists beyond the slow-start window and correlates with target-level resource metrics.

Verification steps

Retrieve the slow-start setting: aws elbv2 describe-target-group-attributes --target-group-arn <target-group-arn> --query 'Attributes[?AttributeKey==`slow_start_duration`].AttributeValue' --output text
Identify when each target moved to healthy using target health describe or CloudWatch events.
Overlay TargetResponseTime spikes on those timestamps; a short-lived increase aligned with the slow-start window suggests ramp-related latency.
Check target-level CPUUtilization, network, and active connections during and after the window; sustained pressure after warm-up indicates backend saturation.
Review ALB access logs to confirm request share to newly healthy targets grows gradually during the warm-up period.

If spikes appear only on targets that have been healthy for an extended period, slow start is not involved; investigate the backend directly. The one diagnostic detail that changes this recommendation is whether the latency spike outlasts the configured slow_start_duration.

ALB Target Group Slow Start: Concurrent Latency Spikes During Target Warm-Up

1 answer

Determine whether ALB slow start or backend saturation causes concurrent latency spikes

Confirmed behaviors

Verification steps

Your perspective belongs here.

0 question comments