Skip to main content
AWS Gateway Load Balancer inserts virtual network appliances into an IP traffic path without making them the visible destination. Routes send packets to a GWLB endpoint, and GWLB encapsulates them for a selected appliance. Updated October 9, 2026. GWLB handles IP packets and distributes flows to appliances; it does not route HTTP requests.

Components and boundaries

A GWLB endpoint is distinct from an interface endpoint or S3 gateway endpoint. A centralized provider VPC can serve several consumer VPCs without broad network peering.

Request and return flow

Forward and return paths should both traverse the intended inspection path. AWS supports only limited asymmetric behavior. A response cannot enter GWLB when GWLB never observed the initial flow packet. Deploy an endpoint in each Availability Zone that originates traffic to preserve zonal paths. In cross-account designs, compare Availability Zone IDs because names can differ. Route-table correctness is part of GWLB availability.

What GENEVE carries

GWLB encapsulates the complete original IP packet rather than translating its addresses. The outer transport is UDP 6081, and GENEVE options carry documented AWS metadata. Encapsulation adds 68 bytes. GWLB accepts original packets up to 8,500 bytes, so appliance interfaces must support at least an 8,568-byte MTU for the largest packet. GWLB does not fragment packets or generate the ICMP needed for Path MTU Discovery. Appliances must understand GWLB’s GENEVE format and account for encapsulation overhead.

Stickiness, symmetry, and failover

By default, TCP and UDP flows use five-tuple stickiness: source IP and port, destination IP and port, and protocol. Optional broader stickiness can correlate related connections but can concentrate traffic. Target failover is separate. Default no_rebalance behavior keeps an existing flow on its selected appliance after the target becomes unhealthy. rebalance rehashes affected flows, which can lose state in firewalls. Health failover does not automatically migrate appliance session state.

Health checks and scaling

GWLB sends TCP, HTTP, or HTTPS health checks directly to targets. These checks do not use GENEVE and therefore do not prove that the appliance can inspect and return production traffic. New flows use healthy targets. Under default policy, existing flows stay on their appliance. If all targets are unhealthy, GWLB can choose a target for new flows, but the appliance may still fail traffic. GWLB service capacity scales automatically, but appliance throughput and connection tables remain your responsibility. Cross-zone routing is disabled by default.

Operational caveats

  • Missing return routes can break a healthy target group.
  • Endpoint quotas, appliance throughput, and UDP 6081 must be monitored.
  • Changing stickiness can remap flows.
  • PrivateLink is directional; providers cannot initiate arbitrary connections through endpoints.
  • An appliance health endpoint should reflect dataplane dependencies where supported.

Frequently asked questions

No. GWLB distributes IP flows to network appliances and does not provide HTTP routing, TLS termination, or application targets. ALB or NLB can still serve the workload while routes place GWLB inspection before or after it.
Not by default. New flows use healthy targets, but established flows remain assigned to their original appliance. Enable rebalancing only after evaluating how the appliance handles missing session state and after planning traffic draining.
A GWLB endpoint is zonal. Deploying one wherever traffic originates keeps paths zonal, reduces cross-zone dependencies, and aligns each consumer zone with provider capacity. The target group still needs healthy appliances in each enabled zone.

Sources and further reading

Last modified on October 8, 2026