Elastic Load Balancing · ALB · NLB · GWLB

Pick the load balancer that matches your traffic's layer

Elastic Load Balancing distributes incoming traffic across healthy targets in multiple Availability Zones. Application Load Balancer handles HTTP requests, Network Load Balancer handles TCP and UDP connections, and Gateway Load Balancer handles IP packets bound for security appliances. This page covers the shared concepts and a comparison table, then walks through each of the three types.

Compare types Start with ALB
OSI layerLoad balancer
  1. L7ApplicationHTTP · HTTPS · HTTP/2 · gRPCALB
  2. L6Presentation
  3. L5Session
  4. L4TransportTCP · UDP · TLS · QUICNLB
  5. L3NetworkAll IP packets · GENEVE 6081GWLB

All three types use the same building blocks: listeners, target groups, and health checks.

3

Load balancer types (ALB · NLB · GWLB)

6081

GENEVE port between GWLB and appliances

8500

Maximum packet size on GWLB interfaces (bytes)

mTLS

ALB mutual TLS authentication (passthrough · verify)

Common building blocks

One entry point, no matter how many targets come and go

A load balancer continuously checks target health and sends traffic only to healthy targets. When Auto Scaling groups or containers change, the address clients use stays the same. All three types share the building blocks below.

Listener

Listeners

A listener accepts connections on a protocol and port and passes them to target groups according to its rules. A GWLB has exactly one listener, with no protocol or port.

Target group

Target groups

You choose a target type such as instance or ip and register targets. The target type can't be changed after creation, and each target group has its own health checks and attributes.

Health check

Health checks and fail open

Traffic goes only to healthy targets, but if no target is healthy, it goes to all targets. For ALB and NLB, you can set DNS failover and routing failover thresholds as a minimum count or percentage of healthy targets.

Cross-zone

Cross-zone load balancing

When enabled, each node distributes traffic across targets in all Availability Zones. It is always on at the load balancer level for ALB and off by default for NLB and GWLB.

Deregistration delay

Deregistration delay

A deregistered target enters the draining state to finish in-flight requests. The default is 300 seconds, after which it becomes unused.

LCU reservation

Capacity unit reservation

Reserve minimum capacity ahead of an expected surge. After reserving, the load balancer still scales with traffic but never below the reservation. NLB and GWLB count 1 LCU as 2.2 Mbps.

Type selection

ALB · NLB · GWLB compared

The deciding factor is which layer of the traffic you need to inspect to make a decision.

Comparison of Application, Network, and Gateway Load Balancers
ItemALBNLBGWLB
OSI layerL7 · per requestL4 · per connection · flowL3 · per packet (transparent gateway)
Listener protocolsHTTP · HTTPSHTTP/2 · gRPC on HTTPS listenersTCP · TLS · UDP · TCP_UDP · QUIC · TCP_QUICIP packets on all portsGENEVE (UDP 6081) to appliances
Target typesinstance · ip · lambdainstance · ip · albinstance · ip
Target selectionround robin (default), least outstanding requests, weighted randomFlow hash on protocol, IPs · ports, and TCP sequence number5-tuple (default), 3-tuple, or 2-tuple flow stickiness
Static IPReached by DNS name. For static IPs, put the ALB behind an NLBStatic IP per Availability Zone; Elastic IPs for internet-facingGWLB endpoint set as next hop in route tables
Security groupsAssociated with the load balancerCan be changed later only if associated at creationNone. Controlled by appliance security groups · NACLs
TLSTerminated on HTTPS listeners, mTLS supportedTerminated on TLS listeners (ALPN policy), or passed through as TCPNot terminated. Packets go to appliances unchanged
Cross-zone load balancingAlways on. Can be turned off at the target group levelOff by defaultOff by default
Typical useWeb · APIs · microservices, authentication at the frontHigh-performance TCP · UDP, static IPs, PrivateLink servicesInline inspection such as firewalls and IDS/IPS

Application Load Balancer · L7

ALB routes each HTTP request on its own merits

ALB accepts and terminates the client connection, chooses a target group based on the request's host, path, headers, method, query string, and source IP, and then sends the request to the target over a separate connection.

  1. Connection · TLS termination — The client connects to the ALB's DNS name, and the HTTPS listener terminates TLS with an ACM certificate. With SNI, you can add up to 25 certificates besides the default certificate.
  2. Rule evaluation — Listener rules are evaluated in priority order. The first matching rule runs its authentication, JWT validation, and transforms, then one of forward, redirect, or fixed-response.
  3. Target selection — The target group's routing algorithm picks a healthy target. With sticky sessions enabled, the request goes to the target the cookie points to.
  4. Delivery — The request goes to EC2, a container IP, or a Lambda function, and the response returns to the client.
A client connects to the ALB HTTPS listener, and the ALB splits requests across instance, ip, and lambda target groups by path rule VPC ClientHTTPS ALBHTTPS:443 1 host · path 2 header · method * default tg-webinstance tg-apiip · container tg-fnlambda /* /api/* /fn/*

When to use

  • Splitting microservices and containers by host and path
  • Handling OIDC · Amazon Cognito sign-in or JWT validation in front of the application
  • Blue/green and canary deployments with weighted target groups
  • Exposing Lambda functions as HTTP endpoints, or load balancing gRPC · WebSocket
100

Rules per ALB (excluding default rules, adjustable)

5

Target groups per forward action

1,000

Targets per ALB (adjustable)

50

Listeners per ALB (adjustable)

ALB · Listener rules

Listener rules: when the conditions match, the actions run

Listener rules are evaluated from the lowest priority number, and the first matching rule's actions run. There are six condition types: host-header, path-pattern, http-header, http-request-method, query-string, and source-ip. host-header, path-pattern, and http-header can also match with regular expressions instead of wildcards.

Priority · Condition · Actionlistener HTTPS:443
1priority
host-header api.example.com
path-pattern /v2/*
forward tg-v2 weight 90
tg-v1 weight 10
2priority
path-pattern /admin/*
source-ip 192.0.2.0/24
authenticate-oidc
forward tg-admin
3priority
http-header X-Client-Version: 1.*
fixed-response 426
4priority
path-pattern /old-docs/*
redirect HTTP_301
host docs.example.com · path /#{path}
*default
When no other rule matches
forward tg-web

Each rule must end with exactly one routing action: forward, redirect, or fixed-response. On HTTPS listeners, authenticate-cognito, authenticate-oidc, and jwt-validation actions can come before it. Non-default rules can each carry one transform per type (host-header-rewrite, url-rewrite) that rewrites the request before it reaches the target. A rule can have up to 5 condition values and 6 wildcards.

ALB · Features

Authentication, deployments, and sessions handled at the load balancer

Authentication

OIDC · Cognito authentication

The authenticate-oidc · authenticate-cognito actions in HTTPS listener rules handle sign-in and pass the authenticated user's claims to targets in headers.

JWT validation

JWT validation

The jwt-validation action verifies the signature with public keys from a JWKS endpoint and checks iss and additional claims. The JWKS response can be up to 150 KB and 10 keys.

mTLS

Mutual TLS authentication

Verify mode validates client certificates against the CAs in a trust store; passthrough mode passes the certificate chain to targets in a header. Each ALB supports 2 listeners in verify mode.

Transforms

URL · host header rewrite

A rule's transform uses regular expressions to rewrite the path, query string, and Host header before sending to the target. You can migrate URL schemes without application code changes or a separate proxy.

Weighted target groups

Weighted target groups

A single forward action splits requests by weight across up to 5 target groups. With target group stickiness enabled, a client stays in the group it was first assigned to.

Sticky sessions

Sticky sessions

Requests go to the same target using the ALB-generated AWSALB cookie (duration-based) or an application cookie (application-based). Not available on target groups with cross-zone load balancing turned off.

Algorithms · Slow start

Routing algorithms and slow start

Slow start ramps up a new target's share of requests linearly over 30–900 seconds (round robin only). With weighted random, ATW automatically reduces traffic to targets whose error rates spike.

Lambda targets

Lambda function targets

The ALB converts the HTTP request into a JSON event and invokes the function. A lambda target group holds a single function, and the function's response JSON can be up to 1 MB.

HTTP/2 · gRPC

gRPC and WebSocket

Set the protocol version of a target group behind an HTTPS listener to gRPC or HTTP2 to forward that traffic as is. A WebSocket connection stays on the target that accepted the upgrade.

With Target Optimizer enabled, an agent installed on each target enforces a maximum number of concurrent requests per target. It can be enabled only when you create the target group; once enabled, the algorithm is round robin only and sticky sessions aren't supported.

Network Load Balancer · L4

NLB forwards L4 traffic connection by connection

NLB pins each TCP · UDP flow to one target using a flow hash and has a static IP in each Availability Zone. Unless the listener is TLS, it passes traffic through without opening the payload, and it scales to handle millions of requests per second.

  1. DNS · zonal IPs — The DNS name resolves to NLB node IPs, one per enabled Availability Zone. dns_record.client_routing_policy sets the same-zone affinity to 100, 85, or 0%.
  2. Flow stickiness — The node picks a target from the protocol, source and destination IPs and ports, and TCP sequence number, and keeps sending to that target until the connection ends.
  3. Delivery — Depending on configuration, targets receive the original client IP. A TLS listener terminates TLS on the NLB and opens a new connection to the target.
  4. Idle timeout — TCP defaults to 350 seconds (configurable from 60 to 6,000), TLS is fixed at 350 seconds, and UDP is fixed at 120 seconds.
Clients and PrivateLink endpoints connect to the NLB's per-AZ IPs, and the NLB pins each flow to a target in each zone ClientTCP · UDP EndpointConsumer VPC NLBTCP · UDP · TLS · QUIC AZ-aEIP 203.0.113.10 AZ-bEIP 203.0.113.20 PrivateLink Target AAZ-a · instance Target BAZ-b · ip flow hash · sticky flows client IP preserved

When to use

  • Partners need static IPs · Elastic IPs to allow in their firewalls
  • Services that use UDP or QUIC, such as gaming, IoT, and VoIP
  • Offering a service to other VPCs · accounts as an AWS PrivateLink endpoint service
  • Putting static IPs in front of an ALB, or terminating TLS for non-HTTP TCP protocols
3,000

Targets per NLB (500 with cross-zone load balancing)

500

Targets per Availability Zone per NLB (adjustable)

350s

Default TCP idle timeout

50

Listeners per NLB

NLB · Features

Static IPs, source IPs, and PrivateLink together

Protocols · QUIC

TCP · UDP · TLS · QUIC

QUIC · TCP_QUIC listeners pass QUIC v1 traffic to targets without decryption. They pin targets by the Server ID in the Connection ID, so mobile clients keep their sessions across connection migration.

Static IP

Static IPs and Elastic IPs

NLB nodes have a static IP in each Availability Zone. An internet-facing NLB can attach one Elastic IP per subnet, so clients can keep a fixed allow list.

Source IP

Client IP preservation

By default it is on for instance targets and off for TCP · TLS on ip targets. It can't be turned off for UDP · TCP_UDP · QUIC · TCP_QUIC. It doesn't work for targets reached through Transit Gateway, so use Proxy Protocol v2 to pass the IP.

PrivateLink

Front end for endpoint services

Register the NLB as a VPC endpoint service, and interface endpoints in consumer VPCs connect to the NLB. You can choose whether security group inbound rules apply to PrivateLink traffic.

Security groups

Security groups

You must associate a security group at creation to be able to change it later. Referencing the NLB security group as the source in target security groups allows both data and health check traffic.

TLS · ALPN

TLS termination and ALPN

A TLS listener terminates TLS with an ACM certificate and a security policy. Choose an ALPN policy from HTTP1Only, HTTP2Only, HTTP2Optional, HTTP2Preferred, and None.

Weighted TG

Weighted target groups

A single NLB listener splits traffic across multiple target groups with weights from 0 to 999. It works with instance, ip, and alb target groups, which suits blue/green and canary deployments.

Zonal shift · DNS failover

Handling zonal failures

ARC zonal shift takes one Availability Zone out of traffic. When a zonal health check fails, that zone's DNS record is removed; check it with the ZonalHealthStatus metric.

ALB as target

Registering an ALB as a target

Register one ALB in an alb target group to put static IPs and PrivateLink in front of it. For quota purposes, one ALB counts as 50 targets (100 with cross-zone load balancing).

On a dual-stack NLB, you can add listener rules besides the default rule to send traffic to different target groups based on the source IP address type (IPv4 · IPv6). Each rule must have one forward action.

Gateway Load Balancer · L3

GWLB inserts appliances into the traffic path

GWLB receives IP packets on all ports, encapsulates them in GENEVE, and distributes them across a fleet of virtual appliances such as firewalls, IDS/IPS, and DPI. It acts as a transparent gateway, a single entry and exit point, and scales the number of appliances with demand.

  1. Steer with routing — Route tables in the application VPC (including IGW edge routing) point to the GWLB endpoint as the next hop. Place the endpoint and application servers in different subnets.
  2. PrivateLink — The GWLB endpoint sends traffic to the GWLB in the service provider VPC. The GWLB is in the same VPC as the appliances.
  3. GENEVE encapsulation — The GWLB picks an appliance by flow hash and sends the original packet wrapped in GENEVE (UDP 6081). Encapsulation adds 68 bytes.
  4. Return after inspection — Packets the appliance returns over GENEVE pass back through the GWLB and endpoint to their original destination. Return traffic must follow the same path.
Traffic entering through the internet gateway is routed to the GWLB endpoint; the GWLB in the security VPC distributes it to two appliances over GENEVE, and inspected traffic continues to the application server APPLICATION VPC SECURITY VPC IGWedge route table GWLB endpointroute next hop App serverALB · EC2 inspected GWLBlistener: all IP packets PrivateLink FW Atarget FW Btarget GENEVE · UDP 6081 5-tuple flow stickiness MTU 8,500 bytes

When to use

  • Inspecting internet inbound · outbound traffic with third-party firewalls
  • Centrally inspecting VPC-to-VPC and on-premises traffic through Transit Gateway
  • Sharing one appliance fleet across many VPCs and accounts
  • Scaling appliances horizontally while keeping flows symmetric without SNAT
6081

GENEVE target group protocol · port

8,568

Appliance MTU needed to receive 8,500-byte packets

300

Targets per GWLB (not adjustable)

1

Listener per GWLB

GWLB · Features

Flow symmetry and failover are central to the design

GENEVE

GENEVE encapsulation

The GENEVE header carries flow information in a TLV with Option Class 0x0108, and the appliance decapsulates it to process the original packet. Dual stack also uses an IPv4 GENEVE header.

MTU

MTU and fragmentation

GWLB interfaces accept packets up to 8,500 bytes and drop larger ones. GWLB doesn't support IP fragmentation and doesn't generate "fragmentation needed" ICMP messages, so PMTUD doesn't work.

GWLB endpoint

Gateway Load Balancer endpoint

A VPC endpoint that serves as a route table next hop. It uses PrivateLink to connect consumer VPCs to appliances in the provider VPC, so multiple VPCs and accounts share one inspection fleet.

Flow stickiness

5 · 3 · 2-tuple flow stickiness

The default is 5-tuple; you can switch to source_ip_dest_ip_proto (3-tuple) or source_ip_dest_ip (2-tuple). With 3- or 2-tuple, the idle timeout can't be changed.

Target failover

Existing flows on target failure

Set target_failover to rebalance to move existing flows to another target when a target becomes unhealthy or is deregistered. The default is no_rebalance, and both attributes must have the same value.

Idle timeout

Idle timeout

TCP flows default to 350 seconds (60–6,000 seconds), and UDP is fixed at 120 seconds. If you raise it above 350 seconds, set the target ENI's connection tracking timeout to at least the same value.

TGW appliance mode

Transit Gateway appliance mode

With appliance mode enabled on the security VPC attachment, the TGW picks one ENI by flow hash and keeps both directions of traffic in the same Availability Zone. Attach only one TGW to the security VPC.

Route design

Centralized inspection routing

Spoke VPCs send the default route to the TGW, and the TGW sends it to the security VPC attachment. In the security VPC, the TGW attachment subnet routes to the GWLB endpoint, and the endpoint subnet routes back to the TGW.

Partners

Partner appliances

Vendors registered as ELB partners have integrated and validated their appliances with GWLB. However, choosing and validating the appliance software remains your responsibility.

GWLB allows asymmetric flows where the return traffic of a flow whose first packet it processed bypasses the GWLB, but this isn't recommended. Flows where only the return traffic reaches the GWLB, without the GWLB seeing the first packet, aren't supported.

Reference architecture · ALB

One ALB from the edge to containers, instances, and Lambda

Requests that pass through CloudFront and AWS WAF arrive at an internet-facing ALB spanning two AZs, which accepts them with an ACM certificate. Listener rules split them by host · path condition across ECS Fargate, EC2, and Lambda target groups, authenticating first with Cognito · OIDC when required.

Application Load Balancer reference architecture Users' HTTPS requests pass through CloudFront with an AWS WAF web ACL attached and reach an internet-facing ALB spanning public subnets in two Availability Zones. The ALB runs an HTTPS 443 listener with an ACM certificate and, based on the listener rules' path · host conditions, sends requests to ECS Fargate tasks (ip target group) and EC2 instances in an Auto Scaling group (instance target group) in each AZ's private subnet, and to a Lambda function outside the VPC (lambda target group). The ALB authenticates users with Amazon Cognito or an OIDC IdP and stores access logs in an S3 bucket. INTERNET AWS EDGE REGION VPC AZ A AZ B PUBLIC SUBNET PRIVATE SUBNET PUBLIC SUBNET PRIVATE SUBNET UsersHTTPS CloudFrontorigin: ALB AWS WAFweb ACL ALBHTTPS:443 ACM certificate ECS Fargate taskpath /api/* · ip TG EC2 · Auto Scalinghost www.* · instance TG EC2 · Auto Scalinghost www.* · instance TG ECS Fargate taskpath /api/* · ip TG S3access logs Lambdapath /fn/*lambda TG Cognito · OIDC IdPauthenticate action Targets in each AZ · Lambda invoked outside the VPC
Request path (→ request direction, target group per rule) Calls made by the ALB (IdP authentication · S3 access logs) Association (CloudFront ↔ web ACL)

On narrow screens, swipe the diagram sideways.

Reference architecture · NLB

Expose L4 services with static IPs and PrivateLink

An internet-facing NLB attaches one Elastic IP per AZ, so on-premises firewalls can build allow lists from static IPs. Targets can be EC2 instances, IPs, or an ALB, and other accounts are served over PrivateLink by an internal NLB set up as an endpoint service.

Network Load Balancer reference architecture On-premises and internet clients connect over TCP, UDP, and TLS to an internet-facing NLB with an Elastic IP in each AZ, and the NLB sends connections to an EC2 instance target group, an ip target group, and an alb target group. An application in a consumer VPC in another account connects through an interface endpoint over PrivateLink to an internal NLB, the endpoint service in the provider VPC, which sends traffic to EC2 targets. Connections are initiated only from the consumer side. INTERNET · ON-PREMISES CONSUMER ACCOUNT CONSUMER VPC PROVIDER ACCOUNT PROVIDER VPC PUBLIC SUBNETS PRIVATE SUBNETS PRIVATE SUBNETS On-premisesEIP allow list Clientsinternet TLS:443 TCP · UDP NLBinternet-facing TCP · UDP · TLS EIP · AZ a EIP · AZ b EC2 · instance TGTCP · client IP preserved (default on) IP targets · ip TGUDP · client IP always preserved ALB · alb TGTCP · L7 routing behind static IPs ip TG TCP · TLS: client IP preservation off by default · targets in AZ a · AZ b Appconsumer Endpointinterface Endpoint ENI per AZ · private IP Internal NLBendpoint service EC2 · instance TGTCP 443 · AZ a · AZ b PrivateLink · only the consumer initiates Source IP of traffic via the endpoint is the NLB private IP → client IP · vpce ID passed in a Proxy Protocol v2 header
Connection path (→ connection direction) PrivateLink (consumer → endpoint service, one-way initiation)

On narrow screens, swipe the diagram sideways.

Reference architecture · GWLB

Inspect ingress and egress with one appliance fleet

The GWLB in the security VPC serves as an endpoint service, and each VPC uses its GWLB endpoint as a route next hop. IGW ingress routing sends inbound traffic, and Transit Gateway sends spoke VPC outbound traffic, to the endpoints; only traffic that has passed through the appliances reaches its destination.

Gateway Load Balancer centralized inspection reference architecture Inbound: when internet users' traffic arrives at the application VPC's internet gateway, the ingress route table sends traffic bound for the application subnet to the GWLB endpoint. The GWLB endpoint sends it over PrivateLink to the Gateway Load Balancer in the security VPC, and the GWLB distributes it over GENEVE UDP 6081 to firewall appliances in an Auto Scaling group. Inspected traffic returns to the same GWLB endpoint and continues to the application. Egress: spoke VPC traffic passes through Transit Gateway into the egress VPC attachment with appliance mode enabled, goes from the GWLB endpoint through the GWLB and appliances and back, then exits to the internet through a NAT gateway and internet gateway. INTERNET APPLICATION VPC · INGRESS GWLBE SUBNET APP SUBNET SPOKE VPC A SPOKE VPC B EGRESS VPC SECURITY VPC · PROVIDER UsersHTTPS IGWingress RT IGW route table app subnet → vpce GWLB endpointone per AZ Applicationafter inspection PrivateLink EC20/0 → TGW EC20/0 → TGW TransitGateway spoke 0/0 →egress VPC Attachmentappliance mode GWLB endpointTGW subnet → vpce NAT gatewaypublic subnet IGW0/0 → internet Internet Gateway Load Balancerendpoint service GWLBe in many VPCs · accounts share one fleet ASG FirewallAZ a FirewallAZ b GENEVE UDP 6081 Third-party appliances 5-tuple flow stickiness
Inspection path (GWLB endpoint ↔ GWLB, two lines out and back) GENEVE encapsulation (appliance round trip) Regular traffic (→ direction of travel)

On narrow screens, swipe the diagram sideways.

Getting started

Setup sequence

All three types are built in the same order. The differences are the listener protocol and target type, plus, for GWLB, the endpoints and route tables.

  1. 01

    Type and subnets

    Choose a type from the comparison table and pick one subnet per Availability Zone. Decide on internet-facing or internal and the IP address type (IPv4 · dual stack) at this point.

  2. 02

    Security groups

    Associate security groups with the ALB and NLB. For an NLB, associate them at creation to be able to change them later. For GWLB, allow GENEVE 6081 in the appliance security groups.

  3. 03

    Target groups · health checks

    Choose the target type and protocol and register targets. Tune attributes such as the health check path, deregistration delay, and sticky sessions.

  4. 04

    Listeners · rules

    For ALB and NLB, create listeners, certificates, and rules. For GWLB, create the endpoint service and GWLB endpoints and add them to route tables as the next hop.

  5. 05

    DNS · monitoring

    Point your domain at the load balancer with a Route 53 alias record, and track target health and capacity unit usage with CloudWatch metrics and access logs.

Pricing

Pricing components

All three types are billed for load balancer hours and capacity unit (LCU · NLCU · GLCU) usage. Each hour, capacity units are calculated from whichever of several dimensions has the highest usage.

Elastic Load Balancing pricing components
ComponentWhat one capacity unit coversNotes
Load balancer hoursHours an ALB · NLB · GWLB runs (partial hours billed as full hours)Rates differ by type
ALB LCU25 new connections/s · 3,000 active connections/min · 1 GB processed/hour · 1,000 rule evaluations/sThe first 10 rules processed are free. With mTLS, 1,500 active connections/min; for Lambda targets, 0.4 GB/hour
NLB NLCUTCP 800 new connections/s · 100,000 active/min
UDP 400 new flows/s · 50,000 active/min
TLS 50 new connections/s · 3,000 active/min		Processed bytes are 1 GB/hour for all three protocols
GWLB GLCU600 new connections · flows/s · 60,000 active/min · 1 GB processed/hourGWLB endpoints are billed under AWS PrivateLink pricing for endpoint hours and GB processed
Capacity reservationReserved capacity unit-hoursWhen using Load Balancer Capacity Unit Reservation. Usage above the reservation is billed separately
Related chargesBilled by other servicesData transfer (Amazon EC2 pricing) and public IPv4 addresses used by the load balancer (Amazon VPC pricing)

Rates vary by Region and usage. For current rates, see the Elastic Load Balancing pricing page.

Next step

Decide on the right load balancer mix for your workload

Bring your protocols, static IP needs, authentication method, and inspection requirements, and we'll review the ALB · NLB · GWLB placement together.

Open the service page Read the user guide