AWS Network Firewall adds rule hit counts, turning dormant-rule cleanup into a query

AWS has added rule hit count to Network Firewall, tracking how often each stateful rule matches traffic across both custom and managed rule groups ^[1]. The capability is enabled by default ^[2], which matters because the question it answers - did this control actually fire - was previously answered by hand, through manual log analysis ^[3].

AWS is explicit about the gaps it is closing. Organizations with governance policies that require removing dormant rules after a defined period had no mechanism to identify them ^[4]. Teams working to PCI 4.0 and DORA could not produce evidence that specific controls were actively functioning ^[5]. Central teams running firewalls for multiple business units could not tell which rules were unused or needed updating ^[6]. AWS says the hit data lets you remove unused rules, accelerate incident response, and validate control effectiveness for compliance ^[7].

The mechanism is worth reading closely, because it defines what the number means. The counter increments only when a rule match results in an alert log being created ^[8]. Rules with an alert, drop, or reject action therefore increment, since all three generate alert logs ^[9]. Rules with a pass action do not generate alert logs by default and will not appear in the metric at all ^[10]. AWS's workaround is to add the alert keyword inside the pass rule, which writes an alert log while still permitting the traffic ^[11].

That asymmetry is the operational trap. A zero next to a rule is two different statements collapsed into one: nothing matched, or the rule is a pass rule that was never instrumented to log ^[12]. Any policy built around explicit allow-listing will read as largely dormant on first inspection, and pruning on that basis would delete working rules. Instrumenting those pass rules fixes the visibility, but each one then writes an alert log on every match, into CloudWatch Logs or S3 ^[13].

The plumbing is unusually light. Network Firewall attaches an aws_metadata block containing the rule group's resource_arn to each alert log, by default and with no additional configuration ^[14]. The combination of sid and resource_arn identifies the specific rule that fired ^[15]. The firewall monitoring dashboard consumes those two fields to produce per-rule hit counts, so routine review does not require writing a query ^[16], and the same logs can be queried directly with CloudWatch Logs Insights or Amazon Athena ^[17].

"Enabled by default" needs a qualifier. The walkthrough requires an existing firewall inspecting VPC traffic, and alert log delivery must be configured ^[18]. The dashboard widget additionally requires detailed monitoring, enabled through the logging configuration or the Monitoring tab in the console ^[19]. The metadata itself is captured regardless of log destination and regardless of whether detailed monitoring is on, so custom dashboards can be built from the raw logs ^[20]. What is on by default is the metadata, not the reporting: a firewall with alert logging switched off produces no hit counts ^[21].

For an attestation file, this is a genuine change in kind. A hit count is a positive artifact that a control matched traffic and logged it ^[8][15], which is a stronger statement than a screenshot of a rule's existence. It does not work in reverse. A control with zero hits may simply have had nothing to catch ^[8].

What to watch: whether teams begin adding the alert keyword to pass rules at scale, and what that does to log volume and query cost ^[11][13]; and whether hit counts on managed rule groups ^[1] get used to argue for trimming vendor-supplied rules, which is a different risk conversation from cleaning up your own.