AWS has introduced rule hit counts for AWS Network Firewall, giving security teams a way to measure whether their stateful firewall rules are matching traffic.
The new capability addresses a problem: as policies expand, organizations often rely on manual log analysis to determine which controls remain useful and which consume capacity without being triggered.
That process is slow, inconsistent, and difficult to defend during audits. By exposing match activity per rule, AWS gives administrators evidence they can use to identify stale entries, tune policies, and verify that deployed safeguards are operating in production environments.
AWS Network Firewall Adds Rule Hit Counts
The feature relies on Suricata-compatible rules. A hit counter increases only when a matching rule produces an alert log entry. Consequently, actions such as alert, drop, and reject are represented in the metric because they create alert records.
A pass rule, however, permits traffic without creating an alert log by default, so it will not appear in the count. Organizations that need visibility into permitted traffic can add the alert keyword within a pass rule.
This preserves the allow decision while recording the match, enabling analysts to validate rules that authorize applications or outbound connections.
Each alert log includes AWS metadata identifying the resource ARN, while the Suricata signature ID identifies the rule. AWS Network Firewall uses this combination to calculate rule hits in the Top Rule Hits dashboard.
The view aggregates results for a firewall across Availability Zones within its AWS Region and displays hit counts, percentages of total matches, resource ARNs, signature IDs, rule descriptions, and last-occurrence timestamps.
Analysts can also inspect records directly through CloudWatch Logs Insights when logs are delivered to CloudWatch, or through Amazon Athena when they are stored in Amazon S3. This makes the telemetry accessible.
For rule hygiene, the dashboard provides a starting point. If a signature does not appear during a selected lookback period, its rule has not matched traffic in that timeframe.
Security teams can investigate whether it is obsolete, incorrectly ordered, or reserved for a but rare workflow. They should not automatically delete it, but can combine hit data with asset ownership, application requirements, and change-control review before removal.
AWS stated that during an investigation, analysts can filter activity to the suspected window and quickly identify rules that detected suspicious connections. This can reveal relevant indicators.
These may include attempts to communicate with external testing infrastructure, unexpected egress paths, or blocked geographic destinations. The same visibility helps validate newly deployed controls.
A rule that begins recording hits after rollout provides evidence that it is seeing intended traffic and enforcing its policy action. AWS says rule hit counts are enabled by default and carry no additional Network Firewall charge, although normal logging, storage, and query costs still apply.
Native dashboard visibility requires alert log delivery and detailed monitoring, while custom dashboards can use included metadata directly. The feature supports only stateful rules, helping teams make firewall governance decisions.
Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN
