AWS Elastic Load Balancing, In Depth: ALB, NLB, GWLB & Target Groups

In a nutshell

Picture the single front door of a busy restaurant. Every guest arrives at one address, a host greets them there, and the host decides which of the many waiters and tables to send each guest to — quietly skipping any waiter who’s on a break. Guests never need to know which staff came or went; the door stays the same. A load balancer is that host for your application: clients reach one stable DNS name, and behind it the balancer spreads every request across a fleet of backends, steps around the ones that are unhealthy, and hides all the churn of instances scaling in and out.

AWS gives you three modern hosts for three different jobs. An ALB (Application Load Balancer) is the host who reads your reservation — it looks inside each HTTP request (the URL, the hostname, the headers) and routes accordingly, so /api goes to one kitchen and /images to another. An NLB (Network Load Balancer) is a turnstile: it doesn’t read anything, it just waves connections through at enormous speed and can keep the exact same street address (a static IP) forever. A GWLB (Gateway Load Balancer) is the host who walks every guest past a security checkpoint first, feeding traffic through firewall appliances before it reaches you.

Get the choice and the health checks right and your app is highly available and scales itself; get them wrong and you meet the 3-a.m. 503 page. This lesson is the exhaustive tour — read the analogy above, then everything below fills in every knob.

Level: Intermediate · Time: ~50 min · Full prerequisites and outcomes are in the two sections just below.

Almost nothing you build on AWS talks to the internet directly. In front of your EC2 instances, your containers, your Lambda functions, and even your on-prem servers sits a load balancer — the single, stable front door that takes incoming connections and spreads them across a fleet of backends, hides individual instance failures, terminates TLS, and gives you one DNS name that survives every scale-out, deploy, and instance replacement underneath it. Get it right and your application is highly available, horizontally scalable, and secure by default. Get it wrong and you discover, usually at 3 a.m., that health checks were failing silently, that cross-zone traffic was lop-sided, that sticky sessions pinned everyone to one dying instance, or that you paid for a Network Load Balancer when you needed Layer-7 path routing.

Elastic Load Balancing (ELB) is the AWS service that gives you four flavours of load balancer for four different jobs: the Application Load Balancer (ALB) for HTTP/HTTPS and content-based routing at Layer 7; the Network Load Balancer (NLB) for raw TCP/UDP throughput and ultra-low latency at Layer 4; the Gateway Load Balancer (GWLB) for inserting third-party security appliances transparently at Layer 3; and the Classic Load Balancer (CLB), the original, now legacy and slated for retirement. This is the exhaustive lesson. We go through the whole family — the comparison that decides which one you pick, then listeners and routing rules, target groups in every shape (instance, IP, Lambda, ALB-as-target), health checks down to the field, deregistration delay, the three stickiness modes, slow start, cross-zone load balancing and its billing twist, TLS termination with SNI and mutual TLS, access logs, and the security-group model that differs between ALB and NLB — until you can whiteboard an AWS load-balancing design from memory and answer every follow-up the SAA and Advanced Networking exams will throw at you.

Learning objectives

• Choose the right load balancer — ALB, NLB, GWLB, or (never again) CLB — from the OSI layer, protocol, and feature requirements, and justify the choice in an interview.
• Configure listeners and rules on an ALB: host-based, path-based, header, query-string, source-IP and HTTP-method conditions; redirect, fixed-response, forward, weighted forward, and authenticate actions.
• Build target groups of every target type (instance, IP, Lambda, ALB) and tune health checks, deregistration delay, stickiness, and slow start field by field.
• Reason correctly about cross-zone load balancing — the default per load-balancer type, the traffic distribution it produces, and the inter-AZ data-transfer cost it can incur.
• Implement TLS termination with SNI for many certificates on one listener, configure security policies, and stand up mutual TLS (mTLS) on an ALB.
• Apply the correct security model — security groups on ALB/GWLB, the NLB’s special behaviour and preserve_client_ip — and turn on access logs for audit and troubleshooting.

Prerequisites & where this fits

You need an AWS account, the AWS CLI configured (see AWS Hands-On First Steps), and a working mental model of a VPC — subnets across Availability Zones, route tables, and security groups vs NACLs. If those are shaky, read Amazon VPC, In Depth and AWS Security Groups vs Network ACLs, In Depth first — this lesson assumes you know what a subnet and a security group are and goes deep on every load-balancer knob. This is the Networking deep-dive of the AWS Zero-to-Hero course, the layer that sits between your VPC and your compute. It pairs naturally with EC2 Auto Scaling (a load balancer’s target group is what an Auto Scaling group registers into) and with Route 53, which puts a friendly name in front of the load balancer’s own DNS name — the next lesson, Amazon Route 53, In Depth, covers that.

Core concepts

A load balancer accepts incoming connections on one side and distributes them across a pool of targets on the other, so that no single backend is a bottleneck or a single point of failure. The AWS implementation is a fully managed, horizontally scaling fleet of nodes that AWS runs for you — you never see or patch the underlying instances; you just get a DNS name and an endpoint that scales with load.

Anchor everything that follows on these mental models:

• The load balancer is a fleet, addressed by DNS — never by IP. When you create an ELB, AWS places one or more nodes in each subnet you select (one per Availability Zone). The endpoint you get is a DNS name (e.g. my-alb-123456.eu-west-1.elb.amazonaws.com) that resolves to the nodes’ IP addresses, and that set of IPs changes over time as AWS scales and heals the fleet. You always point clients (or Route 53 alias records) at the DNS name, never at a resolved IP. (The one exception: an NLB can be given static Elastic IPs — more on that later.)
• Layers decide the family. ELB maps to the OSI model. ALB operates at Layer 7 (the application layer) — it understands HTTP, sees URLs, headers, cookies, and methods, and routes on them. NLB operates at Layer 4 (transport) — it sees TCP/UDP and ports, not content, and is brutally fast. GWLB operates at Layer 3 (network) — it transparently steers IP packets to and from inspection appliances. Which layer your requirement lives at picks your load balancer.
• Listener → rules → target group → targets. A listener checks for connections on a protocol and port (e.g. HTTPS:443). On an ALB it evaluates rules in priority order; each rule has conditions (match on host, path, header…) and actions (forward to a target group, redirect, return a fixed response…). The chosen action sends the request to a target group, which is a set of registered targets (instances, IPs, a Lambda function, or another ALB) plus the health check that decides which targets are eligible.
• Health checks are the whole game. A load balancer only sends traffic to healthy targets. The health check — its protocol, path, codes, thresholds, and timing — is what defines “healthy”. Most production load-balancer incidents are health-check misconfigurations: a check that’s too strict flaps targets in and out; one that’s too loose sends users to broken instances.
• AZs and cross-zone. A load balancer node lives in one AZ. Cross-zone load balancing controls whether a node may send traffic to targets in other AZs or only its own. This one toggle changes both your traffic distribution and, sometimes, your bill.

