Listener Rules and Path-Based Routing

An ALB listener is a process that checks for connection requests using a protocol and port you specify (e.g., HTTP on port 80 or HTTPS on port 443). Each listener has one or more rules that determine where to forward requests based on their content.

A listener must have a default rule (the catch-all action when no other rule matches) and can have up to 100 additional rules. Rules are evaluated in priority order (lowest number = highest priority). When a request matches a rule's condition, the corresponding action is applied and no further rules are evaluated.

Listener rules match requests based on conditions. You can combine multiple conditions in one rule (all conditions must match for the rule to apply). Available condition types:

• host-header: matches the Host HTTP header (e.g., api.example.com)
• path-pattern: matches the URL path (e.g., /api/*, /images/*.jpg)
• http-header: matches any HTTP header name and value pattern
• http-request-method: matches HTTP methods (GET, POST, DELETE, etc.)
• query-string: matches key-value pairs in the query string
• source-ip: matches client IP CIDR ranges

Path-based routing directs requests to different target groups based on the URL path. This is the most common routing pattern for microservices behind a single ALB. Example rules on one ALB:

• Path is /api/* → Target Group: api-service
• Path is /images/* → Target Group: image-processor
• Path is /admin/* → Target Group: admin-app
• Default → Target Group: frontend-app

This allows a single ALB to front multiple distinct services without requiring multiple load balancers, reducing cost and DNS complexity.

Host-based routing routes requests based on the HTTP Host header, enabling multiple domain names (virtual hosts) to be served from a single ALB. Example:

• Host is api.example.com → api-service target group
• Host is admin.example.com → admin-app target group
• Host is www.example.com → frontend target group

Each domain name has its CNAME or ALIAS record pointing to the same ALB DNS name, but the ALB routes each to the appropriate backend based on the host header. Host-based routing is ideal for multi-tenant SaaS or monolithic apps being split into microservices.

When a rule's conditions match, the ALB executes one of these actions:

• forward: forward the request to one or more target groups (with optional weights)
• redirect: return an HTTP redirect (301 or 302) to a new URL; useful for HTTP to HTTPS redirects
• fixed-response: return a static HTTP response with a specified status code, content type, and body—useful for maintenance pages or simple health check responses
• authenticate-cognito: authenticate users via a Cognito User Pool before forwarding
• authenticate-oidc: authenticate users via any OIDC-compatible identity provider

The most common listener rule pattern is redirecting HTTP to HTTPS:

1. Create an HTTP listener on port 80 with one rule: redirect all traffic (/*) to HTTPS with a 301 status code
2. Create an HTTPS listener on port 443 with your actual routing rules pointing to target groups

This ensures users who type http:// or follow old HTTP links are transparently redirected to HTTPS without any application-level changes. The redirect is handled entirely at the load balancer layer.

The fixed-response action returns a static HTTP response from the ALB without forwarding the request to any target. Use it for:

• Returning a 503 maintenance page for specific paths during maintenance
• Providing a lightweight health check endpoint directly from the ALB (returns 200 OK instantly without backend overhead)
• Blocking specific paths with a 403 Forbidden response

Fixed responses are useful for temporarily taking paths out of service without modifying application code or redeploying, by adjusting listener rules dynamically.

The ALB's authenticate-cognito action integrates with Amazon Cognito User Pools to handle user authentication before forwarding requests to your application. When an unauthenticated user reaches a protected listener rule, the ALB redirects them to the Cognito-hosted UI for login. After successful authentication, the ALB sets an encrypted cookie and forwards the request with user identity headers.

This offloads authentication logic entirely from your application. Your backend receives X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data, and X-Amzn-Oidc-Access-Token headers with the authenticated user's claims.

ALB listener rules can route based on query string parameters and HTTP headers, enabling fine-grained request routing:

• Route mobile clients by detecting User-Agent: *Mobile* header to a mobile-optimised backend
• Route premium API requests by checking a custom X-API-Tier: premium header to a faster target group
• Route A/B test variants by reading a query string parameter ?variant=beta

Header-based routing allows you to implement feature flags and traffic splitting at the infrastructure layer without modifying application code.

Rules are evaluated in ascending priority order. Lower priority numbers are evaluated first. The first matching rule's action is applied and no further rules are evaluated. The default rule has no priority number and is always evaluated last as the catch-all.

Best practice: assign priority numbers in increments of 10 (10, 20, 30...) rather than sequential integers. This leaves room to insert new rules between existing ones without renumbering. More specific rules (e.g., path + host header) should have lower numbers (higher priority) than generic rules.

A single ALB can front an entire microservices platform using listener rules. A real-world example with all three condition types combined:

• Priority 10: Host=api.example.com + Path=/v2/* → api-v2 target group
• Priority 20: Host=api.example.com + Path=/v1/* → api-v1 target group
• Priority 30: Host=auth.example.com → auth-service target group
• Priority 40: Host=www.example.com + Path=/static/* → CloudFront redirect
• Default: Host=www.example.com → frontend target group

This design reduces costs by eliminating the need for separate load balancers per service.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: listener rules route requests based on host, path, headers, methods, and query strings, rules are evaluated in priority order with the first match winning, and actions include forward, redirect, fixed-response, and Cognito authentication. Path and host-based routing enable a single ALB to front multiple microservices. Next up we explore SSL termination and sticky sessions.