Application Load Balancer — Advanced Routing & Target Groups

Recap: Where the Fleet Left Off

Foundations You'll Need Today

1. Why This Is on the Exam

The Application Load Balancer sits at the intersection of three SAP-C02 concerns that are otherwise handled by separate services: traffic distribution, deployment safety, and TLS termination. That overlap is exactly why it appears so often. A question about blue/green deployment could be answered with CodeDeploy, with Route 53 weighted records, or with ALB weighted target groups, and the exam expects you to know which of those three is appropriate given the constraint stated in the scenario. A question about routing /api to one service and /static to another could be answered with a reverse proxy on EC2, with CloudFront behaviors, or with ALB listener rules — and again the discriminator is usually operational overhead rather than raw capability.

The architectural problem ALB solves is that a fleet of interchangeable compute units needs a stable, highly available entry point that can make routing decisions at layer 7. A Network Load Balancer can distribute connections but cannot inspect an HTTP path or a header, so it cannot split traffic by URL. A Classic Load Balancer can do rudimentary layer-7 work but lacks target groups, host-based rules, and native Lambda targets. ALB exists in the gap: it terminates HTTP and HTTPS, evaluates a prioritized list of rules against each request, and forwards to a named target group whose membership and health are managed independently of the listener configuration. That separation — listener rules on one side, target group membership on the other — is the design decision that makes canary releases and blue/green cutovers possible without touching DNS.

On the exam blueprint this maps most directly to the resilient architectures domain, because the failure-handling story (health checks, cross-zone balancing, connection draining) is what keeps a multi-AZ application available. It also shows up in the migration and modernization domain whenever a scenario describes decomposing a monolith into path-routed services, and in the cost domain when the correct answer is to consolidate several small load balancers behind one ALB with multiple listener rules. Expect at least one question where the deciding factor is that ALB is the only load balancer type that supports a Lambda target or a weighted split within a single rule.

2. How a Request Actually Flows Through an ALB

An ALB is not a single appliance; it is a set of load balancer nodes that AWS provisions across the Availability Zones you enable, with at least one node per enabled zone. When you create an internet-facing ALB you get a DNS name, and that name resolves to the IP addresses of those nodes. Because the node set changes as AWS scales the load balancer, AWS recommends that you never resolve the ALB DNS name to IPs and pin them — always reference the DNS name, or put a Route 53 alias record in front of it. This is the first mechanism detail worth internalizing: the ALB's own availability is a function of how many zones you enabled, and enabling only one zone makes the load balancer itself a single point of failure regardless of how many targets you registered.

When a request arrives, the listener evaluates its rules in priority order, lowest number first, and stops at the first match. Each rule has a condition (host header, path pattern, HTTP header, query string, source IP, or HTTP method) and an action. The action is either a forward to one or more target groups with optional weights, a redirect, a fixed response, or an authenticate action against a Cognito or OIDC identity provider. If no rule matches, the listener's default action applies. This ordering matters operationally: a broad rule with a low priority number will shadow every more specific rule behind it, and that is one of the most common misconfigurations in production ALBs.

Once a target group is selected, the ALB picks a target using the group's routing algorithm. The default is round robin, and the alternative is least outstanding requests, which biases toward targets with fewer in-flight requests and tends to produce better tail latency when request durations vary widely. The ALB then opens or reuses a connection to the target on the port and protocol the target group specifies, and the target group's health check determines whether that target was eligible in the first place. Health checks run on their own interval and threshold settings, independent of request traffic, which means a target can be receiving requests and still be marked unhealthy by the next check — the two systems are related but not synchronized.

Two protocol details are worth holding onto. First, ALB supports HTTP/1.1, HTTP/2, and gRPC, and it can translate between them: a client speaking HTTP/2 to the ALB can be forwarded to a target speaking HTTP/1.1. Second, when you enable a target group for a Lambda function, the ALB invokes the function with an event payload describing the request and expects a structured response, which means the Lambda target path has no persistent connection and no health check in the traditional sense. That difference is why Lambda targets behave differently under load and why they are usually the wrong answer when a scenario emphasizes steady high-throughput connection reuse.

3. The Core Decision Boundary: Rule Conditions vs. Target Group Weights

