Protect APIs and edge with WAF

AWS WAF and Network Firewall are paid services. WAF bills a small monthly fee per web ACL, a smaller fee per rule and a per-request charge for inspected traffic; Network Firewall bills per hour per endpoint plus a per-GB data-processing charge. An empty web ACL or an unattached firewall is the most expensive way to have no protection, because you pay for it and trust it at the same time while it delivers nothing.

The exposure these controls mask is both a security and a cost one. An unprotected public API is exactly the kind of gap that turns into a breach, an audit finding, or a runaway bill: API Gateway and the Lambda behind it charge per request, so an automated bot storm against an unfiltered endpoint can generate millions of billable invocations overnight, with no business activity behind them. A WAF rate-based rule would have turned the whole storm away at the edge for a few dollars.

The right framing is that the dollar amounts here are small and the exposure they cap is large and unbounded. Populating an empty web ACL or attaching one to an API adds a modest per-rule and per-request charge, so the corrected state costs slightly more than the broken one. That incremental spend buys back the assurance the original line item only pretended to provide, and it is worth saying out loud at the review.

Maya is the finance partner for a mid-sized fintech. Security Hub has flagged a cluster of WAF and Network Firewall findings: a couple of empty web ACLs, a public API with no association at all, and a firewall missing deletion protection. At the review she does not lead with what the fix costs, because she knows the answer is a few dollars a month. She leads with the assurance problem: the company is paying for these firewalls and counting them as satisfied controls on the security questionnaire, yet several of them inspect nothing. The line item is real and the protection is fictional at the same time.

The team pulls the rule counts. Two web ACLs have empty Rules arrays with a default action of Allow, so every request sails through, and a public API Gateway stage has no web ACL bound to it. Maya's framing for the finance pack is that the dollar amounts here are small and the exposure they cap is large and unbounded: that unprotected API bills per request, so an automated bot storm could turn into a five-figure invoice spike overnight with no business activity behind it, when a WAF rate-based rule would have turned the storm away at the edge for a few dollars. She approves the modest per-rule and per-request increment without debate, and asks for the count of empty or unattached firewalls to become a standing zero-target metric so the company stops paying for protection it does not have.

The direct cost of an inert firewall is negligible, a few dollars a month for a web ACL or the hourly Network Firewall charge, so the finding looks like rounding error and gets deprioritised. That is the wrong read. The real impact is on the integrity of your control reporting: when "WAF deployed" appears as a satisfied control but the web ACL is empty or unattached, the posture you are attesting to is materially misstated.

There is also a genuine cost tail. An unprotected public API is a tail-risk on the cloud bill: per-request billing means an automated attack can become a surprise invoice overnight, and a WAF rate-based rule is the cheap insurance that caps it. The expected monthly cost of an unprotected API is near zero right up until the night a storm hits it, which is exactly the kind of unbudgeted spike finance most wants to avoid.

The budgeting move is to treat WAF and Network Firewall as funded baseline infrastructure rather than per-project line items to argue about, and to make the count of empty or unattached firewalls a standing zero-target metric. A non-zero and growing count means firewalls are being created faster than they are configured, which usually points to IaC templates or review gates that do not enforce a rules baseline.

WAF and Network Firewall are the layers that turn away malicious traffic before it reaches the business's applications and networks. The risk this group addresses is subtle: a firewall can be deployed but empty, or a public API can have no firewall in front of it at all, and the dashboard will still read "protected" while the reality is "open."

This is mostly a control-assurance and process matter rather than a cost story. "We had a firewall but it had no rules in it" is a far worse sentence to say after an incident than "we had not deployed one yet," because it reads as negligence. The fix is cheap and largely one-time per resource.

The defensible end state is that every public API and load balancer sits behind a web ACL that contains the managed baseline, every Network Firewall policy carries real rules and cannot be deleted by accident, and coverage is enforced by the deployment pipeline rather than by someone remembering. The leadership question is one number: how many of our firewalls are empty or unattached, and the right answer is always zero.

After an incident response found that the web ACL fronting a production load balancer had an empty Rules array, so every request had passed uninspected for nearly a year while three security reviews recorded WAF as in place, the CEO asked the obvious question: how did we attest to a control we did not actually have? The answer was that the dashboard, the architecture diagram and the security questionnaire all read protected, and every one of them was technically accurate and wrong about the only thing that mattered, whether traffic was being inspected.

The response was to stop treating firewall coverage as something each team configures by hand and make it a pipeline-enforced default. A non-empty rules block, a web ACL association on every public API and load balancer, and deletion protection on every Network Firewall became required parts of the IaC modules, enforced by a CI policy check so a pull request that creates an inert firewall fails before it merges. The leadership signal is now one number on the report: how many of our firewalls are empty or unattached, and the expected answer is zero. The shift, from a firewall that exists to a firewall that works, is the whole point, because 'we had a firewall but it had no rules in it' is a far worse sentence to say after a breach than 'we had not deployed one yet.'

The dollar amount is trivial; the reason it is escalated is that it represents a security control the organisation believes it has and does not. An empty or unattached firewall leaves the application or network it fronts exposed exactly as if no firewall existed, while every report, diagram and questionnaire says it is protected. That gap between claim and reality can survive audits and reviews undetected, which makes it larger than its cost suggests.

There is a reputational and regulatory edge too. "We had a firewall but it had no rules in it" reads as negligence after an incident, not backlog. So this category sits at the intersection of security posture and assurance credibility. The leadership move is not to spend more on firewalls; it is to insist that every firewall the org claims is actually inspecting traffic, and to ask for the one number that proves it: how many are empty or unattached?