How are you handling the per-GB tax on cloud-native firewalls/NAT across client estates?
I run a small cloud-firewall/NAT product, and before I get to that (disclosure up front, mods OK'd this post — see the bottom), I genuinely want to compare notes with people operating this at scale across many clients, because the maths gets ugly faster for you than it does for a single tenant.
The thing I keep running into: the cloud-native egress controls are metered per gigabyte, and that meter never stops scaling with the client's traffic.
Rough numbers, US figures, so you can sanity-check against your own invoices:
- AWS NAT Gateway — ~$0.045/GB processed, plus ~$0.045/hr per gateway.
- AWS Network Firewall — ~$0.065/GB inspected, plus $0.395/endpoint-hr ($288/mo per AZ), billed per endpoint per AZ, so a 2–3 AZ design multiplies the hourly floor before a single byte moves.
- Azure Firewall — a per-GB processing charge on top of a per-hour SKU floor (Standard ~$1.25/hr).
For one tenant that's an annoyance. Across an estate it's a structural margin problem, because:
- Your managed-service price is fixed, but your cost base floats with the client's traffic. You quote a monthly number; their egress doubles after some launch or batch job; your firewall/NAT line doubles with it and quietly eats the spread.
- The per-AZ hourly floors stack before any data moves. Multi-AZ inspection means paying the endpoint-hour several times per client just to be resilient — multiply across N tenants.
- It's two meters, not one. Egress filtering and NAT each meter per-GB, so the same gigabyte often gets charged twice on its way out.
- You usually can't cleanly pass it through. Clients want a predictable monthly number; a traffic-indexed true-up is painful to explain and worse to forecast.
So the real question for this sub: how are you actually dealing with this? The options I've seen MSSPs take, none free:
- Eat it as cost of goods — fine until a chatty tenant turns a profitable account unprofitable.
- Pass it through as a metered line item — honest, but kills the "predictable managed service" pitch and invites bill-shock arguments monthly.
- Centralise inspection (one shared firewall behind a GWLB / transit hub) to amortise the hourly floors — helps per-hour, does nothing for per-GB, concentrates blast radius.
- Roll your own on pfSense/OPNsense/VyOS to dodge the meter — kills per-GB cost but you now own patching, HA, config drift and multi-tenant management by hand.
- Stay on the mega-NGFWs (Palo, Fortinet, Check Point) where MSSP programs and multi-tenancy are mature — but the licensing/complexity is a different pain, and overkill if all you need is egress + NAT.
Genuinely interested in what's working: are you centralising, DIY-ing the NAT/firewall layer, passing per-GB through, and how are you keeping fleet management sane? And for those who've moved off cloud-native — what did the migration actually cost in engineer time?
Disclosure (mods approved this post): I'm the founder of Enforza, which is one of the options above — so take this as "here's what we built and why", not a neutral survey. It's a cloud-managed firewall + secure NAT gateway you run as a normal Linux VM (an NVA) inside the client's own network/account, built on standard Linux network primitives. It does L3/L4/L7 egress filtering (by FQDN/SNI), ingress, east-west and secure source-NAT, and runs as a transparent appliance behind an AWS Gateway Load Balancer if you want centralised inspection without re-architecting routing.
Why it's relevant to this thread: it's priced flat per firewall, no per-GB data-processing charge — so the cost base stops floating with each client's traffic. At modest egress it tends to land 60–80% cheaper than a cloud-native firewall stacked with a NAT gateway — directional, workload-dependent, so run your own numbers, don't trust mine. To be straight about what it does and doesn't:
- It replaces the firewall/NAT metering — you still pay AWS/Azure for the VM and normal bandwidth. Not a way to dodge your CSP's infra bill.
- No TLS decryption and no key custody. FQDN/SNI filtering reads the hostname already in the clear (SNI, Host header, DNS).
- Multi-tenant by default (each client an isolated tenant), whole fleet from one console — GitOps/policy-as-code or UI — with logs to each client's own SIEM, not through us.
- Small bootstrapped team, but not a weekend project — in production ~3 years. It's the focused egress/NAT/inspection set most cloud teams use, not a full enterprise NGFW suite; I won't pretend it matches Palo/Fortinet feature-for-feature.
Site's in my profile / I'll drop it in a comment if anyone wants it rather than linking in the body. Mostly I'd rather hear how you're solving the per-GB problem today — happy to be told the DIY or centralised route beats what we do for your shape of estate.