AWS has introduced rule hit count support for AWS Network Firewall, giving security teams direct visibility into which stateful firewall rules are matching live network traffic.
The new capability is enabled by default and helps organizations identify active, inactive, and potentially misconfigured rules without manually reviewing large volumes of firewall logs.
As firewall policies grow, they often accumulate rules that are no longer needed, never trigger, or are placed incorrectly in the inspection order.
Until now, teams had to search alert logs manually to determine whether a specific rule was being used. This could make firewall cleanup, incident investigations, and compliance validation slow and difficult.
The rule hit count feature uses AWS Network Firewall alert logs to show how frequently individual stateful rules match traffic.
AWS Network Firewall Shows Triggered Security Rules
The AWS console’s Top Rule Hits dashboard displays the signature ID, rule description, resource ARN, total hit count, percentage of overall hits, and the most recent time the rule was triggered.
This lets security teams quickly determine whether a control is active. A rule that repeatedly appears in the dashboard is matching traffic, while a rule that does not appear during the selected lookback period may be unused, outdated, or positioned behind another matching rule.
AWS Network Firewall counts a rule hit only when the traffic match generates an alert log. Rules using alert, drop, or reject actions are included because these actions create alert records.
However, pass rules do not create alert logs by default and therefore do not appear in hit count data. Organizations that want to measure matches for allow rules can add the alert keyword to a Suricata pass rule.
For example, a rule can permit HTTPS traffic while simultaneously creating an alert log. This allows teams to monitor authorized traffic patterns without blocking the connection.
AWS adds an aws_metadata field to alert logs, including the ARN of the rule group or firewall policy that produced the event.
Analysts can combine the resource ARN with the Suricata signature ID (SID) to identify the exact rule that generated an alert, with alert data delivered to Amazon CloudWatch Logs or Amazon S3.
Security operations teams can investigate the logs with CloudWatch Logs Insights or Amazon Athena, while the native Network Firewall monitoring dashboard provides an easier view of the most frequently triggered rules.
The feature can help during incident response. For example, if a security team suspects outbound communication with a malicious domain, it can filter the rule hit count view to the relevant time period.
This can reveal whether a domain-blocking or threat-detection rule triggered, how often it matched, and when the most recent event occurred.
Rule hit counts can also support compliance operations. Teams working with PCI DSS 4.0, DORA, and internal governance requirements can use the data as evidence that firewall controls are functioning.
It also helps central cloud security teams review policies managed for multiple business units and remove dormant rules that consume capacity without adding protection.
AWS noted that system-generated signature IDs may also appear in the dashboard. These can represent strict-order default actions, such as dropping established traffic that did not match an explicit rule. In these cases, the displayed ARN points to the firewall policy rather than a stateful rule group.
Rule hit count is available at no additional AWS Network Firewall charge, although normal CloudWatch Logs, Amazon S3, and Athena storage or query fees still apply.
The capability supports stateful rules only; stateless rules are not currently covered. It is available in supported AWS Regions except the Middle East Bahrain and Middle East UAE Regions.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC
