On an AWS Application Load Balancer, what can a listener rule match on, and how does the load balancer decide which rule applies to a given request?

## The shape of a listener An Application Load Balancer has one or more listeners, each bound to a port and protocol. A listener always has a **default action** - what happens when no rule matches - and may have any number of **rules** layered on top of it. This is the entire routing model: there is no separate route table, no server blocks, no virtual-host config. Everything about which service receives a request is expressed as rules on a listener. ## Conditions A rule has between one and several conditions, and the ALB supports exactly these condition fields: - `host-header` - the value of the HTTP `Host` header (or the `:authority` pseudo-header on HTTP/2). Wildcards are allowed, so `*.example.com` works. - `path-pattern` - the URL path only. `/api/*` matches `/api/users`; it does **not** see `?page=2`, and matching is case-sensitive, so `/API/users` will not match `/api/*`. - `http-header` - any named request header and a list of values to match, which is how you route on a custom header such as a client or tenant identifier. - `http-request-method` - `GET`, `POST`, and so on, so you can send writes somewhere different from reads. - `query-string` - key/value pairs from the query. - `source-ip` - the source address of the connection, given in CIDR form. Within one rule, all conditions must be satisfied - they are ANDed. Within one condition, the listed values are alternatives - they are ORed. So a single rule can say "host is `api.example.com` **and** path starts with `/v2/`", but expressing "path `/a/*` **or** path `/b/*` routed to different groups" needs two rules. ## Evaluation order Each rule has a numeric priority. The load balancer evaluates rules in ascending priority order and stops at the first rule whose conditions all match. There is no longest-prefix or most-specific tiebreak, which is the single most common surprise: if a broad rule such as `path-pattern: /*` sits at priority 10 and a narrow one such as `/admin/*` sits at priority 20, the narrow one is dead code and every admin request goes wherever the broad rule pointed. Order rules from most specific to least specific, and leave gaps between priority numbers so you can insert a rule later without renumbering. If no rule matches, the listener's default action runs. A common pattern is to make the default a `fixed-response` returning 404, so an unknown host cannot accidentally land on whichever service happens to be first. ## Actions - `forward` sends the request to a target group; the forward action can also list several target groups with weights, which is how blue/green and canary shifting is done at the load balancer. - `redirect` answers the request itself with a 301 or 302 and can substitute pieces of the original URL, which is how the port-80 listener sends everyone to HTTPS without any backend. - `fixed-response` returns a status code, content type and short body straight from the load balancer - a maintenance page or a cheap rejection. - `authenticate-oidc` / `authenticate-cognito` run a login flow before the request is forwarded; when present they must come first in the rule's action list, with the forward last. ## The source-IP trap The `source-ip` condition matches the address the load balancer sees on the connection. If your ALB sits behind CloudFront or any other proxy, that address belongs to the proxy, not the end user, and a rule intended to allow only the office network will either match nothing or match everyone. The correct instrument in that topology is an `http-header` condition on the forwarded-client-address header - with the understanding that a header can be forged unless the edge in front of you is trusted and overwrites it. ## Quotas shape the design Rules per load balancer are capped by a service quota (adjustable through Service Quotas, but not unlimited), and rule evaluations are one of the billing dimensions of an ALB's capacity units. A design that gives every microservice fifteen path rules on one shared listener will meet that ceiling; grouping by host header, with one rule per service, scales much further. ```bash aws elbv2 create-rule \ --listener-arn "$LISTENER_ARN" \ --priority 20 \ --conditions Field=host-header,Values='api.example.com' \ Field=path-pattern,Values='/v2/*' \ --actions Type=forward,TargetGroupArn="$TG_ARN" ``` Both conditions must hold for this rule to fire, and any request that matches a rule with a priority below 20 never reaches it.