Infra, Illustrated.
AWSDeep Diveintermediate

ALB vs NLB: which should you use?

Use ALB for HTTP-aware routing and NLB for transport protocols or zonal static IPs. See where GWLB and Global Accelerator fit when those are separate requirements.

Published Sep 10, 2026Reviewed Sep 10, 2026Standard accelerator, ALB, NLB, GWLB behavior verified 2026-09-10

Choose from the requirement

Start with the protocol and the decision you need AWS to make. If the requirement says URL path, hostname, headers, authentication, or WAF, start with ALB. If it says TCP, UDP, QUIC, TLS pass-through, or a fixed address in each Availability Zone, start with NLB.

Practical selection guide

Start with what the workload needs

Choose from the protocol, routing decision, and address requirement. If several apply, give each service a separate job.

Use ALB

For HTTP or HTTPS applications that need routing by hostname, path, header, method, or query—and for AWS WAF or supported authentication at the load balancer.

DNS → HTTPS listener → path rule → target groupExample: /checkout → checkout-tg. Not for arbitrary TCP, UDP, or opaque TLS pass-through.

Use NLB

For TCP, UDP, or QUIC services; TLS pass-through; or a stable address in each enabled Availability Zone.

DNS / zonal IP → TCP listener → target groupExample: :443 → tcp-service-tg. It cannot route from an HTTP URL or apply AWS WAF.

Use GWLB

When VPC routes must insert a scalable fleet of third-party firewalls, IDS/IPS appliances, or other transparent network appliances.

route → GWLBE ⇄ firewall fleet → routeIt is an inspection hop, not the application entrance.

Use Global Accelerator

When internet clients need static global anycast addresses and health-based routing to application endpoints in more than one AWS Region.

anycast IPs → Region → ALB or NLBIt does not replace ALB request rules or NLB flow selection.
Use the detailed comparison to verify protocols, address behavior, security controls, and target types.
Decision / optionALB
reads HTTP		NLB
balances flows		GWLB
inserts appliances		Global Accelerator
selects regional entry
Scope + roleRegional application proxy · Layer 7Regional transport load balancer · Layer 4Regional routed inspection path · Layer 3Global standard accelerator · TCP/UDP delivery
Accepted trafficHTTP, HTTPS
WebSockets · HTTP/2 · gRPC support		TCP, TLS, UDP, TCP_UDP, QUIC, TCP_QUIC
verified 2026-09-10		IP packets; GENEVE encapsulation to appliances on UDP 6081TCP and UDP listeners
Decision inputsHost, path, headers, method, query string, source-IP CIDRListener and flow; dual-stack rules can match source IP versionVPC route to GWLBE; flow stickiness selects applianceClient location, endpoint health, regional traffic dials, endpoint weights
Selection chainListener rule → action → target group → targetListener action → optional weighted target group selection → flow targetGWLBE → GWLB → appliance → GWLB → GWLBEListener → regional endpoint group → endpoint
Destination typesInstance, IP, Lambda
ECS registers instance or IP targets		Instance, IP, ALB
ALB target requires TCP setup		GENEVE-capable appliances registered as instance or IP targetsALB, NLB, EC2, Elastic IP
GWLB is not an endpoint
TLS handlingHTTPS listener terminates TLS; backend may use HTTP or HTTPSTLS listener terminates; TCP listener can pass TLS throughTransparent insertion; decryption and inspection depend on applianceEndpoint handles TLS; accelerator does not terminate application TLS
Address modelDNS endpoint with changing IPs; internet-facing or internalStatic address per enabled AZ; optional EIPs for internet-facing IPv4 NLBPrivate GWLB endpoint used as a route-table targetStatic anycast addresses; regional endpoints can change behind them
WAF + securityAWS WAF integration; ALB and target security groupsNo AWS WAF integration; security groups can apply to the NLBAppliances provide firewall, IDS, or IPS functionsNo WAF integration at GA; associate WAF with an ALB endpoint
Choose whenHTTP applications need content routing, authentication, or WAFTransport workloads need flow balancing, zonal static addresses, or TLS pass-throughTraffic must traverse a scalable appliance fleetMulti-Region applications need global static entry and health-based regional selection
Fast answer: HTTP-aware application routing → ALB · transport protocols or zonal static IPs → NLB · routed appliance inspection → GWLB · static multi-Region internet entry → Global Accelerator.