Key terms you’ll see throughout: target group (the pool of backends + health check), listener (protocol/port the LB accepts on), rule (ALB condition→action), deregistration delay / connection draining (the grace period before a removed target stops receiving traffic), stickiness / session affinity (pinning a client to one target), SNI (Server Name Indication — multiple TLS certificates on one listener), mTLS (mutual TLS — the client also presents a certificate), and cross-zone load balancing (whether nodes spread traffic across AZs).

The ELB family: ALB vs NLB vs GWLB vs CLB

Four load balancers, four jobs. Three of them — ALB, NLB, GWLB — share a modern code base and are collectively the v2 / “Elastic Load Balancing v2” generation built on the target-group model. The CLB is the v1 original, predating target groups, and AWS has announced its retirement; treat it as legacy only.

The decision in one breath: HTTP/HTTPS with any content-based routing → ALB. Raw TCP/UDP, static IPs, extreme performance, or fronting a PrivateLink service → NLB. Inserting third-party security appliances inline → GWLB. New workload → never CLB. The “when each” section at the end works through the edge cases.

Application Load Balancer (ALB) — Layer 7

The ALB speaks HTTP. It terminates the connection, parses the request, and routes on anything in the request: the Host header, the URL path, arbitrary headers, query strings, the HTTP method, even the source IP. That intelligence is why it’s the default for web applications and microservices — one ALB can route /api/* to one service, /static/* to another, admin.example.com to a third, all from a single listener. It supports HTTP/1.1, HTTP/2, gRPC, and WebSockets, integrates with AWS WAF for L7 protection, and can authenticate users via OIDC or Amazon Cognito before the request ever reaches your code. Because it operates at L7, it does not preserve the client’s source IP at the TCP layer — your application reads the original client address from the X-Forwarded-For header instead. It always uses a DNS name (no static IP) and always has a security group.

Network Load Balancer (NLB) — Layer 4

The NLB doesn’t read your traffic — it forwards flows. It hashes the connection’s 5-tuple (source IP, source port, destination IP, destination port, protocol) to pick a target and sends the packets on, which makes it astonishingly fast: millions of requests per second, single-digit-millisecond (often sub-millisecond) latency, and the ability to scale to sudden, spiky traffic without pre-warming. It’s the only ELB that can have a static Elastic IP per AZ — essential when clients need to allowlist your IPs by firewall rule. It preserves the client source IP by default for instance and IP targets, handles TCP, UDP, TCP_UDP, and TLS listeners, and is the load balancer you put behind an AWS PrivateLink endpoint service. Since August 2023 NLBs support security groups too (and you must decide at creation time — you cannot add one to an SG-less NLB later). Reach for the NLB when you need extreme performance, non-HTTP protocols, static IPs, or source-IP preservation.

Gateway Load Balancer (GWLB) — Layer 3

The GWLB exists for one job: inserting third-party network appliances — firewalls, IDS/IPS, deep packet inspection — transparently into your traffic path, as a “bump in the wire”. It operates at Layer 3, distributing IP packets across a fleet of appliances and using the GENEVE protocol (UDP port 6081) to encapsulate traffic so the appliance sees the original packet unchanged. You don’t point clients at a GWLB directly; you create Gateway Load Balancer Endpoints (a PrivateLink type) and route traffic to them with VPC route tables. It preserves flow stickiness so a connection’s packets always reach the same appliance. If you’re deploying a Palo Alto, Fortinet, Check Point, or similar virtual appliance for centralised inspection, the GWLB is the AWS-native way to do it — see AWS Network Firewall: egress filtering & centralized inspection for the AWS-managed alternative.

Classic Load Balancer (CLB) — legacy

The original ELB from 2009, predating target groups and the v2 generation. It straddles L4 and a limited L7, supports only instance targets, has none of the modern routing rules, no SNI, no Lambda targets, and a weaker feature set across the board. AWS has announced the retirement of the Classic Load Balancer and is actively steering customers off it. The only reason to touch a CLB today is to migrate an old workload away from it. Every new design uses ALB or NLB.

Listeners and rules

A listener is the front door: a protocol and port the load balancer accepts connections on. You can have multiple listeners on one load balancer (e.g. an ALB with both HTTP:80 — usually redirecting — and HTTPS:443). What a listener does with a connection differs by load-balancer type: on an NLB and CLB the listener simply forwards to a target group (or, on CLB, to instances); on an ALB, the listener runs an ordered list of rules, and this is where the L7 power lives.

Listener fields

ALB rules: conditions and actions

Each ALB listener has a default rule (the catch-all) plus up to 100 custom rules, evaluated in priority order, lowest number first; the first rule whose conditions all match wins, and evaluation stops. A rule is a set of conditions (ANDed together) and exactly one terminal action (plus optional non-terminal actions like authenticate that run first).

Rule conditions — the things you can match on:

Conditions support wildcards (*, ?) and you can have several values per condition. All conditions in a rule must match for the rule to fire.

Rule actions — what happens when a rule matches:

A canonical setup: an HTTP:80 listener whose default action is a redirect to HTTPS, and an HTTPS:443 listener with rules — Host shop.example.com + Path /api/* → forward to tg-api; Path /static/* → forward to tg-static; default → forward to tg-web. That’s content-based routing, and it’s why teams pick the ALB.

# Add an HTTPS listener with a default forward to a target group
aws elbv2 create-listener \
  --load-balancer-arn "$ALB_ARN" \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn="$ACM_CERT_ARN" \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn="$TG_WEB_ARN"

# Add a path-based rule: /api/* -> tg-api, priority 10
aws elbv2 create-rule \
  --listener-arn "$LISTENER_ARN" \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn="$TG_API_ARN"

# HTTP:80 listener that redirects everything to HTTPS
aws elbv2 create-listener \
  --load-balancer-arn "$ALB_ARN" \
  --protocol HTTP --port 80 \
  --default-actions \
  'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

Target groups

A target group is the pool of backends a listener or rule forwards to, plus the health check that decides which of those backends are eligible, plus the per-group attributes (deregistration delay, stickiness, slow start, etc.). Target groups are first-class resources you create independently and attach to listeners — and one target group can be referenced by multiple listeners or rules, even across more than one load balancer. The most important decision is the target type, because it’s fixed at creation and changes everything else.

Target types

The alb target type is the clever one: it lets you put an NLB in front of an ALB, so you get the NLB’s static Elastic IPs and PrivateLink support plus the ALB’s Layer-7 routing behind it — the standard way to expose an HTTP service over PrivateLink.

Target group core settings

Health checks — field by field

The health check is the most consequential thing in a target group. The load balancer probes each target on a schedule; a target becomes healthy after N consecutive passes and unhealthy after M consecutive failures, and only healthy targets receive traffic.

The classic failure mode: a security group that doesn’t allow the load balancer’s traffic to the health-check port, so every target shows unhealthy and the ALB returns 503 Service Unavailable. Always allow the LB’s SG (ALB) or the LB nodes’ subnet/CIDR (NLB) inbound to the target on both the traffic port and the health-check port.

Deregistration delay (connection draining)

When a target is deregistered — because Auto Scaling is terminating it, you’re deploying, or it failed — you rarely want to cut its in-flight requests dead. Deregistration delay (a.k.a. connection draining) is the grace period during which the load balancer stops sending new requests to the target but lets existing connections finish.

Tie this to your Auto Scaling lifecycle hooks and ALB health-check grace period so instances drain cleanly on scale-in and on rolling deploys.

Stickiness (session affinity)

By default a load balancer spreads requests; stickiness pins a client to the same target for a window, which matters for apps that hold session state in memory. There are three flavours:

Stickiness is a smell as often as a solution: it undermines even distribution and means a target’s death takes its pinned sessions with it. Prefer stateless backends with session state in ElastiCache/DynamoDB, and use stickiness only when you truly cannot.

Slow start

When a fresh target joins a busy target group, sending it a full share of traffic immediately can overwhelm a cold JVM, an empty cache, or a connection pool that hasn’t warmed. Slow start ramps a new target’s traffic linearly from zero to its full share over a configured window (30–900 seconds; 0 = disabled, the default).

Slow start applies to ALB and CLB target groups only (not NLB), and it does not apply while a target group is empty or only has one target — there’s no one else to share with.

Routing algorithm — how a target actually gets picked

The health check decides which targets are eligible; the routing algorithm decides which eligible target a given request goes to. It’s set per target group and differs by load-balancer type, and it’s the detail that explains a lot of “why is one instance hotter than the others?” mysteries.

Two consequences worth internalising. First, stickiness overrides the algorithm: once a client is pinned (by the AWSALB cookie on an ALB or the flow hash on an NLB) that decision wins, so heavy stickiness can defeat even LOR. Second, on the ALB, least_outstanding_requests is usually the better default for real microservices — flip it on any target group whose requests are non-uniform:

aws elbv2 modify-target-group-attributes \
  --target-group-arn "$TG_ARN" \
  --attributes Key=load_balancing.algorithm.type,Value=least_outstanding_requests

Automatic Target Weights (ATW) is the newer safety net: with weighted_random, the ALB continuously measures per-target error rates and automatically shifts traffic away from a target that is failing anomalously (returning 5xx, connection errors) even while its health check still passes — catching the “healthy but broken” grey failure that a binary health check misses.

Cross-zone load balancing

A load balancer has one node per Availability Zone. Cross-zone load balancing decides whether each node may send traffic only to targets in its own AZ or to all registered targets across every AZ. This single setting changes both distribution fairness and your bill, and — crucially — the default differs by load-balancer type.

Why the uneven-distribution warning matters: imagine AZ-a has 1 instance and AZ-b has 4, and Route 53 sends roughly half the clients to each AZ’s node. With cross-zone off, the single instance in AZ-a gets the whole of AZ-a’s 50% while each of AZ-b’s four instances gets 12.5% — a 4× imbalance. With cross-zone on, all five instances share equally. The defence is to keep target counts balanced across AZs (Auto Scaling’s AZ rebalancing does this) or turn cross-zone on.

The billing twist: for the ALB cross-zone traffic is free, so leaving it on is a no-brainer. For the NLB and GWLB, cross-zone traffic incurs inter-AZ data-transfer charges, so enabling it trades even distribution for cost — on a high-throughput NLB that can be significant. On v2 load balancers cross-zone is configured as a target-group attribute (load_balancing.cross_zone.enabled), so you can even mix policies per target group.

# Turn cross-zone ON for an NLB target group (off by default)
aws elbv2 modify-target-group-attributes \
  --target-group-arn "$TG_ARN" \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

TLS termination, SNI and mTLS

TLS termination means the load balancer decrypts HTTPS/TLS at the edge so your backends can speak plain HTTP — offloading the cryptographic work, centralising certificate management, and letting the ALB read the request for routing. (You can also re-encrypt to the targets by using an HTTPS/TLS target-group protocol when end-to-end encryption is required.)

Certificates and security policies

You attach a server certificate to an HTTPS (ALB) or TLS (NLB) listener. Use AWS Certificate Manager (ACM) — public certificates are free and auto-renew, so you never get paged for an expired cert. The security policy (ELBSecurityPolicy-*) is the named set of TLS protocol versions and cipher suites the listener will negotiate; pick a current TLS 1.2/1.3 policy (e.g. ELBSecurityPolicy-TLS13-1-2-2021-06) so you don’t allow legacy TLS 1.0/1.1 or weak ciphers.

SNI — many certificates, one listener

Server Name Indication (SNI) lets a single HTTPS listener serve multiple TLS certificates and present the right one based on the hostname the client requests in the TLS handshake. You set one default certificate and add others; the ALB matches the SNI hostname to the best certificate (a NLB TLS listener supports SNI too). This is how one ALB fronts app.example.com, api.example.com, and customer-vanity-domain.com each with its own certificate — no need for a load balancer per domain.

# Add an extra SNI certificate to an existing HTTPS listener
aws elbv2 add-listener-certificates \
  --listener-arn "$LISTENER_ARN" \
  --certificates CertificateArn="$SECOND_CERT_ARN"

Mutual TLS (mTLS)

In ordinary TLS the server proves its identity to the client. In mutual TLS the client also presents a certificate that the load balancer validates — strong, certificate-based client authentication for B2B APIs, IoT fleets, and zero-trust designs. The ALB supports mTLS on HTTPS listeners in two modes:

• verify — the ALB validates the client certificate against a trust store (a bundle of CA certificates you upload to S3), optionally checking a certificate revocation list (CRL). Connections without a valid client cert are rejected. The ALB passes the validated certificate details to your app in X-Amz-Mtls-* headers.
• passthrough — the ALB does not validate; it forwards the whole client-certificate chain to your application in a header so your code does the verification.

The NLB also supports a form of TLS mutual authentication on TLS listeners. Use mTLS when you need cryptographic proof of client identity rather than (or in addition to) tokens.

Access logs and security groups

Access logs

Access logs capture detailed records of every request the load balancer processed — client IP, target, latencies, status codes, the matched rule, TLS cipher, and more — written to an S3 bucket you specify. They’re off by default and free to enable (you pay only S3 storage and the request charges). For an ALB they’re the primary forensic and analytics source: who hit what, how slow it was, which target served it, and whether the LB or the target returned an error. Turn them on in production; query them with Athena. (For real-time, there are also connection logs on the ALB and flow logs at the VPC level.)

# Enable ALB access logs to an S3 bucket (bucket policy must allow the ELB account)
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn "$ALB_ARN" \
  --attributes \
  Key=access_logs.s3.enabled,Value=true \
  Key=access_logs.s3.bucket,Value=my-alb-logs-bucket \
  Key=access_logs.s3.prefix,Value=prod-alb

Security groups — ALB vs NLB

This trips people up because the two behave differently.

• ALB always has a security group attached to the load balancer itself. Inbound, allow 443/80 from the world (or your clients); outbound, the ALB needs to reach targets. Then the target’s security group must allow inbound from the ALB’s security group on the traffic and health-check ports — reference the SG, don’t hard-code IPs.
• NLB historically had no security group; targets had to allow the clients’ IPs (because the NLB preserves the source IP) or the VPC CIDR / NLB subnet ranges. Since August 2023 an NLB can have a security group — but you must enable it at creation (an SG-less NLB cannot gain one later). With an SG, you also control whether the SG is evaluated for traffic where preserve_client_ip is on, via the enforce_security_group_inbound_rules_on_private_link_traffic style attributes. The historical gotcha — “my NLB targets reject traffic because their SG allows the NLB but the NLB preserves the client IP, which the SG doesn’t allow” — is exactly why you must reason about source-IP preservation when writing target SG rules.

Note also that a Network ACL sits at the subnet level and is stateless: it must allow both the inbound request and the outbound ephemeral-port response in each direction, or return traffic silently dies. See AWS Security Groups vs Network ACLs for that interaction.

The diagram above maps the family onto the OSI stack — ALB at L7 reading paths and hosts into multiple target groups, the NLB at L4 hashing flows (with its optional static EIPs), and the GWLB at L3 steering packets through inspection appliances — with the shared listener → rules → target group → health-checked targets pipeline beneath them.

Going deeper

The core above is enough to design and pass the exam. This section is for the reader who runs load balancers in anger — the timing knobs, the hardening attributes, the exact shape of the bill, and the failure modes that only show up at scale.

Idle timeout, keep-alive, and the 502/504 boundary

Every load balancer holds a connection open only so long before it reclaims it. On the ALB this is the connection idle timeout — idle_timeout.timeout_seconds, default 60 s, adjustable 1–4000 s — and it applies to both the client→ALB and the ALB→target sides. If a target takes longer than the idle timeout to send the first byte of a response, the ALB gives up and returns 504 Gateway Timeout. Long operations (report generation, large uploads) therefore need a higher idle timeout, or an async pattern.

The subtler failure is the 502 Bad Gateway caused by a keep-alive race: the ALB reuses a pooled back-end connection, but the target had already decided to close it. The rule is simple and worth committing to memory — set the target’s own keep-alive timeout higher than the ALB idle timeout (e.g. target 75 s when the ALB is 60 s) so the ALB always closes the connection first. Many stock web-server defaults (nginx keepalive_timeout 65, older Node.js server.keepAliveTimeout of 5 s) get this backwards and produce sporadic 502s under load. A separate 2023 attribute, client_keep_alive.seconds (default 3600), caps the total lifetime of a client connection independent of idle time.

The NLB is different: a TCP flow’s idle timeout is 350 s and is not configurable, and UDP flows time out at 120 s. Because the NLB does not send a TCP reset when it reaps an idle flow, a client that goes quiet for longer than 350 s can find its connection silently dead. The fix is TCP keep-alives from the application (interval < 350 s) so the flow never looks idle. This is the single most common “my long-lived NLB connection dropped for no reason” cause.

Hardening attributes you should set on day one

Beyond security groups and TLS policy, a production load balancer has a set of attributes that are off or permissive by default and worth turning on deliberately:

# Belt-and-braces: deletion protection + strict desync mitigation on a prod ALB
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn "$ALB_ARN" \
  --attributes \
    Key=deletion_protection.enabled,Value=true \
    Key=routing.http.desync_mitigation_mode,Value=strictest \
    Key=routing.http.drop_invalid_header_fields.enabled,Value=true

The LCU / NLCU pricing model, dimension by dimension

Every v2 load balancer bills two things: a small hourly rate for the load balancer itself, plus capacity units consumed. You do not add the dimensions up — for each hour you are charged on the single highest of them. Knowing which dimension dominates tells you where your cost actually comes from.

An ALB Load Balancer Capacity Unit (LCU) measures four dimensions; 1 LCU equals whichever of these is the ceiling that hour:

• New connections: 25 new connections per second.
• Active connections: 3,000 active connections per minute.
• Processed bytes: 1 GB per hour (for instance/IP targets; Lambda targets are metered at 0.4 GB).
• Rule evaluations: 1,000 rule-evaluations per second (the first 10 rule evaluations per request are free).

So a connection-storm API with tiny payloads bills on the new-connections axis, while a media service bills on processed bytes — the same LB, different dominant dimension. The NLB uses an analogous NLCU with new flows, active flows, and processed bytes (no rule evaluations), and TLS listeners are metered on a separate, higher-priced NLCU because the NLB is doing the crypto. The GWLB bills in GLCUs. Practical levers: consolidate small ALBs (each has its own hourly charge), keep rule counts lean, and remember that enabling cross-zone on an NLB adds inter-AZ data-transfer charges on top of the NLCU bytes — the one place the “cross-zone is free” intuition from the ALB does not carry over.

Surviving a bad AZ: zonal shift and zonal affinity

Both ALB and NLB integrate with Route 53 Application Recovery Controller (ARC) zonal shift: with one API call (or zonal autoshift, where AWS triggers it for you on detecting an impairment) you pull one AZ’s load-balancer IPs out of DNS, evacuating that zone without touching your targets. This is the fastest lever for a grey AZ failure — but it only helps if your other AZs have the capacity to absorb the load, which is the real argument for the “keep target counts balanced across AZs” rule from the cross-zone section.

The NLB adds a related knob, dns_record.client_routing_policy: the default any_availability_zone lets clients resolve to any AZ’s node, while availability_zone_affinity steers a client to the node in its own AZ to shave inter-AZ latency and data-transfer cost — at the price of concentrating a client’s blast radius in one zone. partial_availability_zone_affinity splits the difference.

Two operational gotchas: the access-log bucket policy and the SG-less NLB

Access logs need the load balancer’s delivery identity to have s3:PutObject on your bucket, and the identity differs by region generation. In older regions you must allow a numeric ELB account ID (each region has its own, e.g. 127311923021 for us-east-1) as the principal. In newer regions (roughly those launched from 2022 on) delivery uses the service principal logdelivery.elasticloadbalancing.amazonaws.com instead. Copy the wrong one for your region and logs silently never appear — there is no error, the toggle just does nothing. Second gotcha, restated because it is the classic one: an NLB can only gain a security group if you attach it at creation time — there is no “add SG later” for an NLB that was built without one; you must recreate it.

Service quotas that bite at scale

These are default, soft quotas — raise them through Service Quotas — but the defaults catch teams by surprise:

Provisioning it as code

In production you never click this together — you declare it. In Terraform (AWS provider v5) the canonical resources are aws_lb (with load_balancer_type = "application" | "network" | "gateway"), aws_lb_target_group, aws_lb_listener, and aws_lb_listener_rule. Cross-zone for a network LB is enable_cross_zone_load_balancing on the aws_lb (default false for NLB, matching AWS; ALB is always on and the argument is ignored). CloudFormation exposes the same objects as AWS::ElasticLoadBalancingV2::LoadBalancer, TargetGroup, Listener, and ListenerRule.

resource "aws_lb" "web" {
  name                       = "prod-web-alb"
  load_balancer_type         = "application"
  security_groups            = [aws_security_group.alb.id]
  subnets                    = var.public_subnet_ids
  enable_deletion_protection = true
  drop_invalid_header_fields = true
}

resource "aws_lb_target_group" "web" {
  name        = "prod-web-tg"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = var.vpc_id
  target_type = "instance"

  # Least-outstanding-requests suits non-uniform microservice traffic
  load_balancing_algorithm_type = "least_outstanding_requests"

  health_check {
    path                = "/healthz"
    matcher             = "200-299"
    healthy_threshold   = 3
    unhealthy_threshold = 2
    interval            = 15
  }
}

Hands-on lab

We’ll stand up an internet-facing ALB in front of a tiny two-instance target group, watch health checks turn the targets healthy, hit the DNS name, add a path-based rule, and clean everything up. This uses small t3.micro instances and an ALB; the ALB has an hourly + LCU charge, so we tear it down at the end. Run it in a non-production account, in a region with at least two AZs.

0. Set variables (replace the VPC and two subnet IDs from two different AZs).

REGION=eu-west-1
VPC_ID=vpc-xxxxxxxx
SUBNET_A=subnet-aaaaaaa   # AZ a
SUBNET_B=subnet-bbbbbbb   # AZ b

1. Create a security group for the ALB (allow HTTP from the world).

ALB_SG=$(aws ec2 create-security-group --group-name lab-alb-sg \
  --description "ALB SG" --vpc-id $VPC_ID --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $ALB_SG \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

2. Create a security group for the instances that allows port 80 from the ALB’s SG.

WEB_SG=$(aws ec2 create-security-group --group-name lab-web-sg \
  --description "web SG" --vpc-id $VPC_ID --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $WEB_SG \
  --protocol tcp --port 80 --source-group $ALB_SG

3. Launch two t3.micro instances (Amazon Linux 2023) running a one-line web server via user data — one per subnet. Look up the latest AL2023 AMI from SSM:

AMI=$(aws ssm get-parameters --names \
  /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameters[0].Value' --output text)

USERDATA=$(printf '#!/bin/bash\ndnf -y install httpd\necho "Hello from $(hostname -f)" > /var/www/html/index.html\nsystemctl enable --now httpd\n' | base64)

for SUBNET in $SUBNET_A $SUBNET_B; do
  aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
    --security-group-ids $WEB_SG --subnet-id $SUBNET \
    --user-data "$USERDATA" \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=lab-web}]'
done

Wait until both instances are running, then capture their IDs:

INSTANCE_IDS=$(aws ec2 describe-instances \
  --filters Name=tag:Name,Values=lab-web Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].InstanceId' --output text)
echo $INSTANCE_IDS

4. Create a target group (instance type, HTTP:80, health check /).

TG_ARN=$(aws elbv2 create-target-group --name lab-tg --protocol HTTP --port 80 \
  --vpc-id $VPC_ID --target-type instance \
  --health-check-path / --matcher HttpCode=200 \
  --query 'TargetGroups[0].TargetGroupArn' --output text)

for ID in $INSTANCE_IDS; do
  aws elbv2 register-targets --target-group-arn $TG_ARN --targets Id=$ID
done

5. Create the ALB across both subnets and a listener forwarding to the target group.

ALB_ARN=$(aws elbv2 create-load-balancer --name lab-alb \
  --type application --scheme internet-facing \
  --subnets $SUBNET_A $SUBNET_B --security-groups $ALB_SG \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

aws elbv2 create-listener --load-balancer-arn $ALB_ARN \
  --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

6. Validate — watch health, then curl the DNS name.

# Targets should move from "initial" to "healthy" within ~1-2 minutes
aws elbv2 describe-target-health --target-group-arn $TG_ARN \
  --query 'TargetHealthDescriptions[].{id:Target.Id,state:TargetHealth.State}' \
  --output table

DNS=$(aws elbv2 describe-load-balancers --load-balancer-arns $ALB_ARN \
  --query 'LoadBalancers[0].DNSName' --output text)
echo "http://$DNS"

# Repeat a few times — you should see responses from BOTH hostnames (ALB spreads load)
for i in 1 2 3 4 5 6; do curl -s "http://$DNS"; done

Expected: describe-target-health shows both targets healthy, and the curl loop returns “Hello from …” alternating between the two instance hostnames — proof the ALB is load-balancing across AZs (cross-zone is on by default for ALB).

7. (Optional) Add a path-based rule that returns a fixed maintenance response for /maintenance:

LISTENER_ARN=$(aws elbv2 describe-listeners --load-balancer-arn $ALB_ARN \
  --query 'Listeners[0].ListenerArn' --output text)

aws elbv2 create-rule --listener-arn $LISTENER_ARN --priority 10 \
  --conditions Field=path-pattern,Values='/maintenance' \
  --actions 'Type=fixed-response,FixedResponseConfig={StatusCode=503,ContentType=text/plain,MessageBody=Down for maintenance}'

curl -s "http://$DNS/maintenance"   # -> "Down for maintenance"

Cleanup — delete in dependency order (listener/rules go with the LB):

aws elbv2 delete-load-balancer --load-balancer-arn $ALB_ARN
sleep 30
aws elbv2 delete-target-group --target-group-arn $TG_ARN
aws ec2 terminate-instances --instance-ids $INSTANCE_IDS
aws ec2 wait instance-terminated --instance-ids $INSTANCE_IDS
aws ec2 delete-security-group --group-id $WEB_SG
aws ec2 delete-security-group --group-id $ALB_SG

Cost note: an ALB is not free-tier-free in the way EC2 micro is — it bills an hourly rate plus Load Balancer Capacity Units (LCUs), together roughly US$0.02–0.03 per hour in most regions, so an hour of lab time costs a few cents; the two t3.micro instances fall under the EC2 free tier for the first 12 months (750 hrs/month combined) or cost a couple of cents each per hour otherwise. Delete the ALB promptly — an idle ALB still bills its hourly charge 24×7.

Common mistakes & troubleshooting

Common beginner mistakes

These are misconceptions rather than symptoms — the wrong mental model that leads you into the troubleshooting table above. Fix the model and the bug never happens.

• “The load balancer has an IP I can allowlist.” No — an ALB (and a default NLB) is a fleet addressed by a DNS name that resolves to a set of IPs which change as AWS heals and scales it. Hard-coding a resolved IP works until the day it doesn’t. Right model: point clients and Route 53 alias records at the DNS name; the only way to get a stable IP is an NLB with static Elastic IPs.

• “Cross-zone load balancing behaves the same on every type.” It does not, and this is the most-tested trap. ALB: cross-zone is always on and free. NLB/GWLB: off by default, and turning it on adds inter-AZ data-transfer charges. Right model: before you assume even distribution, ask which load balancer — and if it’s an NLB, keep target counts balanced per AZ instead of blindly enabling cross-zone.

• “Health-checking / is good enough.” A request to / can return 200 from a web server whose database connection is dead — the check passes while the app is broken, and users get errors from a “healthy” target. Right model: point the check at a real /healthz that verifies critical dependencies, but keep it shallow enough that one slow dependency doesn’t flap the whole fleet.

• “Stickiness fixed my logout bug, so I’m done.” Stickiness pins a user to one target — and when that target dies (deploys, scale-in, hardware), it takes every pinned session with it, and it unbalances load. You’ve converted an occasional logout into a periodic mass logout. Right model: stickiness is a smell; put session state in ElastiCache or DynamoDB and keep backends stateless.

• “My NLB preserves the client IP, so a target SG that allows the NLB is correct.” Exactly backwards. Because the NLB preserves the source IP, the packet arrives with the client’s address, not the NLB’s — so a target SG that allows the NLB/VPC range rejects real traffic. Right model: with source-IP preservation on, allow the client CIDRs (or the VPC CIDR) on the target SG.

• “TLS terminates at the ALB, so traffic to my instances is encrypted.” Only up to the ALB. By default the ALB→target hop is plain HTTP inside your VPC. Right model: if you need end-to-end encryption (compliance, zero-trust), give the target group an HTTPS/TLS protocol so the ALB re-encrypts to the target — decide it, don’t assume it.

• “An idle load balancer is basically free, so I’ll leave it up.” An ALB/NLB bills its hourly rate 24×7 whether or not a single request flows, with LCUs stacked on top. A forgotten lab LB is a quiet monthly charge. Right model: delete load balancers you’re not using; enable deletion protection only on the ones you mean to keep.

Best practices

• Pick the layer first. HTTP routing → ALB; raw TCP/UDP, static IP, or PrivateLink front → NLB; inline appliances → GWLB; never CLB for anything new.
• Always redirect HTTP→HTTPS and terminate TLS with an ACM certificate so renewal is automatic; choose a current TLS 1.2/1.3 security policy.
• Health-check the application, not just the port. Use an HTTP /healthz that verifies critical dependencies, with thresholds tuned so you eject bad targets fast without flapping.
• Spread across at least two (ideally three) AZs and keep target counts balanced per AZ; enable cross-zone on the ALB (it’s free) and weigh the inter-AZ cost on the NLB.
• Tune deregistration delay to your request profile and wire it to Auto Scaling lifecycle hooks so deploys and scale-in drain cleanly.
• Prefer stateless backends. Push session state to ElastiCache/DynamoDB and avoid stickiness unless an app genuinely requires it.
• Turn on access logs to S3 in production and analyse them with Athena; add AWS WAF on the ALB for L7 protection.
• Reference security groups, not IPs, between the ALB and its targets; treat the SG chain as part of the design, not an afterthought.

Security notes

• Front the ALB with AWS WAF for OWASP-class protection (SQLi, XSS, rate limiting, bot control) and consider AWS Shield Advanced for DDoS on internet-facing load balancers.
• Enforce strong TLS: pick a TLS 1.2/1.3 ELBSecurityPolicy, disable legacy protocols, and use FS (forward-secrecy) policies; rotate via ACM automatically.
• Use mTLS on the ALB where you need cryptographic client authentication (B2B/IoT/zero-trust) rather than relying solely on bearer tokens.
• Lock down the security-group chain: the ALB SG allows only the ports you serve from only the clients you intend; the target SG allows only the ALB SG. For NLBs, reason from source-IP preservation when writing target rules.
• Use internal (internal) load balancers for service-to-service traffic so backends never get a public endpoint; reserve internet-facing for the true edge.
• Authenticate at the edge with authenticate-oidc/authenticate-cognito to keep unauthenticated traffic off your application entirely.
• Audit with access logs and CloudTrail: access logs answer “who hit what”; CloudTrail records configuration changes to the load balancer and target groups.

Interview & exam questions

1. What’s the core difference between an ALB and an NLB, and how do you choose? The ALB is a Layer-7 load balancer that understands HTTP and routes on content (host, path, headers, method); the NLB is a Layer-4 load balancer that forwards TCP/UDP flows with ultra-low latency, supports static Elastic IPs, and preserves the client source IP. Choose the ALB for web apps and content-based routing; the NLB for extreme performance, non-HTTP protocols, static IPs, or PrivateLink fronts.

2. Why does my application read the load balancer’s IP as the source address, and how do I get the real client IP? An ALB terminates the connection and opens a new one to the target, so the target sees the ALB’s IP; the original client IP is in the X-Forwarded-For header. An NLB with instance/IP targets preserves the client source IP at the TCP layer by default, so the target sees the real client IP directly.

3. Explain cross-zone load balancing, its defaults, and its cost implication. Cross-zone lets a node in one AZ send traffic to targets in all AZs (even distribution) rather than only its own (per-AZ-then-per-target distribution, which is uneven if AZ target counts differ). It’s on by default and free for the ALB, and off by default for the NLB/GWLB, where enabling it incurs inter-AZ data-transfer charges.

4. A user reports their session keeps “logging out”. How might the load balancer be involved, and how do you fix it properly? If the app holds session state in memory and stickiness is off, requests land on different targets that don’t share state. The quick fix is stickiness (duration cookie or app cookie on the ALB); the proper fix is stateless backends with session state in ElastiCache/DynamoDB so any target can serve any request.

5. All your ALB targets are unhealthy and clients get 503. Walk through the diagnosis. 503 means no healthy targets. Check the target SG allows the ALB SG inbound on the traffic and health-check ports; confirm the health-check path/port/matcher match a real endpoint and code; verify the app is actually listening; check the NACL allows return traffic. Use describe-target-health for the per-target reason code.

6. What target types can an ALB target group contain, and what’s special about the alb type? instance, IP, and Lambda (ALB only). The alb target type belongs to an NLB target group and points at an ALB, so you can put an NLB (static EIPs, PrivateLink) in front of an ALB’s L7 routing.

7. What is SNI and why does it matter on an ALB? Server Name Indication lets one HTTPS listener serve multiple certificates and present the correct one based on the hostname in the TLS handshake, so a single ALB can front many domains each with its own certificate — no load balancer per domain.

8. What is deregistration delay / connection draining, and what value would you set? It’s the grace period during which a deregistering target receives no new requests but finishes in-flight ones (default 300s). Lower it (e.g. 30s) for short, stateless requests to speed deploys; raise it for long uploads or long-lived connections — and tie it to ASG lifecycle hooks.

9. When would you reach for a Gateway Load Balancer? To insert third-party security appliances (firewall, IDS/IPS) transparently into the traffic path at Layer 3, using GENEVE encapsulation and GWLB endpoints, while preserving flow stickiness — the AWS-native pattern for centralised appliance-based inspection.

10. Does an NLB have a security group? Historically no — you secured targets against client/VPC CIDRs (because the NLB preserves the source IP). Since August 2023 an NLB can have a security group, but it must be enabled at creation; an SG-less NLB cannot gain one later.

11. What is mTLS on an ALB and what are the two modes? Mutual TLS makes the client present a certificate that the ALB validates. verify checks the client cert against an uploaded trust store (CA bundle in S3) with optional CRL; passthrough forwards the client certificate chain to your app to validate. Used for strong client authentication.

12. What is slow start and which load balancers support it? Slow start ramps a newly healthy target’s traffic linearly from zero to full over 30–900s so cold instances aren’t overwhelmed on join. It applies to ALB and CLB target groups (not NLB) and only when the group has other targets to share with.

Quick check

1. Which load balancer operates at Layer 7 and can route on URL path and host header?
2. Which load balancer can be assigned a static Elastic IP per Availability Zone?
3. What is the default value of deregistration_delay.timeout_seconds?
4. Cross-zone load balancing is on-by-default and free for which load-balancer type?
5. What ALB feature lets one HTTPS listener serve certificates for many different domains?

Answers

1. The Application Load Balancer (ALB).
2. The Network Load Balancer (NLB) — one Elastic IP per AZ.
3. 300 seconds (5 minutes).
4. The ALB (cross-zone is always on for ALB and incurs no inter-AZ charge; it’s off-by-default and chargeable on the NLB/GWLB).
5. SNI (Server Name Indication) with multiple listener certificates.

Exercise

Design and build, using the CLI, an internet-facing ALB that serves two microservices behind one HTTPS listener: requests to api.<yourdomain> path /v1/* go to a target group tg-api, and everything else goes to tg-web. Requirements: (1) an HTTP:80 listener that redirects to HTTPS; (2) an HTTPS:443 listener using an ACM certificate and a TLS 1.3 security policy; (3) a path-based rule for /v1/*; (4) access logs enabled to an S3 bucket; (5) health checks on a dedicated /healthz path with a 200-299 matcher. Then deliberately break it: tighten the tg-api target SG to remove the ALB SG rule and observe the targets go unhealthy and the listener return 503 — confirming you understand the SG chain. Restore it, verify both routes, and tear everything down. Bonus: put an NLB with a static EIP in front of the ALB using the alb target type and curl the NLB’s EIP.

Practice challenges

Six graded exercises, beginner to advanced. Try each before opening the solution. They use the same $ALB_ARN, $LISTENER_ARN, $TG_ARN placeholders as the lab; nothing here needs a live account to reason through.

1. (Beginner) Pick the load balancer. For each requirement, name the load balancer: (a) a partner must allowlist a fixed IP for your endpoint; (b) route /api/* and /static/* to different backends; © insert a third-party firewall appliance inline for packet inspection.

<details><summary>Solution</summary>

(a) NLB — the only ELB with static Elastic IPs. (b) ALB — Layer-7 path-based routing. © GWLB — transparent appliance insertion via GENEVE.

Why: the choice falls straight out of the layer and the one distinctive feature each type owns (static IP → NLB, content routing → ALB, appliances → GWLB). </details>

2. (Beginner) Redirect HTTP to HTTPS. Write the CLI to add an HTTP:80 listener whose default action is a permanent redirect to HTTPS:443.

<details><summary>Solution</summary>

aws elbv2 create-listener \
  --load-balancer-arn "$ALB_ARN" \
  --protocol HTTP --port 80 \
  --default-actions \
  'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

Why: HTTP_301 is a permanent redirect so browsers and search engines cache the HTTPS location; the ALB does the redirect itself, so no backend is involved. </details>

3. (Intermediate) Header-based routing. On an existing HTTPS listener, add a rule at priority 20 that forwards requests carrying the header X-Tenant: acme to a target group $TG_ACME.

<details><summary>Solution</summary>

aws elbv2 create-rule \
  --listener-arn "$LISTENER_ARN" \
  --priority 20 \
  --conditions 'Field=http-header,HttpHeaderConfig={HttpHeaderName=X-Tenant,Values=[acme]}' \
  --actions Type=forward,TargetGroupArn="$TG_ACME"

Why: http-header conditions are how ALBs do multi-tenant and canary routing; lower priority numbers are evaluated first, and the first fully-matching rule wins. </details>

4. (Intermediate) Tune a target group for fast, fair deploys. Change $TG_ARN to route by least outstanding requests and drop its deregistration delay to 30 s.

<details><summary>Solution</summary>

aws elbv2 modify-target-group-attributes \
  --target-group-arn "$TG_ARN" \
  --attributes \
    Key=load_balancing.algorithm.type,Value=least_outstanding_requests \
    Key=deregistration_delay.timeout_seconds,Value=30

Why: LOR keeps a slow target from accumulating work, and 30 s draining is plenty for short, stateless requests — deploys finish fast instead of waiting out the 300 s default. </details>

5. (Advanced) Static IP in front of Layer-7 routing. A partner needs a static IP allowlist but your service needs the ALB’s path routing. Describe the construct, then write the CLI to create the NLB target group and register the ALB.

<details><summary>Solution</summary>

Put an NLB in front of the ALB using the alb target type: the NLB gives static Elastic IPs, the ALB behind it keeps the L7 rules.

# NLB target group of type 'alb', then register the ALB as its target
TG_ALB=$(aws elbv2 create-target-group --name front-alb-tg \
  --protocol TCP --port 443 --vpc-id "$VPC_ID" --target-type alb \
  --query 'TargetGroups[0].TargetGroupArn' --output text)

aws elbv2 register-targets --target-group-arn "$TG_ALB" \
  --targets Id="$ALB_ARN"
# then create a TCP:443 listener on the NLB that forwards to $TG_ALB

Why: the alb target type belongs to an NLB target group and points at an ALB — the canonical way to expose L7 routing behind a static IP or an AWS PrivateLink endpoint service. </details>

6. (Advanced) Diagnose the “SG looks right but NLB targets reject traffic.” Instance targets behind an NLB refuse connections even though the target SG allows the NLB’s security group and the VPC CIDR. What’s wrong, what’s the fix, and what one-time constraint applies to NLB security groups?

<details><summary>Solution</summary>

The NLB has client-IP preservation on (default for instance/IP targets), so packets arrive with the client’s source IP — not the NLB’s. A target SG that only allows the NLB or VPC range drops them. Fix: allow the client CIDRs (or, for internal traffic, the VPC CIDR that the clients actually come from) on the target SG. Constraint: an NLB can only have a security group if it was attached at creation — an SG-less NLB cannot gain one later; you’d recreate the NLB.

Why: you must reason SG rules from what source IP the target sees, and source-IP preservation changes that from the LB’s IP to the real client’s. </details>

Certification mapping

• AWS Certified Solutions Architect – Associate (SAA-C03): choosing ALB vs NLB vs GWLB, target groups and health checks, cross-zone load balancing, TLS termination and SNI, sticky sessions, and integrating load balancers with Auto Scaling and multi-AZ designs are core, frequently tested topics.
• AWS Certified Advanced Networking – Specialty (ANS-C01): the deep end — NLB source-IP preservation and security groups, GWLB and GENEVE appliance insertion, mTLS, PrivateLink with NLB, cross-zone cost trade-offs, and access-log analysis.
• AWS Certified SysOps Administrator – Associate (SOA-C02): operating load balancers — health-check troubleshooting, the 502/503/504 distinctions, deregistration delay and draining, access logs, and CloudWatch metrics (HealthyHostCount, TargetResponseTime, HTTPCode_ELB_5XX).
• AWS Certified Developer – Associate (DVA-C02): ALB path/host routing for microservices, Lambda targets, authentication actions, and the X-Forwarded-For header.

Glossary

• Elastic Load Balancing (ELB): the AWS service family providing ALB, NLB, GWLB, and the legacy CLB.
• Application Load Balancer (ALB): a Layer-7 load balancer that routes HTTP/HTTPS on request content.
• Network Load Balancer (NLB): a Layer-4 load balancer for TCP/UDP with ultra-low latency, static EIPs, and source-IP preservation.
• Gateway Load Balancer (GWLB): a Layer-3 load balancer that transparently inserts inspection appliances using GENEVE.
• Classic Load Balancer (CLB): the original ELB; legacy and being retired.
• Listener: the protocol/port on which a load balancer accepts connections.
• Rule (ALB): a priority-ordered condition→action pairing on an ALB listener.
• Target group: the pool of registered targets plus the health check and per-group attributes.
• Target type: instance, IP, Lambda, or ALB — fixed when the target group is created.
• Health check: the probe (protocol/path/port/thresholds/matcher) that determines target health.
• Deregistration delay (connection draining): the grace period before a removed target stops receiving traffic.
• Stickiness (session affinity): pinning a client to one target (LB cookie, app cookie, or source-IP).
• Slow start: linear traffic ramp-up for a newly healthy target (ALB/CLB).
• Cross-zone load balancing: whether nodes distribute traffic across all AZs or only their own.
• SNI (Server Name Indication): serving multiple TLS certificates on one listener by hostname.
• mTLS (mutual TLS): TLS where the client also presents a validated certificate.
• X-Forwarded-For: the HTTP header carrying the original client IP through an ALB.
• LCU (Load Balancer Capacity Unit): the metered unit (new connections, active connections, bandwidth, rule evaluations) that, with the hourly rate, determines ELB cost.
• Round robin / least outstanding requests (LOR): the two ALB target-selection algorithms — round robin sends to each target in turn; LOR sends to the target with the fewest in-flight requests.
• Flow hash: the NLB’s algorithm — it hashes a connection’s tuple to pick one target and keeps every packet of that flow on it for the connection’s life.
• Automatic Target Weights (ATW): ALB feature (with the weighted_random algorithm) that shifts traffic away from a target failing anomalously even while its health check still passes.
• Idle timeout: the window a load balancer keeps an inactive connection before reclaiming it — ALB default 60 s (1–4000 s); NLB TCP flows a fixed 350 s.
• Desync mitigation mode: an ALB setting (monitor/defensive/strictest) that defends against HTTP request-smuggling (desync) attacks.
• Deletion protection: a load-balancer attribute that blocks deletion until it is explicitly disabled.
• GENEVE: the UDP-6081 encapsulation the GWLB uses to hand original packets to inspection appliances unchanged.
• Zonal shift: a Route 53 ARC action that pulls one AZ’s load-balancer IPs out of DNS to evacuate an impaired Availability Zone.
• NLCU / GLCU: the Network / Gateway Load Balancer capacity-unit meters — the NLB/GWLB equivalents of the ALB’s LCU.

Next steps

• Put a friendly name in front of your load balancer’s DNS name and add health-based failover with Amazon Route 53, In Depth: Hosted Zones, Records, Routing Policies & Health Checks.
• Revisit the network the load balancer lives in — Amazon VPC, In Depth — and the firewalling that wraps it, AWS Security Groups vs Network ACLs, In Depth.
• See how containers use the same load balancers in ECS Service Connect vs Load Balancers: discovery & resilience.
• Front an HTTP service privately with AWS PrivateLink: provider & consumer, cross-account using an NLB and the alb target type.
• When something breaks across services, work it methodically with AWS Troubleshooting Methodology: EC2, VPC, IAM, S3 & Lambda.