Application Load Balancer Internals: Rules, Targets, and Request Flow

An Application Load Balancer accepts HTTP or HTTPS connections, evaluates each request against ordered listener rules, and forwards matching requests to healthy targets in a target group. Updated October 9, 2026. ALB makes Layer 7 routing decisions per request and maintains separate target-side connections.

​

The request path

1. The client resolves the ALB DNS name.
2. A load balancer node accepts the request on an HTTP or HTTPS listener.
3. An HTTPS listener negotiates TLS using its certificate and security policy.
4. Associated AWS WAF rules evaluate supported HTTP traffic.
5. Listener rules run in priority order until one matches.
6. Optional authentication or rewrites run before a terminal action.
7. A forward action chooses a target group and healthy target.
8. ALB sends the request over the target group’s protocol and port.

ALB adds or updates documented forwarding headers such as X-Forwarded-For according to configured attributes.

​

Listeners and rules

A listener defines the front-end protocol and port. Each non-default rule has a priority, conditions, optional transforms, and actions. Conditions can inspect host, path, method, headers, query strings, and source IP. Rules are routing configuration, not application authorization. A host or path match does not establish user identity or replace backend permission checks.

​

Target groups and health

Target groups contain instances, IP addresses, or Lambda functions. For instance and IP targets, they define protocol, port, protocol version, health checks, deregistration, algorithm, and optional stickiness. Health checks should prove a target can safely receive traffic without expensive work. During deregistration, connection draining gives in-flight requests time to finish. A target becomes routable only after meeting its target group’s health thresholds.

​

HTTP/2, gRPC, and connection behavior

ALB accepts HTTP/1.x and HTTP/2 on HTTPS listeners and supports WebSocket upgrades. Target groups can send HTTP/1.1, HTTP/2, or gRPC where documented. For gRPC, ALB supports unary and streaming calls, method-path routing, and gRPC health checks. HTTP/2 and gRPC target groups support forward actions. Idle timeout and HTTP client keepalive duration are different attributes. Tune them against clients, proxies, and servers rather than assuming one setting controls every connection lifetime.

​

Stickiness and cross-zone routing

ALB offers generated-cookie and application-cookie stickiness for supported groups. Stickiness can preserve server-local sessions but creates uneven load and complicates recovery. Shared session state is usually more resilient. Cross-zone load balancing is enabled by default at the ALB level. Target groups can override behavior under documented restrictions. Stickiness changes request distribution but does not make server-local session state durable.

​

TLS, WAF, and network controls

An HTTPS listener terminates TLS using ACM or IAM certificates. Its security policy determines supported protocols and ciphers. ALB can use HTTP or HTTPS to targets. AWS WAF evaluates HTTP requests with managed or custom rules. Security groups separately control listener traffic and ALB-to-target traffic. Where possible, target groups should accept traffic only from the ALB security group.

​

Metrics that explain behavior

Start with RequestCount, TargetResponseTime, load-balancer and target 5xx counts, HealthyHostCount, and UnHealthyHostCount. Add rejected connections, connection errors, rule evaluations, processed bytes, TLS errors, and consumed LCUs. Access logs provide request evidence; metrics provide aggregates; application traces explain backend work.

​

Frequently asked questions

​

Sources and further reading

• ALB listeners
• ALB listener rules
• ALB target groups
• ALB attributes
• ALB CloudWatch metrics