Almost every ALB scenario question reduces to a single fork: is the routing decision based on a property of the request, or on a proportion you want to control? If the answer is a property of the request — the hostname, the path, a header, a query parameter — the mechanism is a listener rule condition, and the rule forwards to exactly one target group. If the answer is a proportion — send 10% of traffic to the new version, or split evenly between two identical services — the mechanism is a single rule that forwards to two target groups with weights. Confusing these two produces designs that technically work but are operationally wrong, such as creating two listener rules with identical conditions and hoping the ALB splits between them, which it will not do; it will match the first rule and ignore the second.

The second-order decision is where the split should live at all. Weighted target groups keep the split inside the load balancer, which means it is instant, requires no DNS propagation, and can be changed by an API call. Route 53 weighted records put the split in DNS, which means clients cache the answer for the record's TTL and the effective split drifts from the configured one until caches expire. For a canary that you intend to ramp from 1% to 100% over an hour, the ALB approach is strictly better. For a split between two entirely separate stacks in different regions, DNS is the only option because a single ALB cannot span regions.

The exam phrasing that signals the weighted-target-group answer is usually a stated desire to test a new version with a small, controllable, quickly reversible share of production traffic. The phrasing that signals a listener rule is usually a stated difference in the request itself — a path prefix, a subdomain, a mobile client sending a distinguishing header. When a scenario mentions both, the correct design is normally a listener rule that selects the target group pair, with weights applied inside that rule, so that only the canary's slice of the path-routed traffic is split.

4. Configuration Modes and Their Tradeoffs

The knobs on an ALB fall into four groups: scheme and zones, listener and rule configuration, target group settings, and attributes. The scheme decision is made once at creation and cannot be changed — an internet-facing ALB has public IPs on its nodes and an internal ALB does not. This is a genuine constraint rather than a preference, and it is why scenarios that describe a service that must be reachable only from inside a VPC and also from an on-premises network over Direct Connect point at an internal ALB with a private IP, not an internet-facing one with security group restrictions. The zone decision is also effectively permanent in the sense that enabling more zones later is easy but running with one zone is a design error you cannot patch around.

Listener configuration is where most of the operational flexibility lives. Each listener is bound to a port and protocol, and HTTPS listeners require an ACM certificate or an imported one. Rules within a listener are evaluated by priority, and the default action is the fallback. The tradeoff here is between rule count and rule clarity: you can express a great deal with a handful of well-ordered rules, but every additional rule is another chance to shadow a later one. A useful discipline is to reserve low priority numbers for the most specific conditions and let the default action handle the long tail, rather than writing an exhaustive set of rules that must all be kept in the right order.

Target group settings carry the health check configuration, the routing algorithm, the deregistration delay, and the stickiness settings. Deregistration delay is the one that most often surprises people: when a target is deregistered or fails a health check, the ALB stops sending new requests but keeps existing connections open for the configured delay, defaulting to 300 seconds, so that in-flight requests can finish. Setting it too high makes deployments slow because every removed target lingers; setting it too low causes 5xx errors during scale-in because requests are cut off mid-flight. This is the same drain concept that yesterday's Terminating:Wait lifecycle hook implements, and the two must be tuned together or one will undo the other.

Attributes are the least visible group and the most likely to be the hidden answer in a scenario. Cross-zone load balancing is on by default for ALBs and distributes requests evenly across all targets in all enabled zones rather than evenly across zones. Slow start gives a newly registered target a ramp-up period during which it receives a linearly increasing share of requests, which matters for JVM-based services that need to warm caches. Sticky sessions bind a client to a target using a cookie, which is sometimes necessary for stateful applications but undermines even distribution and complicates scale-in. Idle timeout controls how long an idle connection is held, and it must be shorter than the keep-alive timeout of the backend or the backend will close connections the ALB still believes are open.

5. Sizing, Limits and Quotas

ALB capacity is not something you provision. There is no instance size and no capacity unit to buy; AWS scales the load balancer's nodes in response to traffic, and the practical limits are expressed as quotas on configuration objects and as soft limits on new connections and requests per second that can be raised through a support request. This is a meaningful difference from an NLB, where you can attach Elastic IPs and reason about static addresses, and from a Gateway Load Balancer, which is built for a different purpose entirely. For exam purposes the important consequence is that "the load balancer is too small" is almost never the correct diagnosis; the bottleneck is nearly always the targets, the health check configuration, or a quota on a configuration object.

The quotas that actually constrain designs are the ones on rules and target groups. A listener supports a bounded number of rules, and each rule supports a bounded number of conditions and a bounded number of target groups in a forward action. Target groups have their own limits on registered targets, and each target group can be associated with a limited number of load balancers. Certificates are limited per load balancer, which matters when a scenario describes hosting hundreds of customer domains — the answer there is usually a wildcard certificate or SNI with a smaller set of certificates rather than one certificate per domain. These numbers change over time, so the exam-relevant skill is knowing which quota to check, not memorizing the current value.

