skip to content

Elastic Load Balancing

4 roadmaps18 questions

The managed load-balancer family sitting in front of your compute: ALB at layer 7, NLB at layer 4, and the target groups and health checks both route through. Picking the right one and justifying the choice is a staple AWS design question.

part ofAWSoverview, primer and where to startread it →
on this pageshow

explore

questions

18

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?

level: juniorimportance: must knowfreq 70%

answer

  1. conditions on the request, ordered list
  2. priority number decides, not specificity
  3. first match wins, then default action
  4. AND across conditions, OR within one
  5. source-ip is the connection, not the header

basics

~20 s

An ALB listener rule matches on host header, URL path, HTTP header, HTTP method, query string, or source IP. Rules are evaluated in priority order, lowest number first; the first match wins, and unmatched requests fall through to the listener's default action.

solid answer

~40 s

Every ALB listener has a default action plus an ordered list of rules. Each rule carries a priority number and one or more conditions: `host-header`, `path-pattern`, `http-header`, `http-request-method`, `query-string`, or `source-ip`. Conditions inside one rule are ANDed - all must match - while several values inside a single condition are ORed. The ALB walks the rules from the lowest priority number upward and applies the **first** one that matches; there is no most-specific-wins logic, so ordering is the design. If nothing matches, the listener's default action runs. Actions are `forward` to one or more target groups (optionally weighted), `redirect`, `fixed-response`, `authenticate-oidc` or `authenticate-cognito`. Two gotchas: path patterns are case-sensitive and do not include the query string, and `source-ip` matches the address of the connection, not anything in `X-Forwarded-For`.

code

bash · 9 lines
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"

aws elbv2 describe-rules --listener-arn "$LISTENER_ARN" \
  --query 'Rules[].{Priority:Priority,Conditions:Conditions[].Field}'

go deeper

for a junior

Be able to list what a rule can match on - host, path, header, method, query string, source IP - and state plainly that rules are tried in priority order and the first match wins.

for a middle

Explain AND across conditions versus OR within one, why a broad rule at a low priority silently shadows narrower ones, and what the non-forward actions (redirect, fixed-response) are for.

for a senior

Demonstrate the operational angles: weighted forward actions for canaries, a fixed-response default that fails closed on unknown hosts, and why the source-ip condition is the wrong tool behind a CDN.

for a principal

Own the routing convention for the whole platform - host-based versus path-based, who may edit the rule table, and how you stay clear of the rules-per-load-balancer quota as service count grows.