[!NOTE] A common wrong turn: choosing NLB because it sounds faster, then discovering that the application needs path routing or WAF. Choose from the protocol and routing requirement first; validate capacity and latency separately.

Put each service in the path

ALB and NLB are alternative regional application entrances. Global Accelerator can sit in front of either one when clients need stable global addresses and regional failover. GWLB belongs on a route that must pass through a firewall or another virtual appliance.

Example combined architecture

Global Accelerator in front; ALB and NLB beside each other

Clients enter through Global Accelerator. Each listener reaches the regional load balancer required by that protocol. The Mumbai egress route uses GWLB for a separate firewall path.

Give each service one job: Global Accelerator chooses a Region, ALB or NLB chooses an application target, and GWLB chooses a firewall appliance only for traffic routed through inspection.
runtime trafficconfiguration or healthGENEVE tunnelunavailable or dropped

[!NOTE] Architecture boundary: GWLB is neither an application frontend nor the firewall. A route sends traffic to a GWLB endpoint, and GWLB selects an appliance. Repeat endpoints and appliances per Availability Zone where the production design requires zonal resilience.

Use ALB for HTTP routing

Use ALB when one HTTPS entrance must send /checkout to one service and /static to another, route multiple hostnames, apply AWS WAF, or perform supported authentication and JWT checks. The listener evaluates rules in priority order; the selected target group then chooses a healthy application target.

Example · web application

Route POST /checkout to the checkout service

Choose ALB because the decision depends on the hostname and URL path. This example terminates client TLS at the ALB and opens a separate HTTPS connection to the target.

1 · Client and network access

DNS resolves the ALB name. The ALB security group allows TCP 443.

POST https://shop.example.com/checkout

2 · HTTPS listener :443

Protocol and port accept the connection. ACM certificate and TLS policy apply; TLS terminates here. Optional mutual TLS can verify a client certificate.

3 · AWS WAF on this ALB

A regional web ACL can allow, block, count, CAPTCHA, or challenge an HTTP request. A blocked request returns without calling an application target.

