Gateway Load Balancer (GWLB): The Transparent Inspection Problem

Why Inserting a Firewall Is Hard

Imagine you are a security guard at a building entrance. Your job is to check every person's ID before they enter. Simple enough. Now imagine the building has 10 entrances, 10,000 people per minute, and if you are sick, no one can enter at all. That is the problem enterprises face when inserting security appliances into network traffic paths.

Enterprises are contractually or regulatorily required to inspect traffic using specific third-party appliances — Palo Alto Networks, Fortinet, Cisco Firepower. These are not software you can just run anywhere; they are licensed, stateful appliances that need to see both directions of a TCP flow to function correctly.

The naive approach — routing traffic to a single EC2 instance running the firewall software — creates three problems:

1. Single Point of Failure (SPOF): If that instance crashes, all traffic stops.
2. No horizontal scaling: You cannot simply add more firewall instances and split traffic arbitrarily. Firewalls are stateful — both the request and the response for a given TCP connection must go through the same firewall instance.
3. IP rewriting: Traditional load balancers perform Source NAT (SNAT), replacing the client's real IP with the load balancer's IP. The firewall — and ultimately the application — loses visibility into who the real client is.

How GWLB Solves All Three Problems

Gateway Load Balancer (GWLB) is a purpose-built AWS service that operates at Layer 3 (the Network layer) of the OSI model. It is simultaneously a transparent network gateway and a load balancer. It solves the three problems above as follows:

Problem 1 (SPOF) → Managed fleet: GWLB distributes traffic across a fleet of firewall appliances registered as targets. If one appliance fails, GWLB health checks detect it and stop sending traffic to it within seconds.

Problem 2 (Statefulness) → Flow stickiness: GWLB uses a 5-tuple hash (Source IP, Destination IP, Source Port, Destination Port, Protocol) to ensure that all packets belonging to the same TCP/UDP flow always go to the same firewall appliance for the lifetime of the connection. The firewall sees a coherent, ordered stream.

Problem 3 (IP rewriting) → GENEVE encapsulation: This is the key innovation. GWLB uses the GENEVE (Generic Network Virtualization Encapsulation) protocol (UDP port 6081) to wrap the original packet inside a new outer packet. The original packet — with the real client IP — is preserved intact inside the GENEVE envelope. The firewall appliance receives the GENEVE packet, strips the outer header, and inspects the original packet with the real source IP visible. After inspection, it re-encapsulates and returns the packet. GWLB strips the GENEVE header and forwards the original packet to its destination.

The result: the application server receives a packet with the original client IP address in the source field — exactly as if no load balancer existed in the path.

The GWLB Endpoint (GWLBe): The Wormhole

The GWLB itself lives in a Security VPC — a dedicated VPC that contains only the firewall fleet. Your application lives in a separate Application VPC. How does traffic cross VPC boundaries transparently?

The answer is the GWLB Endpoint (GWLBe), which is built on AWS PrivateLink technology. You deploy a GWLBe in a subnet of your Application VPC. It appears as a regular VPC endpoint — just an IP address in your subnet. But when traffic is sent to it, it is tunneled via PrivateLink to the GWLB in the Security VPC, inspected, and returned.

You then modify your VPC Route Tables to redirect traffic through the GWLBe:

• In the IGW Ingress Route Table (attached to the Internet Gateway itself): route the Application subnet CIDR to the GWLBe. This intercepts inbound traffic before it reaches the application.
• In the Application Subnet Route Table: route 0.0.0.0/0 to the GWLBe. This intercepts outbound traffic before it reaches the IGW.

This creates a symmetric inspection path: all traffic in both directions passes through the firewall fleet.

Key Point — GWLB is not a traditional load balancer. It does not terminate connections, does not perform SSL offload, and does not understand HTTP. It is a pure Layer 3 bump-in-the-wire. If you need HTTP-aware load balancing, that is the Application Load Balancer (ALB). GWLB's job is to make a fleet of third-party appliances look like a single, highly available, transparent network device.