> ## Documentation Index > Fetch the complete documentation index at: https://docs.springwinter.dev/llms.txt > Use this file to discover all available pages before exploring further. # Application Load Balancer Internals: Rules, Targets, and Request Flow > Understand how AWS ALB processes requests through listeners, rules, target groups, health checks, TLS, WAF, stickiness, and CloudWatch. 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. | Action | Result | Typical use | | - | - | - | | Forward | Sends to target groups | Service routing and rollout | | Redirect | Returns an HTTP redirect | HTTP-to-HTTPS or canonical host | | Fixed response | Returns configured status and body | Maintenance or rejection | 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 Not as a general application contract. ALB routes at Layer 7 per request and maintains separate target connections. HTTP/2, WebSockets, stickiness, idle timeouts, and deregistration affect observed behavior, so design against documented request semantics. Yes. A gRPC target group can use path conditions corresponding to package, service, and method names. Use an HTTPS listener and forward actions, select the gRPC protocol version, and configure matching gRPC health checks. No. ALB health reflects configured target checks. A shallow check can pass while a dependency or operation fails. Combine target health with request errors, latency, logs, traces, and application service indicators. ## Sources and further reading * [ALB listeners](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html) * [ALB listener rules](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-rules.html) * [ALB target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html) * [ALB attributes](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#load-balancer-attributes) * [ALB CloudWatch metrics](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.