Priority 10 · MATCHEDHost = shop.example.com AND path = /checkout*forward → checkout-tg
Priority 20 · path = /static/*forward → static-tg · skipped for this request
Default · no conditionsforward → storefront-tg · runs only when no custom rule matches

4 · checkout-tg selects a target

IP targets · HTTPS :8443 · HTTP/1.1 in this example. The target group’s configured algorithm chooses among eligible targets.

✓ HEALTHY · SELECTED10.0.21.18:8443 · AZ-aseparate backend TLS connection
× UNHEALTHY · EXCLUDED10.0.22.41:8443 · AZ-bTarget.Timeout

Listener and rule options

HTTP can redirect to HTTPS. Conditions include host, path, header, method, query, and source IP. Actions include forward, redirect, fixed response, and supported authentication or JWT validation features.

Target-group controls

Targets can be instance, IP, or Lambda. Configure protocol version, routing algorithm, health checks, stickiness, slow start where supported, and deregistration delay.

Network and operations

Use subnets across at least two Availability Zones in a standard Region. Observe access logs, WAF logs, target health, latency, and ALB versus target-generated HTTP status metrics.

Behavior to keep in mind. If every registered target in a group is unhealthy, ALB fails open to those targets. Weighted forward actions do not automatically fail over from an empty or unhealthy target group. With an HTTPS backend, ALB encrypts the target connection but does not validate the target certificate.
Three distinct steps: the listener receives the request, the first matching rule selects an action and target group, and the group selects a healthy target.

[!NOTE] Common misconception: the target group inspects the URL. Correct model: the listener rule selects the target group.

Use NLB for transport protocols or zonal static IPs

Use NLB for TCP, TLS, UDP, TCP_UDP, QUIC, or TCP_QUIC services; for TLS pass-through; or when allowlists require a stable address per enabled Availability Zone. NLB maps a transport flow without reading an HTTP path. It can also target an ALB directly, or publish a service to interface VPC endpoints through PrivateLink—the arrows and target types matter.

Example · deploy a TCP service

Use NLB for a TCP service with a stable zonal address

The client connects to a listener, the listener forwards to a target group, and NLB selects a healthy target for that connection. It does not read an HTTP hostname or URL path.

1Client opens a connection203.0.113.24:51514TCP → 198.51.100.10:443
2
Network Load Balancerpayments-nlb
Zonal address
198.51.100.10
Listener
TCP :443
Forwards to
tcp-service-tg

Reads the transport flow—not Host or /checkout.

3Target group · TCP :8443tcp-service-tg
selected10.0.21.18:8443HEALTHY
excluded10.0.22.41:8443UNHEALTHY
Why NLB fits: the service only needs TCP forwarding and a stable address in this Availability Zone. There is no HTTP rule for NLB to evaluate.

What stays together?

NLB maps a transport connection to a target. AWS does not publish the target-selection formula.

Existing connectionsource port 51514

Packets 1, 2, and 3 continue to 10.0.21.18:8443.

New connectionsource port 51515

Selection runs again and may choose another healthy target.

TCP listener :443encrypted bytes → target

The target can terminate TLS. NLB does not need to decrypt the HTTP request.

TLS listener :443TLS ends at NLB → backend connection

NLB uses the configured target-group protocol for the target-side connection.

Client address is conditional. Instance targets and several protocol combinations preserve it by default. TCP/TLS IP targets have different defaults and use preserve_client_ip.enabled; topology restrictions also apply.
Common compositions

Follow the arrows: NLB, ALB, and VPC endpoints

These patterns solve different problems. The target-group type tells you what NLB can actually forward to.

NLBtarget type: albALB
NLB → ALB is a direct target type

Use it when the same entry needs NLB features—such as zonal static addresses or PrivateLink—and ALB still needs to route HTTP requests.

Configure: TCP target group of type alb; one ALB per target group; matching ports. Both load balancers must be in the same VPC and account, and the hop uses IPv4.
Interface VPCEendpoint serviceNLB
PrivateLink normally flows VPCE → NLB

Use this to publish your service privately to consumer VPCs. The consumer creates an interface endpoint; your endpoint service is associated with the provider NLB.

Do not model this as NLB → VPCE. For consumer traffic, the endpoint is the entrance and NLB is on the provider side.
NLBtarget type: ipVPCE ENI IPs
Literal NLB → VPCE is an IP-target pattern

Use this only for a specific interface-endpoint bridge where the endpoint service and protocol support the path. NLB has no vpce target type.

You own the plumbing: register reachable endpoint ENI private IPs, keep registrations aligned with endpoint lifecycle, and verify health checks, security groups, TLS hostname/SNI, and Availability Zone coverage.

Listener and target protocols

Listeners support TCP, TLS, UDP, TCP_UDP, QUIC, and TCP_QUIC. Target-group combinations vary by listener protocol; only a TCP listener can forward to an ALB target.

Flow and connection controls

Flow mapping uses transport fields. Configure cross-zone load balancing, deregistration delay, source-IP stickiness where supported, Proxy Protocol v2, and client-IP preservation with care.

Network and operations

Security groups can filter NLB traffic when attached. Observe healthy targets, zonal health, active and new flows, reset counts, processed bytes, port allocation errors, and TLS negotiation errors.

Behavior to keep in mind. If all registered targets are unhealthy, NLB can fail open to them. DNS may remove an unhealthy zone before its cached address expires. Existing transport connections are not automatically recreated on another target.
Configure it this way: create the client-facing listener, forward it to a compatible target group, register healthy targets in every enabled zone, and plan for one NLB address per zone.

Use GWLB to insert a firewall fleet

Use GWLB when a route must send traffic through third-party firewalls, intrusion detection, or other GENEVE-capable appliances. The route table points to a zonal endpoint; GWLB selects an appliance and returns allowed traffic to the routed path.

Example · firewall inspection

Route a packet through a firewall fleet

Choose GWLB because the VPC route must insert an appliance before the packet reaches the application. Step through an allowed packet, then switch the firewall verdict to see where a dropped path ends.

Appliance result
CONSUMER VPC · 10.0.0.0/16
Ingress routeapp subnet → vpce
GWLB endpointvpce-0abc123example · zonal
Application subnet10.0.21.0/24
PrivateLink
service path
SERVICE VPC · 10.2.0.0/16
Gateway Load Balancerflow → target group
ALLOWfirewall-a10.2.11.20 · UDP 6081
firewall-bhealthy alternate for new flow
outer IPv4UDP :6081GENEVE metadatainner: 203.0.113.24 → 10.0.21.18
Step 1 · The ingress route matches

The destination route points at the zonal GWLB endpoint. The route, not the application listener, begins this detour.

1Route
2Endpoint
3Service path
4Select
5Encapsulate
6Inspect
7Return
  1. Route matches the application-subnet destination.
  2. The packet enters the zonal GWLB endpoint.
  3. The endpoint service carries it to GWLB.
  4. GWLB maps the flow to a healthy appliance.
  5. GWLB sends the original packet inside GENEVE over UDP 6081.
  6. The appliance allows or drops the packet.
  7. Allowed traffic returns through the endpoint and route to the application.

Route and endpoint ownership

A route table targets a zonal GWLB endpoint in the consumer VPC. PrivateLink connects that endpoint to the provider’s endpoint service and GWLB; the endpoint is distinct from the load balancer.

Flow stickiness and symmetry

Five-tuple stickiness is the default for TCP/UDP flows. Stateful appliances need both directions of a flow to traverse the expected inspection path; Transit Gateway appliance-mode designs add their own constraints.

Appliance and operations

Appliances must support GENEVE and allow UDP 6081. Observe target health, appliance capacity, dropped packets, route tables, flow logs, and forward/return-path symmetry.

Behavior to keep in mind. By default, an existing flow stays on its appliance even after that target becomes unhealthy; configurable target failover can rebalance. If every appliance target is unhealthy, GWLB still selects one and traffic can drop.
GWLB’s target is the appliance. The application remains beyond the inspection return path.

[!NOTE] Common misconception: GWLB replaces the ALB or NLB. Correct model: route tables and an endpoint insert an appliance hop; allowed traffic continues toward the application entry.

Use Global Accelerator for multi-Region entry

Use a standard accelerator when clients need static anycast addresses and new connections should move between healthy regional ALB or NLB endpoints. Global Accelerator chooses the Region and endpoint; the regional load balancer still chooses the application target.

Example · multi-Region application

Use the same client addresses during regional failover

Choose Global Accelerator because clients need stable anycast addresses and new connections must move to another healthy Region. The ALB in that Region still handles HTTP routing.

Internet clientsglobal entry
192.0.2.10192.0.2.20ILLUSTRATIVE ADDRESSES
AWS EDGEGA listenerTCP :443
ap-south-1 · Mumbai
✓ HEALTHYDIAL 100
Endpoint groupregional selection
ALBregional request routing
eu-west-1 · Ireland
✓ HEALTHYDIAL 100
Endpoint groupfailover candidate
ALBregional request routing
Global decision · Global AcceleratorChoose a healthy endpoint group and endpoint for a new connection.
Regional decision · ALBEvaluate HTTP listener rules, choose a target group, then a healthy target.
New connections → Mumbai ALB Normal simplified path: the endpoint is healthy with dial 100%. Configuration changes do not migrate established connections.
When nothing is healthy

If Global Accelerator cannot find a healthy, positive-weight endpoint through its documented failover search, it can route to a random endpoint in the closest endpoint group. That is fail open, not a healthy result.

Addresses and listeners

A standard accelerator provides static anycast addresses. TCP and UDP listeners define accepted ports or ranges; AWS edge locations carry traffic onto the AWS global network.

Endpoint groups and controls

Each endpoint group belongs to one Region. Traffic dials adjust traffic already directed to a group; endpoint weights divide that group’s traffic among endpoints.

Health, TLS, and client IP

ALB and NLB endpoint health comes from Elastic Load Balancing. The regional endpoint terminates application TLS. Client-IP preservation depends on endpoint type and configuration and can change the VPC security path.

Behavior to keep in mind. Dial and weight changes apply to new connections. When no healthy positive-weight endpoint is found through the documented failover search, Global Accelerator can fail open to an endpoint in the closest group.
The two decisions remain separate: Global Accelerator selects the regional endpoint; the ALB or NLB selects an application target.

[!NOTE] Common misconception: a 50% traffic dial means half of all listener traffic, and changing it moves existing connections. Correct model: the dial applies to traffic already directed to that endpoint group, and updates affect new connections.

Check what happens when targets become unhealthy

A failed check changes one selector’s eligible set. It does not prove that the full request path has failed—or recovered.

What failure changes

What happens when a target becomes unhealthy?

Read across each row to see who detects failure, where new traffic goes, what happens to existing traffic, and why an all-unhealthy fail-open state is not recovery.

Layer
Health boundary
New traffic
Existing traffic
Every candidate unhealthy
ALB
Target in target groupObserve: reason codes, target metrics
Select another healthy target
Depends on protocol and draining context
FAIL OPENRoutes to all targets in the affected group
NLB
Target plus zonal thresholdObserve: zonal health, target metrics
Avoid target; zonal DNS/routing can change
Do not assume migration; reset/drain varies
FAIL OPENCan route to unhealthy registered targets
GWLB
Appliance targetObserve: target health, packet loss
Select a healthy appliance
Default keeps its appliance; failover is configurable
FAIL OPENPicks an unhealthy target; traffic may drop
Global Accelerator
Standard endpoint / endpoint groupObserve: endpoint and app health
Select another healthy endpoint
Dial changes do not terminate it
FAIL OPENSearch can end at a random endpoint in closest group
Why “fail open” is not recovery

The service stops excluding every failed candidate because exclusion would leave no route. The selected target can still reject, time out, or drop traffic. Alert on the original health loss and the resulting request outcome.

Separate new from existing traffic. A health or dial change often affects the next selection; it does not teleport an established connection to a new target.

Choose a deployment pattern and test failures

Each extra selector adds a health boundary. Give every service one explicit job, then test what crosses the boundary when it fails.

Deployable starting points

Three common deployment patterns

Start with the smallest path that meets the requirement. Add another service only when it contributes a distinct capability.

Client → ALB → HTTP services
Choose this whenA regional HTTP entrance needs content-aware routing.
VerifyRules, target health, TLS boundaries, and the all-targets-unhealthy drill.
Client → Global Accelerator → ALB Region A / B → services
Choose this whenYou need stable global entry plus health-based regional choice and HTTP routing.
VerifyEndpoint health inheritance, client IP behavior, and new-connection failover.
Client → routed GWLB inspection → NLB or ALB → targets
Choose this whenA routed path must traverse a scalable appliance fleet before application entry.
VerifyForward and return routes, AZ placement, flow symmetry, and appliance failure.
01 DEFINEProtocol, scope, identity, and failure boundary.
02 ROUTEMap DNS, listeners, zones, routes, and trust.
03 HEALTHProbe a condition that represents useful service.
04 OBSERVECorrelate endpoint, target, flow, and app evidence.
05 BREAKTest one target, one zone, one appliance, one Region.
06 REFINERight-size capacity and remove redundant hops.
Inspection-path caveat · verified 2026-09-10. AWS documents that Global Accelerator traffic with client-IP preservation enabled bypasses GWLB endpoints, AWS Network Firewall, and NACL evaluation. Validate the exact ingress path before claiming inline inspection.
Monitor the full decision chain: edge endpoint health, regional load-balancer health, appliance health where used, and the application outcome seen by a synthetic client.
Authoritative references

Sources and documentation