AWS Gateway Load Balancer firewall: how GWLB inspection works

AWS Gateway Load Balancer (GWLB) is the AWS-native way to insert a fleet of inspection appliances into your traffic path — transparently, at scale, without re-architecting every workload’s routing. It is also one of the least understood pieces of AWS networking, partly because the appliances that can sit behind it are a short list. This article explains what GWLB is, how its GENEVE datapath works, which firewalls work with it, how to put a third-party network virtual appliance (NVA) behind it, and what GWLB inspection actually costs.

What AWS Gateway Load Balancer is

AWS Gateway Load Balancer is a load balancer purpose-built for transparent, bump-in-the-wire traffic inspection. Unlike an Application or Network Load Balancer, it is not a front door for your applications — it is a way to steer traffic through a pool of inspection appliances and back out again, invisibly to the workloads on either side.

It has two halves:

• The Gateway Load Balancer itself lives in an appliance (inspection) VPC, in front of a target group of inspection appliances — firewalls, IDS/IPS sensors, or other network virtual appliances.
• The GWLB endpoint (GWLBe) is a Gateway Load Balancer endpoint placed in the spoke (workload) VPC. You point a route at the GWLBe, and traffic destined for that route is handed to the GWLB across a private link, inspected, and returned — with the original source and destination preserved.

Because the GWLBe is just a route target, you insert inspection by changing a route table, not by re-addressing or proxying anything. The workload sends a packet to the internet (or to another VPC); the route quietly diverts it through the appliance fleet first. That is what “transparent” and “bump-in-the-wire” mean here: the appliance sees the real packets, but neither end of the conversation knows an appliance is in the path.

How the GWLB datapath works

The mechanism that makes this transparency possible is GENEVE encapsulation.

When a flow reaches the GWLB endpoint, the GWLB GENEVE-encapsulates the original packet — wrapping it, unchanged, inside a GENEVE header — and forwards it over UDP port 6081 to one of the appliances in the target group. GENEVE (Generic Network Virtualization Encapsulation) carries the original packet plus metadata identifying the flow, so the appliance receives the real inner packet with its true source and destination intact.

At the appliance, the datapath is:

1. Decapsulate. The appliance strips the GENEVE header (UDP/6081) and recovers the original inner packet.
2. Apply policy. The firewall evaluates the inner packet against its L3/L4/L7 policy — allow, deny, log, FQDN/SNI checks, and so on.
3. Forward or return. For allowed egress, the appliance source-NATs the inner packet and sends it out via the appliance VPC’s internet gateway. Return traffic comes back to the appliance, is un-NAT’d, re-encapsulated into the original GENEVE flow, and returned through the tunnel to the GWLB, which hands it back to the GWLBe and on to the originating workload.

The key property is that GENEVE encap/decap is stateful per flow: the GWLB remembers which appliance handled a flow and pins both directions of that flow to the same appliance, so the firewall sees the full conversation. The appliance must terminate the GENEVE tunnel correctly — decapsulating, tracking the flow, and re-encapsulating replies — which, as the next section explains, is exactly why the list of compatible appliances is short.

Multi-AZ and scale

GWLB inspection is designed to scale horizontally and to stay highly available across Availability Zones.

• Target group + health checks. Appliances register in a GWLB target group. GWLB health-checks each appliance and automatically stops sending flows to one that goes unhealthy, distributing flows across the healthy members. To add capacity, you add appliances to the target group — the firewall fleet scales out, it does not scale up.
• Cross-zone load balancing off → AZ affinity. GWLB can run with cross-zone load balancing disabled, which keeps each flow inside its own Availability Zone: AZ-a’s traffic is inspected by an AZ-a appliance, AZ-b’s by an AZ-b appliance, and so on. This is the appliance-mode / AZ-affinity pattern, and it has three benefits — no cross-AZ data-transfer charges on inspected traffic, lower latency, and an AZ-isolated blast radius (losing one appliance only affects its own zone rather than failing flows across to another AZ).
• Horizontal scale-out. Because flows are load-balanced across a target group, throughput is a function of how many appliances you run, not how big a single box is. You scale the fleet to the traffic.

Which firewalls work with AWS GWLB, and why few NVAs can

A common question is simply: what firewalls work with AWS GWLB? The honest answer is that it is a relatively short list, because an appliance must terminate the GENEVE tunnel — decapsulate UDP/6081, track each flow, and re-encapsulate replies — and most firewalls were never built to do that.

Appliances that work as GWLB inspection targets include:

• Palo Alto Networks VM-Series
• Fortinet FortiGate-VM
• Check Point CloudGuard
• AWS Network Firewall (which AWS itself runs behind GWLB internally)
• Enforza — one of the few independent NVAs that can serve as a GWLB inspection appliance

