Key Takeaways

  • AWS Gateway Load Balancer (GWLB) transparently distributes traffic to a fleet of virtual appliances (firewalls, IDS/IPS, deep packet inspection) running on Linux EC2 instances, without the appliance needing to be in the traffic's actual network path.
  • GWLB uses the GENEVE protocol (UDP port 6081) to encapsulate original packets, preserving the source/destination so your Linux appliance can inspect real traffic, not NAT'd traffic.
  • Your Linux instances must decapsulate GENEVE, inspect/process, and re-encapsulate the return packet — this requires either vendor firewall software or custom iptables/eBPF logic.
  • GWLB pairs with VPC endpoints (Gateway Load Balancer Endpoints) to insert inspection transparently into traffic flows via route table changes — no app-level reconfiguration needed.
  • Target group health checks must pass on the GENEVE listener, not a generic HTTP check, or your appliance fleet will appear unhealthy despite working correctly.

Gateway Load Balancer exists for one specific job: letting you insert a fleet of Linux-based network appliances into traffic flows at scale, with automatic scaling and failover, without the appliance vendor needing AWS-specific integration work. Here's how the Linux side of that integration actually works.

Why GWLB Instead of a Regular NLB/ALB?

A standard load balancer routes traffic to an application. GWLB is designed to route traffic through an inspection point and back out — called "bump-in-the-wire." The appliance doesn't terminate the traffic; it inspects and forwards it.

This matters for Linux-based security appliances (Suricata, pfSense, custom DPI tools) that need to see the original, unmodified packet — source IP, destination IP, and ports exactly as a downstream service would see them — not traffic that's already been NAT'd by a conventional load balancer.

Architecture: Traffic Flow Through GWLB

Internet / Client Traffic GWLB Endpoint (VPC route insertion) Linux Appliance Fleet GENEVE decap → inspect Application / EC2 (sees original source IP)

Step 1: Create the Gateway Load Balancer

aws elbv2 create-load-balancer \
  --name appliance-gwlb \
  --type gateway \
  --subnets subnet-0abc123 subnet-0def456

Step 2: Create the Target Group with GENEVE Protocol

aws elbv2 create-target-group \
  --name appliance-targets \
  --protocol GENEVE \
  --port 6081 \
  --vpc-id vpc-0abc123 \
  --health-check-protocol TCP \
  --health-check-port 80 \
  --target-type instance

Register your Linux EC2 appliance instances:

aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:111122223333:targetgroup/appliance-targets/abc123 \
  --targets Id=i-0123456789abcdef0 Id=i-0fedcba9876543210

Step 3: Linux-Side GENEVE Decapsulation

Your appliance OS needs to handle GENEVE-encapsulated traffic on UDP 6081. Many commercial firewall AMIs handle this natively. For a custom build, a minimal approach uses a GENEVE-aware interface:

# Create a GENEVE tunnel interface for decapsulation (example using ip tools)
sudo ip link add gwlb0 type geneve id 0 remote 0.0.0.0 dstport 6081
sudo ip link set gwlb0 up

# Traffic arriving on gwlb0 is the decapsulated original packet;
# inspection software (Suricata, custom eBPF, etc.) attaches here

In production, this is almost always handled by the appliance vendor's GWLB-aware software (Palo Alto VM-Series, Fortinet FortiGate, Check Point CloudGuard all ship GWLB-ready AMIs) rather than hand-rolled — custom GENEVE handling is complex to get right for the return-path re-encapsulation step.

Step 4: Insert the GWLB Endpoint into the Route Table

aws ec2 create-route \
  --route-table-id rtb-0abc123 \
  --destination-cidr-block 0.0.0.0/0 \
  --vpc-endpoint-id vpce-0gwlbendpoint123

This is the step that makes inspection transparent — traffic destined for your application subnet is routed through the GWLB endpoint first, inspected, and forwarded, with no changes required on the application side.

Health Check Gotchas

GWLB target group health checks run against the port/protocol you specify (commonly a TCP check on a management port), not the GENEVE data path itself. A target can pass health checks while still failing to properly decapsulate/re-encapsulate traffic — always validate with real traffic through the path, not just target group status in the console.

FAQ

Q: Does Gateway Load Balancer work with any Linux firewall software? A: Only if that software supports GENEVE decapsulation and correct return-path re-encapsulation. Most major commercial firewall vendors ship GWLB-ready AMIs; custom builds require more engineering.

Q: Is GWLB the same as a Network Load Balancer with a UDP listener? A: No — GWLB is a distinct load balancer type (--type gateway) using GENEVE encapsulation specifically for transparent bump-in-the-wire traffic inspection, not general UDP load balancing.

Q: What's the performance overhead of GENEVE encapsulation? A: Minimal at the network layer, but total latency depends heavily on what your Linux appliance does with the traffic (deep packet inspection adds more overhead than a simple pass-through firewall rule).

Q: Can I scale the appliance fleet automatically? A: Yes — register your Linux instances in an Auto Scaling group tied to the GWLB target group, and AWS handles traffic redistribution as instances scale in/out.

Need Help Architecting Your Inspection Layer?

F9infotech's AWS networking and security team designs Gateway Load Balancer architectures for firewall, IDS/IPS, and DPI integrations at scale. Talk to our team about your traffic inspection requirements.