Two sizing-adjacent behaviors are worth separating from quotas. First, the ALB's health check interval and thresholds determine how quickly a failing target is removed, and that detection latency is a real availability cost during an incident — a target that fails immediately after a check will keep receiving traffic until the next check plus the unhealthy threshold. Second, connection reuse means the ALB is not opening a new backend connection per request, so backend connection counts are governed by concurrency and keep-alive settings rather than by request rate. A scenario that describes exhausting a database's connection limit through an ALB is usually describing a target-side pooling problem, not a load balancer limit.

6. Failure Modes and What They Look Like in Production

The most common ALB failure signature is a burst of HTTP 502 responses. A 502 from an ALB means the load balancer could not get a valid response from the target, and the usual causes are a target that crashed mid-request, a target whose security group no longer permits traffic from the ALB, a target listening on a different port than the target group expects, or a target that is being deregistered while still receiving requests because the deregistration delay is too short. The first diagnostic move is to check target health in the target group and then check the target's own logs for the request that failed — the ALB access logs will show the request reaching the load balancer, and the absence of a corresponding application log entry localizes the problem to the network path or the process.

A 503 from an ALB almost always means there are no healthy targets. That is a different failure than 502 and points at the health check rather than the application. The classic version of this is a health check path that returns a redirect or requires authentication, so every target is marked unhealthy even though the application is serving real traffic fine. The second classic version is a health check that is too aggressive relative to the application's startup time, so targets are marked unhealthy during boot and never get the chance to become healthy. Both are configuration errors that produce a total outage from a working application, which is why the health check path deserves the same review as the application code.

Timeouts present as 504 responses and are the hardest of the three to diagnose because they can originate on either side. The ALB's idle timeout governs how long it will wait on an idle connection; if the backend takes longer than that to produce a response, the ALB closes the connection and the client sees a 504. The mirror-image problem is a backend keep-alive timeout shorter than the ALB's idle timeout, which causes the backend to close connections the ALB still considers usable, producing intermittent 502s that are maddening to reproduce. The standard fix is to set the ALB idle timeout slightly longer than the backend's keep-alive timeout so the backend is always the side that closes first.

Two subtler failure modes are worth naming. Uneven distribution across targets usually means sticky sessions are enabled, or that one target is in a different zone and cross-zone balancing is disabled, or that the routing algorithm is least-outstanding-requests and one target is genuinely slower. And a canary that appears to receive no traffic at all is usually a weight configuration error rather than a routing error — a weight of zero on the new target group, or a second listener rule with a lower priority number that matches first and forwards everything to the old target group. Both are configuration mistakes that look like application bugs from the outside.

7. The Operational and SRE Angle

From an SRE perspective the ALB is the single best place to measure the user-visible health of a service, because it sees every request before any application code does. The metrics that matter most are the target response time, the request count split by target group, the HTTP code counts broken out by 2xx, 3xx, 4xx, and 5xx, and the unhealthy host count. The 5xx count is the closest thing to a direct SLO signal available without instrumenting the application, and an alarm on the 5xx rate as a proportion of total requests is a reasonable default for any service behind an ALB. The unhealthy host count is the leading indicator: it moves before user-visible errors do, because the ALB removes targets from rotation before the error rate climbs.

Access logs are the other half of the observability story. ALB access logs record the request time, the target that handled it, the target and load balancer response codes separately, and the time spent in each phase of the request. That separation is what makes them more useful than application logs for latency work: you can tell whether time was spent waiting for the target to respond or in the connection setup, which distinguishes an application problem from a networking problem. Enabling access logs to S3 and querying them with Athena is a common pattern, and it is the mechanism behind most "which endpoint is slow" investigations.

The runbook shape for an ALB-fronted service has a predictable structure. First, check target health and the unhealthy host count to determine whether the problem is membership or performance. Second, check the 5xx breakdown to distinguish 502 (target unreachable or crashed) from 503 (no healthy targets) from 504 (timeout). Third, check whether a recent deployment changed the target group membership or the listener rules, because a rule ordering mistake produces symptoms that look exactly like an application routing bug. Fourth, check the deregistration delay and idle timeout against the backend's keep-alive settings, since a mismatch there produces intermittent errors that correlate with deployments and scale events rather than with load.