The reason the list is short is that GENEVE decapsulation is non-trivial. A GWLB appliance is not just “a firewall on a subnet” — it has to speak the GWLB data plane: terminate the GENEVE tunnel, preserve the inner packet’s true source and destination, keep both directions of every flow pinned together, source-NAT allowed egress, and re-encapsulate the return path. Most firewalls expect to be routed through on plain IP, not handed GENEVE-wrapped packets to unwrap. That engineering — a correct GENEVE tunnel datapath beside the policy engine — is what separates a GWLB-capable NVA from one that simply runs in a VPC. It is why most teams reaching for GWLB inspection default to the mega-NGFW vendors, and why a flat-priced NVA that can do the same job is worth knowing about.

How to use a third-party NVA with GWLB

If you want to put a third-party NVA behind GWLB rather than a cloud-native service, the deployment shape is the same regardless of which appliance you choose:

1. Appliance VPC. Stand up a dedicated inspection VPC with an internet gateway, and run your NVA fleet there — one appliance per Availability Zone is the common starting point.
2. GWLB + target group. Create a Gateway Load Balancer in the appliance VPC and register the appliances in its GENEVE target group, with health checks. Expose it through a VPC endpoint service, and decide cross-zone on or off (off, for AZ affinity, is the usual choice).
3. GWLBe + route steering in the spoke. In each spoke (workload) VPC, create a GWLB endpoint (GWLBe) and point the workload subnet’s default route (0.0.0.0/0) at the AZ-local GWLBe. That single route change inserts the inspection fleet into the path — no workload re-addressing, no proxy.

The appliances must of course terminate GENEVE (see the previous section), and the EC2 source/destination check must be disabled on each appliance so it can forward transit traffic that is not addressed to itself.

For Enforza specifically, this is shipped as ready-to-run Terraform — a GWLB scenario that builds the appliance VPC, the GWLB and target group, the spoke VPC with per-AZ GWLBe endpoints and route steering, and the engines themselves. CloudFormation is not provided for this scenario yet; the datapath runs on a Debian 12 / Ubuntu 22.04+ base. You point the Terraform at a fleet deployment key, apply, and enable the GWLB connector on each engine in the console.

Enforza as a GWLB inspection appliance

Enforza is one of the few independent NVAs that runs as a transparent GENEVE inspection appliance behind AWS GWLB. Behind the GWLB, an Enforza engine decapsulates GENEVE, applies the same L3/L4/L7 policy it enforces anywhere — egress, ingress and east-west control, FQDN/SNI-based L7 filtering without breaking TLS, secure NAT — source-NATs allowed egress via the appliance VPC’s internet gateway, and returns replies through the tunnel. Multi-AZ with cross-zone off gives you per-AZ affinity and an AZ-isolated blast radius, and you scale by adding engines to the target group.

You get the inspection capability of a GWLB-grade NVA without a mega-NGFW licence. See the GWLB inspection appliance page for the deployment detail and the cost wedge.

Cost vs the incumbents

GWLB inspection cost is really the cost of the appliance you put behind the GWLB, because AWS charges for the GWLB and GWLBe separately and identically no matter whose appliance you run. The appliance is where the bills diverge:

• AWS Network Firewall as the inspection layer bills per-AZ endpoint-hours plus a per-GB data-processing charge — $0.395 per endpoint-hour per Availability Zone (roughly $288/month each, so a 2-AZ pair is about $577/month before a byte) plus $0.065/GB, both duplicated per AZ. Rates are us-east-1, dated 2026-06-14, directional and subject to change.
• Mega-NGFW VMs (Palo Alto VM-Series, FortiGate-VM, CloudGuard) carry per-VM licences, often metered by vCPU or instance size, on top of the EC2 cost — the comprehensive feature set most teams only half use, fully paid for.
• Enforza is a flat per-firewall licence with no per-GB data-processing tax. Your price does not move with traffic, instance size, or the number of protected IPs.

Be clear about what Enforza replaces: you still pay AWS’s own GWLB and GWLBe hourly and data-processing charges — those are AWS’s, not the appliance’s, and they apply to every appliance choice. What the flat Enforza licence replaces is the appliance licence and the per-GB inspection tax that a Network Firewall or mega-NGFW layer adds on top. At modest egress that typically lands 60–80% below the cloud-native firewall plus its data-processing charges.

For the worked numbers, see AWS Network Firewall alternative and the Palo Alto comparison, or run your own figures in the savings calculator.

FAQ

Where to go next

If you are evaluating a GWLB inspection appliance, the GWLB inspection appliance page covers the datapath, the multi-AZ pattern, the Terraform deploy, and the cost wedge in one place. To see how Enforza deploys more broadly, read how it works, or compare egress paths on the secure NAT gateway page.

Start free — one firewall, no card — or estimate the saving in the savings calculator.