ALB: Path-Based, Host-Based, and Header Routing

An Application Load Balancer (ALB) operates at Layer 7 of the OSI model, meaning it can inspect the content of HTTP/HTTPS requests—specifically the host header, URL path, HTTP method, query strings, and custom headers. This allows the ALB to make routing decisions based on application-level data, not just network-level information like source IP and port. The exam tests your ability to differentiate ALB from Network Load Balancer (NLB) and Classic Load Balancer (CLB), and to choose the right routing type for given requirements.

Path-based routing directs requests to different target groups based on the URL path (e.g., /api/* vs. /images/*). Host-based routing uses the Host header (e.g., api.example.com vs. app.example.com). Header-based routing uses arbitrary custom headers (e.g., X-Client-Version: 2.0). These rules are evaluated in order of priority, and the first matching rule determines the target group. If no rule matches, the request is sent to the default target group (which you must configure).

When a client sends an HTTP/HTTPS request to the ALB's DNS name (e.g., myalb-1234567890.us-east-1.elb.amazonaws.com), the ALB terminates the TLS connection (if HTTPS) and then inspects the request. The ALB maintains a list of listeners (e.g., HTTP:80, HTTPS:443). Each listener has a set of rules. Each rule has: - Priority: A unique integer from 1 to 50000. Lower numbers are evaluated first. - Action: Typically forward to a target group, but can also be redirect, fixed-response, or authenticate (for Cognito or OIDC). - Conditions: One or more conditions that must be met. Conditions can be: - host-header: Matches the Host header against a list of hostnames (supports wildcards *.example.com). - path-pattern: Matches the URL path against a pattern (supports wildcards * and ?). - http-header: Matches a custom header name and value. - http-request-method: Matches HTTP methods like GET, POST. - query-string: Matches key-value pairs in the query string. - source-ip: Matches the client's IP address (requires a target group of type ip).

When a request arrives, the ALB evaluates rules in ascending priority order. If a rule's conditions all evaluate to true, the rule's action is executed, and no further rules are evaluated. If no rule matches, the default action (which has no conditions) is executed. The default action is always present and cannot be deleted, but you can modify its target group.

- Listener: Each ALB must have at least one listener. You can have up to 10 listeners per ALB (default limit, can be increased). - Rules: Up to 100 rules per listener (default). Each rule can have up to 5 conditions (except for source-ip which is limited to 1 condition per rule). - Conditions: - host-header: You can specify up to 5 hostnames per condition, each can include wildcards (*.example.com). Matching is case-insensitive. - path-pattern: Supports up to 5 patterns per condition. Patterns use glob-style matching: * matches any sequence of characters, ? matches any single character. Example: /api/* matches /api/users, /api/v1/items. Path matching is case-sensitive by default, but you can enable case-insensitive matching at the listener level. - http-header: You specify a header name (case-insensitive) and up to 5 values (case-sensitive). The condition matches if the request contains the header with one of the specified values. - Default action: Every listener has a default rule (priority default). You must set a default target group or action. If you don't, the ALB will return a 503 error. - Target groups: Each target group can contain EC2 instances, IP addresses, Lambda functions, or private IP addresses. Target groups can be of type instance, ip, or lambda. Health checks are configured per target group.

To create a listener with path-based rules using the AWS CLI:

aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/myalb/1234567890 --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/default-tg/1234567890

Then add a rule:

aws elbv2 create-rule --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/myalb/1234567890/1234567890 --priority 10 --conditions Field=path-pattern,Values=['/api/*'] --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/api-tg/0987654321

For host-based routing, the condition would be:

--conditions Field=host-header,Values=['api.example.com']

For header-based routing:

--conditions Field=http-header,HttpHeaderConfig={HttpHeaderName=X-Client-Version,Values=['2.0']}

You can also forward traffic to multiple target groups with weights. This is useful for canary deployments. For example, you can send 90% of traffic to the stable target group and 10% to the new version. This is configured using the forward action with TargetGroupStickinessConfig and ForwardConfig.

On the SAA-C03 exam, you will be asked to design architectures that separate traffic for different microservices, or to route users to different backends based on domain name or path. You must know when to use path-based vs. host-based routing and how to combine them. The exam also tests edge cases like overlapping patterns, default actions, and the difference between ALB and NLB for Layer 7 routing.

A SaaS company runs multiple microservices (users, orders, payments) behind a single ALB. Each microservice is deployed on its own Auto Scaling group and target group. The ALB listener on port 443 has rules: path /users/* forwards to the users target group, /orders/* to orders, /payments/* to payments. This allows the company to manage each service independently, scale them separately, and deploy updates without affecting others. In production, they also use host-based routing to separate staging and production: api.example.com for prod, api.staging.example.com for staging. They configure host-header conditions with wildcards like *.example.com to simplify. Common misconfiguration: overlapping path patterns (e.g., /users/* and /users/admin/*). If the more specific pattern has a higher priority number (lower priority), the broader pattern matches first, causing admin requests to go to the wrong target group. The fix is to assign lower priority numbers to more specific patterns.

A SaaS provider hosts multiple tenants, each with a custom domain (e.g., tenant1.app.com, tenant2.app.com). They use host-based routing to direct each tenant to their own target group. The ALB listener has rules: host-header = tenant1.app.com forwards to tenant1-tg, tenant2.app.com to tenant2-tg. A default rule sends unknown hosts to a landing page. They also use header-based routing to route based on API version: requests with X-API-Version: 2.0 go to a canary target group for testing. Performance consideration: ALB can handle tens of thousands of rules, but each rule adds latency. For hundreds of tenants, they use a wildcard rule (*.app.com) and then examine the host header at the application level to avoid rule explosion.

An e-commerce company uses weighted target groups to perform blue/green deployments. They create two target groups: blue-tg (stable) and green-tg (new version). A rule forwards traffic to both with weights 90 and 10. They monitor the green version, and if successful, gradually increase its weight to 100. This is done using the AWS CLI or SDK. Common pitfall: forgetting to enable stickiness for stateful applications. If a user's session is on the blue target and then a subsequent request goes to green, the session is lost. They enable stickiness on the target group (using the AWSALB cookie) to ensure session affinity during the transition.