For deployment safety, the SRE-relevant property of weighted target groups is that the weight is an API-controlled number, which means a canary can be automated: shift 5%, watch the 5xx rate and target response time for a defined bake period, and either continue the ramp or set the weight back to zero. That rollback is a single API call with no DNS propagation delay and no client-side caching, which is why it is a better rollback mechanism than a DNS-based split. The corresponding discipline is to alarm on the canary target group's error rate separately from the stable group's, because a 5% canary with a 20% error rate only moves the aggregate error rate by one percentage point — invisible in the aggregate, obvious when measured per target group.

8. Edge Cases and Exam Gotchas

The single most-tested gotcha is that two listener rules with identical conditions do not split traffic. The ALB evaluates rules in priority order and stops at the first match, so the second rule is dead configuration. Any scenario that describes a percentage split must be answered with weights inside one rule, and any scenario that describes two rules with the same condition is describing a bug. A closely related trap is rule ordering: a rule matching /* with a low priority number will shadow a rule matching /api/* with a higher number, and the symptom is that the specific route appears to be ignored.

Security groups are the second recurring trap. An ALB has its own security group, and the targets have theirs; the target's security group must allow traffic from the ALB's security group on the target port. A scenario that describes targets that are healthy in the console but return 502s is often describing a security group that permits the client but not the load balancer. The related detail is that an internal ALB's nodes have private IPs from the subnet CIDR, so a target security group rule referencing the ALB's security group is more robust than one referencing a CIDR range that may change.

Health check configuration produces a cluster of gotchas. The health check port can differ from the traffic port, which is useful for a dedicated health endpoint but is also a common source of confusion. The health check protocol can be HTTP even when the traffic protocol is HTTPS, which is fine internally but must be deliberate. A health check that returns a 3xx is treated as unhealthy unless you configure the matcher to accept it, so an application that redirects unauthenticated requests to a login page will fail its health check by default. And a health check path that hits a database-backed endpoint turns a database slowdown into a total outage, because every target fails its check at once — the standard mitigation is a shallow health check that verifies the process is alive and a separate deep check that is not used for load balancer membership.

The remaining gotchas are about scope. An ALB is regional, so any scenario requiring a single endpoint across regions is describing Global Accelerator or Route 53, not an ALB. An ALB cannot do TCP or UDP passthrough, so a scenario about a non-HTTP protocol is describing an NLB. Lambda targets have no health check and no connection reuse, so a scenario emphasizing sustained throughput or long-lived connections is not a Lambda target scenario. And an ALB does not terminate traffic for a private service consumed across accounts — that is PrivateLink, which presents an NLB-backed endpoint service rather than an ALB.

9. ALB vs. NLB vs. CLB vs. CloudFront

The load balancer family splits along the layer at which the decision is made. An ALB makes decisions at layer 7 and therefore understands HTTP semantics; an NLB makes decisions at layer 4 and therefore understands connections and ports but not paths. A Classic Load Balancer is the legacy option that predates target groups and should not appear as the correct answer in a new design. CloudFront is not a load balancer at all but a CDN whose behaviors can perform some of the same routing work at the edge, which is why it sometimes appears as a distractor in routing questions.

The practical rule is to start from the protocol and the predicate. If the protocol is HTTP and the routing predicate is something in the request, the answer is an ALB. If the protocol is not HTTP, or the requirement is a static IP address, the answer is an NLB. If the requirement is a global entry point with caching, the answer is CloudFront in front of an ALB, and the two are complementary rather than alternatives — CloudFront terminates the client connection at the edge and forwards to the ALB, which then routes to targets. If the requirement is API management rather than traffic distribution, the answer is API Gateway, and the fact that API Gateway can also front a Lambda does not make it a substitute for an ALB in front of a container fleet.

One comparison that comes up specifically in migration scenarios is ALB versus a self-managed reverse proxy such as NGINX on EC2. The functional overlap is real, but the operational difference is that the ALB is a managed, multi-AZ, auto-scaled service with no patching, no capacity planning, and native integration with ACM, WAF, and Auto Scaling group lifecycle. A scenario that emphasizes reducing operational overhead while keeping path-based routing is pointing at the ALB, and a scenario that requires a custom module or a protocol the ALB does not support is the rare case where the self-managed proxy is correct.

Hands-on Lab: A Weighted Canary Behind One Listener Rule

Scenario Question Drills

Peek into Tomorrow

Sources