The Real Firewall Decision Happens in the Audit Room

I was in a design review for a regulated workload when an engineer asked the most reasonable question in the room. We were running a third-party firewall appliance in front of the environment, paying for the license, operating the high availability pair, patching it on a schedule. He pointed at the diagram and said: why not replace this with AWS Network Firewall, drop the license cost, and stop babysitting instances?

He was right on every technical point. And the answer to his question was not in the architecture. It was in a room he had never been invited to.

Almost everyone frames the managed firewall versus appliance decision as a feature comparison or a license-cost calculation. Read the threads, watch the conference talks, and the debate lands on throughput, on which product inspects more protocols, on dollars per gigabyte processed. That framing is comfortable because it fits in a spreadsheet.

It also misses where the real cost lives. In the workloads I have architected for regulated organizations, the managed service handled the overwhelming majority of cases and handled them well. The small minority that still pay for an appliance almost never pay because of latency. They pay for something a benchmark cannot measure, and it shows up only when an auditor sits down across the table.

Start with what each option actually is, because the comparison only makes sense once the capabilities are on the table.

AWS Network Firewall is a managed, stateful and stateless network firewall. Its stateful engine is compatible with Suricata rule syntax and performs deep packet inspection (DPI), looking at payload data and not just headers. It supports Transport Layer Security (TLS) inspection for both inbound and outbound traffic, decrypting, inspecting, and re-encrypting on the same firewall instance so traffic never crosses an extra boundary. It can hold a session, refusing to let the establishment packets reach the destination server until rules matching on the Server Name Indication (SNI) have been evaluated. It does domain filtering through SNI and HTTP host headers, URL and domain category filtering against predefined content categories, and geographic Internet Protocol (IP) filtering backed by MaxMind geolocation data. It also offers AWS managed rule groups, including active threat defense that draws on AWS threat intelligence and threat-signature groups covering malware, botnets, credential phishing, and more. You configure all of it through the console, the application programming interface (API), or infrastructure as code. You operate none of the underlying capacity. It scales as managed infrastructure, and it lives inside one cloud provider by design.

A third-party Next-Generation Firewall (NGFW) appliance, the virtual editions of Palo Alto, Fortinet, Check Point and similar, answers a different question. You bring the stack your organization already runs on premises into the cloud. Same management console, same policy language, same vendor threat intelligence, same mature application-layer inspection your security team has used for years. The price of that continuity is operational: you run the high availability (HA) pair, you patch it, you carry the license, you own the scaling.

The dry trade-off: the managed service takes operations off your hands and ties you to one provider. The appliance gives you continuity and depth at the cost of operating more of your own infrastructure.

If you stop here, the engineer in my review wins the argument. For most workloads, he should.

The documentation gives you a feature matrix. It does not tell you that the decision is rarely about the controls. It is about the cost of proving the controls.

That cost is not subjective. It moves along mechanisms you can name.

First, replacing a control invalidates its evidence. Every control that passed a prior assessment carries documented proof: the configuration, the runbook, the operational logs tied to it. Swap the control and the proof no longer applies. The organization has to re-document, re-test, and re-submit. The expense is not the feature. It is rebuilding the evidence cycle from the start.

Second, configuration divergence across environments is an audit finding. A policy defined once and enforced across multiple environments reduces drift. Drift between an on-premises estate and a cloud environment is a real source of gaps in an assessment. A managed service gives you policy inside one cloud only, so in a hybrid or multi-cloud estate you now maintain two sources of truth, and two sources of truth diverge. A unified appliance buys the absence of that gap.

Third, technical depth the managed service cannot reach forces the decision, but not in the way most people assume. Both sides carry threat intelligence. The managed service ships AWS managed rule groups, including active threat defense backed by AWS threat intelligence and broad threat-signature coverage, so the appliance does not win on having threat feeds. What the top-tier appliance adds is depth a network firewall does not reach: granular application identification independent of port, protocol, or encryption, the kind that tells one application apart from another across thousands of signatures rather than recognizing the protocol alone, plus inline machine-learning prevention aimed at previously unseen threats. That depth is the rule, not the exception. The genuinely rare case is the workload that actually needs it. The trigger is never that the appliance can do more. The trigger is that one specific workload requires something only the appliance delivers, on technical grounds alone. I have seen it happen. It is uncommon, and when it shows up it leaves little room for debate: a requirement the managed service cannot meet at the depth demanded, and the choice stops being a preference and becomes an obligation. Keep this case separate from the governance reasons that follow, because most of what looks like a depth requirement is an assessment requirement in disguise.

Fourth, and this is the center of the whole thing: the cost of an audit is a function of how familiar the control is to the assessor, not only of how good the control is. A new control generates more questions, more requests for evidence, more round trips through the assessment. Reusing a control the assessor already understands and has already accepted reduces the number of iterations. The proving effort does not scale with the technical quality of the firewall. It scales with how unfamiliar that firewall is to the person reviewing it.

This is where regulated jurisdictions make the point concrete. Serious financial-sector regulators tend to be principle-based. They do not publish a list of approved products. They do not say use an appliance, and they do not say a managed service is forbidden. They require the institution to demonstrate confidentiality, integrity, availability, segregation, and traceability, and to keep that demonstration auditable. In Brazil, the central bank operates this way for financial institutions: the obligation to prove sits with the institution, not with the cloud provider. The regulator does not pick your firewall. It requires you to prove your control. Once you internalize that, the managed-versus-appliance question resolves into a different one entirely: which path to proof costs my organization less.

The teams that still buy appliances are not behind the times, and they are not wrong. They are doing arithmetic a benchmark cannot see. They are weighing the cost of proving a new control against the cost of reusing one their assessor already trusts, and sometimes the old control wins for reasons that have nothing to do with packets.

The question was never which firewall is better. It is which path to proof costs the least for your organization to defend.

Managed wins the architecture. The appliance wins the audit. The minority that pay for the appliance are paying for the second sentence, and most of the time they know exactly what they are buying.

If you have moved a regulated workload off an appliance onto a managed service, what made the audit conversation easier, or harder? That is the part the product pages never cover, and it is the part worth comparing notes on.

Erick Mancz is an AWS Solutions Architect with close to 15 years in cloud, focused on production machine learning and generative AI for regulated organizations. I hold every active AWS certification, including the Generative AI Professional as an early adopter. I am the sixth Golden Jacket holder in Brazil in the AWStronaut list and co-founder of Golden Jackets Brazil, the community connecting everyone in the country who has earned that status.

I write Golden Jacket Field Notes, a weekly practitioner series on production ML, GenAI, and cloud architecture on AWS. Not conference recaps, not first tutorials. Notes from workloads where outages, audit gaps, and cost surprises are not tolerated.