## 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.

  • You add a rule for /admin/* but every admin request still lands on the main app. What do you check first?
    The priority numbers. A broader rule - often a catch-all `/*` - is sitting at a lower priority and matching first, because the ALB stops at the first match and never prefers the more specific pattern. Move the `/admin/*` rule to a lower number, or narrow the catch-all.
  • How would you send 5% of traffic to a new version without touching DNS?
    Use a single `forward` action listing both target groups with weights, for example 95 and 5. The ALB splits requests by weight, and you shift the weights as confidence grows. Enable target-group stickiness on that forward action if a user must stay on one version for their whole session.
  • Your ALB sits behind CloudFront and a source-ip rule meant to restrict an internal path matches nothing useful. Why?
    CloudFront terminates the client connection, so the address the ALB sees is a CloudFront node, not the end user. Match on the forwarded-client-address header instead, and make sure only the edge you trust can reach the ALB - otherwise a caller can set that header themselves.

saying these in an interview costs you the question

  • The ALB picks the most specific matching rule.
  • Path patterns include the query string.
  • Path matching is case-insensitive.
  • source-ip conditions read the X-Forwarded-For header.
  • A rule with no match falls through to the next rule instead of the default action.

context

resolving links…

open as a page

In AWS Elastic Load Balancing, what is a target group, and what happens to a registered target once it starts failing that target group's health check?

level: juniorimportance: must knowfreq 72%

basics

~20 s

A target group is the named set of backends an Elastic Load Balancing listener forwards to, plus the health check run against each member. A target that fails enough consecutive checks is marked unhealthy and stops receiving new requests.

open as a page

You are putting a public HTTPS API in front of a fleet of containers on AWS. When would you choose an Application Load Balancer (ALB) over a Network Load Balancer (NLB), and what can an ALB do that an NLB cannot?

level: middleimportance: must knowfreq 78%

basics

~20 s

Pick an ALB when the routing decision depends on the HTTP request itself - host, path, header or method - or when you want WAF, cookie stickiness or built-in OIDC login. Pick an NLB for raw TCP/UDP, static IPs and lowest latency.

open as a page

Your service must be reachable from outside its VPC. When would you put an AWS Network Load Balancer in front of it instead of an Application Load Balancer, and what do you give up by choosing NLB?

level: middleimportance: must knowfreq 78%

basics

~20 s

Network Load Balancer is the right choice when traffic is not HTTP, when you need a fixed IP per Availability Zone, or when you need very high connection volume at minimal added latency. You give up HTTP-aware routing, WAF and authentication actions.

open as a page

An Application Load Balancer is failing requests and every target in its target group shows unhealthy, yet curling the health-check path directly against a target from inside the VPC returns 200. How do you find the cause?

level: middleimportance: must knowfreq 66%

basics

~20 s

Read the reason code from describe-target-health first. Target.Timeout means the probe never arrived — usually the target's security group does not allow the health-check port from the load balancer. Target.ResponseCodeMismatch means it arrived but the status code fell outside the matcher.

open as a page

A partner will only send traffic to IP addresses on their firewall allowlist, but your endpoint currently sits behind an AWS Application Load Balancer. How does moving to a Network Load Balancer solve this, and exactly what would the partner allowlist?

level: juniorimportance: should knowfreq 52%

basics

~20 s

A Network Load Balancer gets one IP address per enabled subnet, and you can pin each to an Elastic IP you own at creation time. The partner allowlists those addresses — one per Availability Zone — instead of a DNS name.

open as a page

On an AWS Network Load Balancer, what is the difference between configuring a TLS listener and a plain TCP listener for an encrypted backend, and how do you decide between them?

level: middleimportance: should knowfreq 46%

basics

~20 s

A TLS listener makes the NLB terminate the handshake using an AWS Certificate Manager certificate and a security policy; a TCP listener passes the encrypted bytes through untouched so the target terminates. Choose termination for central certificate management, passthrough when the application must handle the handshake.

open as a page

An ELB target group is created with a target type of instance, ip, lambda or alb. What does each one register, and why must an ECS task running on Fargate use the ip type?

level: middleimportance: should knowfreq 55%

basics

~20 s

Target type fixes what you register: instance registers EC2 instance IDs, ip registers routable private addresses, lambda registers one function, and alb registers an Application Load Balancer behind a Network Load Balancer. Fargate tasks have their own ENI and no instance to register, so they need ip.

open as a page

An AWS Application Load Balancer HTTPS listener serves several domains, each with its own ACM certificate attached to the listener. Most clients work fine, but one older client always receives the certificate for a different domain and fails hostname verification. What is happening, and how do you fix it?

level: seniorimportance: should knowfreq 42%

basics

~20 s

That client is not sending the TLS SNI extension. An ALB selects among the certificates on an HTTPS listener by SNI, and falls back to the listener's default certificate when SNI is absent - so the client gets whichever domain is the default and hostname verification fails.

open as a page

How does client IP preservation on an AWS Network Load Balancer change what a registered target sees as the source address, and what two things does turning it on commonly break?

level: seniorimportance: should knowfreq 45%

basics

~20 s

With client IP preservation, an NLB forwards packets with the original client address intact, so targets see real client IPs rather than the load balancer's. That breaks security groups written for load balancer CIDRs, and same-VPC callers that are also registered targets.

open as a page

Every rolling deploy behind an Application Load Balancer produces a burst of 5xx responses and reset connections as old instances are replaced. Which target-group mechanism is supposed to prevent that, and how do you make it work?

level: seniorimportance: should knowfreq 52%

basics

~20 s

Connection draining, controlled by the target group attribute deregistration_delay.timeout_seconds. On deregistration the target enters the draining state and stops receiving new requests while in-flight ones finish. Errors usually mean the process is killed before draining completes, not that the delay is wrong.

open as a page

Your platform runs about forty services on AWS. Would you put them all behind one shared Application Load Balancer using host- and path-based rules, or give each service its own ALB? What drives the decision?

level: principalimportance: should knowfreq 30%

basics

~20 s

Neither extreme. Group services into a handful of ALBs along boundaries that already exist - public versus internal, team or account ownership, and traffic profile - because a shared load balancer saves money but shares quotas, load-balancer-wide settings, blast radius and change control.

open as a page

Should the endpoint an ALB target group health-checks verify the service's downstream dependencies, such as its database or cache? Argue the tradeoff and say what you would standardise on.

level: principalimportance: should knowfreq 35%

basics

~20 s

Generally no. A dependency check makes every target fail at the same instant when that dependency blips, turning a partial outage into a total one and potentially triggering fleet-wide instance replacement. Keep the load-balancer check shallow and expose dependency status on a separate endpoint for alarms.

open as a page

What does cross-zone load balancing do in Elastic Load Balancing, and how does its default differ between an Application Load Balancer and a Network Load Balancer?

level: middleimportance: nice to knowfreq 40%

basics

~20 s

Cross-zone load balancing lets each load balancer node send traffic to targets in every enabled Availability Zone, not just its own. It is on for an Application Load Balancer and off by default for a Network Load Balancer, where enabling it also incurs inter-AZ data transfer charges.

open as a page

An AWS Application Load Balancer listener rule uses the authenticate-oidc action to log users in before traffic reaches your service. What does the ALB do with an unauthenticated request, what does your application receive once the user is signed in, and what must the application still verify itself?

level: seniorimportance: nice to knowfreq 30%

basics

~20 s

The ALB runs the OIDC redirect flow itself, sets a session cookie, and then forwards the request with x-amzn-oidc-identity, x-amzn-oidc-accesstoken and a signed x-amzn-oidc-data JWT. The application must verify that JWT's signature and make sure targets cannot be reached without going through the ALB.

open as a page

Your organisation must send all VPC traffic through a fleet of third-party firewall appliances that need to inspect the original, unmodified packets. Why is an AWS Gateway Load Balancer the right component here rather than a Network Load Balancer?

level: seniorimportance: nice to knowfreq 25%

basics

~20 s

Gateway Load Balancer is transparent: it is inserted as a route-table target and encapsulates the original packet in GENEVE to the appliance fleet, preserving the true source and destination. A Network Load Balancer is an endpoint clients must address directly, so it cannot sit invisibly in the path.

open as a page

A long-lived TCP connection that passes through an AWS Network Load Balancer — a pooled database session or a streaming RPC channel — dies after a few minutes of inactivity, while short request/response traffic to the same endpoint is fine. What is happening, and how do you fix it?

level: seniorimportance: nice to knowfreq 35%

basics

~20 s

The load balancer expires idle flows: an NLB drops a TCP flow with no traffic for the idle timeout, which defaults to 350 seconds. Keep the connection warm with TCP keepalives or application-level heartbeats set well below that interval.

open as a page