Skip to content
Logmetry
What we solve
SIEM and log costClean data for AI agentsCoverage, audit and PIIVendor independenceSIEM migrationObservability modernizationAll problems we solve
Who it’s for
For the CISOFor the CIO and CTOFor the CFOFor Architects
Platforms
SplunkMicrosoft SentinelCrowdStrikeElasticDatadogDynatraceSplunk ObservabilitySolarWindsCriblOpenTelemetryA Data LakeCompare the options
The Blueprint
The whole methodPhase 01 · FoundationPhase 02 · AI triagePhase 03 · RemediationPhase 04 · FootprintEverything as codeAI native
JournalAbout
About LogmetryYour teamTrust and securityStep one and the proofWhere we fit
Book the review

The journalEconomics

Firewall allow logs: why you pay Splunk to index data nobody searches

Firewall allow logs are one of the largest sources of Splunk ingest in most environments. Detection rules do not fire on them. Analysts do not query them. Here is the routing architecture that sends them to S3 for a fraction of the cost while keeping your compliance archive intact.

Zbigniew Gajuk2026-04-179 min readFor CFO and FinOps, CISO and SOC

A firewall appliance releases a wide torrent of grey dots with a few red ones into a dark teal pipeline stage. A thin bright teal stream carries only the red dots up to a small analytics console, and a broad teal stream carries every dot down into three storage slabs that step down and grow paler.The few that matter
Most firewall events are allowed sessions nobody searches. The pipeline sends the few that detections use to Splunk and keeps every event in storage that gets cheaper as it ages.

The line item nobody talks about

Look at the license usage report of a typical Splunk deployment, split by source type. Firewall traffic is usually near the top, and most of it is allow traffic: sessions that were permitted and completed. If that holds for your environment, a large share of what you pay to index is data that nobody searches, nobody alerts on, and nobody asks an auditor to produce except in narrow circumstances.

This is not an exotic finding. Splunk Community threads, Reddit’s r/splunk, vendor whitepapers, and consulting engagements have all reported the same distribution for years. Firewall allow logs are among the largest categories of ingest in the Splunk estates our architect has worked on. They are also the least interrogated.

What fills a typical Splunk indexAn illustrative bar of Splunk ingest, not to scale: firewall allow logs, often the largest single source, which detections do not fire on and analysts do not query, next to everything else, the events detections, dashboards, and analysts actually use. Your own share is in the license usage report, split by source type.WHAT FILLS A TYPICAL SPLUNK INDEXFIREWALL ALLOW LOGSEVERYTHING ELSEOften the largest single source. Detections do not fire on them,analysts do not query them, and each GB pays the analytics tier.The events your detections,dashboards, and analysts use.Illustrative, not to scale. Read your own share in the license usage report, by source type.
What fills a typical Splunk indexAn illustrative bar, not to scale: firewall allow logs, often the largest single source, beside everything else your detections, dashboards and analysts use.WHAT FILLS A TYPICAL SPLUNK INDEXFIREWALL ALLOW LOGSOften the largest single source. Detections do not fire onthem, analysts do not query them, and each GB pays theanalytics tier.EVERYTHING ELSEThe events your detections, dashboards, and analysts use.Illustrative, not to scale. Read your own share in the license usagereport, by source type.
Firewall allow logs are often the largest single source of Splunk ingest, and each of those GBs pays the same analytics-tier price as the events your SOC actually uses.

This post walks through why that is, what the detection and compliance rationale actually supports, and what a routing layer changes once you accept that most of what your SIEM receives is not for your SIEM.

What a firewall allow log actually is

Every packet that traverses a firewall produces a record. A Palo Alto session generates a pan_traffic log. A FortiGate produces an fgt_traffic entry in key-value format. A Cisco ASA emits a %ASA-6-302013 built-connection message. The allow vs deny distinction in the log is literal: the action field is set to allow, accept, permit, or the vendor-specific equivalent.

An allow log says a session was permitted and completed. It contains the five-tuple, bytes transferred, user if identity is enabled, and protocol metadata. If the session was unremarkable, that is where the record ends. If it was remarkable, the same session produces additional logs: a threat log, an intrusion event, a user-ID correlation, a URL filtering decision. Those additional logs are the ones your detections actually fire on.

The allow record itself is a session manifest. It proves a connection happened. It does not imply the connection was interesting.

Why allows dominate the ingest volume

A corporate perimeter sees an enormous amount of routine traffic every second. DNS queries. Software update checks. Heartbeats to SaaS platforms. Cloud storage syncs. Each of those is a permitted session and each generates an allow log. The ratio of permitted to denied traffic in a typical enterprise sits somewhere around 90 to 10, and often higher. Firewall policy is explicit by design: you permit what you need, you deny everything else, and the default deny rule barely fires because traffic that would hit it is usually blocked earlier on the rule chain.

When the firewall forwards logs to Splunk, both categories of session show up in the same stream. Allow and deny mix together. By the time they hit the indexer, they are being charged at the same per-GB rate. The volume split is structural: DNS alone can generate hundreds of thousands of allow sessions per hour on a busy network, each one producing a log entry Splunk will charge you to store and parse.

The detection rules that do not fire on them

Open your Splunk Enterprise Security correlation searches or your custom alerts and look at the filter logic. The vast majority of firewall-based detections fall into one of two categories.

The first is pattern matching on deny or threat actions. “Alert when a host has more than N denied outbound connections in five minutes” is an exfiltration heuristic. “Alert when threat engine severity is high” is an intrusion detection signature. “Alert on IPS signatures for specific CVE ranges” is a known-bad matcher. All of these filter for action != "allow" or for enriched threat metadata that lives on a separate log type.

The second is behavioral anomaly detection on aggregate session counts: spikes in outbound data volume, new destination IPs, unusual port usage. These could theoretically use allow logs as input, but most implementations derive them from NetFlow, VPC flow logs, or endpoint telemetry rather than firewall syslog. The cardinality of firewall allows makes them expensive to aggregate inside Splunk at analytics-tier pricing when the same summary is available from lower-cost sources.

The practical outcome is that allow logs sit in the indexer, get parsed, get written to a tsidx file, get replicated across the cluster per your replication factor and search factor, and are never touched by a saved search.

The compliance archive question

Before getting to the fix, the honest part. There are two legitimate reasons allow logs stay in the SIEM even when nothing fires on them.

The first is incident response. When an analyst is investigating a known compromise, the question “what did this host talk to during the window in question” is sometimes answered by allow logs. A browser fetch to a C2 server looks like an allow until threat intel enriches it. A lateral movement attempt to an internal system that did not trigger host-based detection shows up as an allow from the firewall’s perspective. For a narrow class of investigations, allow logs are the corroborating record.

The second is compliance retention. PCI-DSS, HIPAA audit controls, SOC 2 CC7, and most sector-specific frameworks require logs of “security-relevant events” for a defined retention period, typically one year online and seven years archived. Firewall logs fall inside that scope at most organizations.

Neither of these reasons requires the logs to live in your SIEM’s analytics tier. They require the logs to be retrievable and queryable within an acceptable window. An S3 bucket with lifecycle policies and a search layer on top meets both requirements at a fraction of the cost of Splunk indexing.

What the Splunk bill looks like

Splunk bills what it indexes, and the data grows every year. Splunk’s pricing FAQ set a 9 percent uplift on one-year renewals, so a flat estate still pays more at each renewal, and no estate stays flat. Each renewal becomes a choice: pay more or see less.

Add the administrator time that goes to props.conf and transforms.conf tuning, Technology Add-on updates, and forwarder management for exactly the data types we are discussing. That work scales with the number of sources and clients, not with the value of the data.

Now do the arithmetic on your own estate rather than on anyone’s average. Open the license usage report view, split by source type and index, and read the firewall share of daily ingest. Multiply it by what you pay per GB per day at your tier. That is the license line your allow logs carry, before the infrastructure they occupy, the storage they replicate across, or the admin cycles spent keeping their parsers consistent. Peers have published what the same split did for them: Yale New Haven Health cut Palo Alto log volume 40 percent, from 600 to 700 GB a day down to 400 GB (Cribl case study, 8 July 2024), and Nutanix brought firewall log volume down 50 percent (Cribl customers page, read September 2026). Yours is the number your own report shows.

The routing split

A Cribl pipeline sits between the firewall collector and the Splunk HTTP Event Collector. The pipeline has two routes.

Route one sends every event, without filtering, to an S3 bucket. The bucket has a lifecycle policy: hot storage for the first thirty days, Infrequent Access for the next year, Glacier for the remainder of the retention requirement. S3 hot-tier cost lands at roughly $0.023 per GB per month and falls by an order of magnitude in Glacier. Full-fidelity storage for a year of firewall data costs a storage price, not an analytics price.

Route two is conditional. Events where action != "allow" pass a filter and continue on to Splunk HEC. Allow events terminate after the S3 route. Splunk receives every deny, every threat log, every IPS hit, every URL filtering block, every authentication event, every configuration change. Those are the events your detections actually use. They arrive pre-parsed and field-extracted by Cribl, which means Splunk does less work on the indexer side.

The pipeline also deduplicates. Cribl’s Suppress function removes duplicate events within a configurable key and time window, which trims the volume that does reach Splunk further still. How much depends on how repetitive the source is, and that is measured, not assumed.

The routing split for firewall logsA firewall sends to a pipeline in front of the Splunk HTTP Event Collector. Route one sends every event, unfiltered, to an S3 bucket whose lifecycle policy moves it from hot storage to Infrequent Access to Glacier for the rest of the retention requirement. Route two passes only events whose action is not allow, every deny, threat, IPS hit, URL filtering block, authentication event and configuration change, on to Splunk. Allow events end after route one, and Cribl Search queries the archive for the rare investigation that needs them.FIREWALLEvery session loggedPIPELINETwo routes,deduplicatedROUTE ONE: EVERY EVENT, UNFILTEREDHOTRecent daysINFREQUENT ACCESSThe next stretchGLACIERThe rest of retentionS3 lifecycle policy. Full fidelity for the whole retention requirement.ROUTE TWO: ACTION IS NOT ALLOWSPLUNK HTTP EVENT COLLECTOREvery deny, threat, IPS hit, URL filtering block, authentication event and configuration change, pre-parsedAllow events end after route one. Cribl Search queries the archive for the rare investigation that needs them.
The routing split for firewall logsA firewall sends to a pipeline in front of the Splunk HTTP Event Collector. Route one sends every event, unfiltered, to an S3 bucket whose lifecycle policy moves it from hot storage to Infrequent Access to Glacier for the rest of the retention requirement. Route two passes only events whose action is not allow, every deny, threat, IPS hit, URL filtering block, authentication event and configuration change, on to Splunk. Allow events end after route one, and Cribl Search queries the archive for the rare investigation that needs them.THE ROUTING SPLIT FOR FIREWALL LOGSFIREWALLEvery session logged, allow and deny together.PIPELINETwo routes, deduplicated.ROUTE ONE: EVERY EVENTUnfiltered to S3. Hot, then Infrequent Access, thenGlacier for the rest of retention.ROUTE TWO: NOT ALLOWEvery deny, threat, IPS hit, URL block,authentication event and configuration change, toSplunk.Allow events end after route one. Cribl Search reaches them in thearchive.
Every firewall event lands in S3 at full fidelity for the whole retention period, and only the events detections use go on to Splunk. The allow logs leave the analytics tier without leaving your reach.

What stays in Splunk

Everything that powers a detection. Every event that populates a dashboard. Every record an investigator pulls during triage. Your correlation searches, your saved searches, your SPL dashboards, and your existing Technology Add-on integrations all continue to function against the same schema they have always used. Nothing changes on the Splunk side except the volume the indexer sees.

For the narrow class of incident response where allow logs are needed, Cribl Search queries the S3 archive using the same field model. The analyst workflow becomes: query the last ninety days from Splunk for denies and threats, then query the full retention window from S3 for corresponding allows if the case warrants it. Most investigations never need the second query.

What lives in S3

Every log the firewall produced, at full fidelity, stored for the full retention period, queryable within the audit response window. Auditors get the archive. Compliance teams get the retention. The SOC gets the investigation depth on the rare cases that need it. The CFO gets a cost profile that matches the actual utility of the data.

A two-week proof on one source

Route a single firewall through this split for two weeks. Measure three things. The percentage of events suppressed by the allow filter. The percentage of detection rules that still fire correctly with the reduced input stream. The change in daily Splunk ingest attributable to that source.

One source is enough to prove the architecture. If the detections still fire, if the compliance path still resolves, and if the volume reduction matches what Splunk’s own sourcetype breakdown predicted, the rollout to the rest of the firewall fleet is mechanical. The same split then extends to authentication success events, DNS queries, and DHCP, one source at a time. TransUnion took DNS and Sysmon from about 1 TB a day to about 150 GB, about 85 percent, as Cribl published it (Cribl case study, 29 August 2023).

The structural takeaway

Your SIEM is an analytics platform. You should be paying for the analytics you use, not the storage you do not. Firewall allow logs are the clearest example of a category where the cost model and the utility model diverge. Routing them out of the SIEM and into object storage does not change your security posture, does not break compliance, and does not require analyst retraining. It moves a line item off the analytics-tier bill.

Paying analytics prices for data nobody queries is defensible only if the data is genuinely unrecoverable from anywhere else. For firewall allows, it is not. The pipeline architecture that fixes this is not experimental, and the components involved have been in production for years. The only unusual thing about this conversation is how rarely it happens before a renewal cycle forces it.

See your architecture drawn, with the costs, before you spend anything.

Our lead architects draw your SIEM feed from your diagrams: where the cost sits, what step one would change, and where it would not pay. If it pays, the next step is a two-week proof on your noisiest source.

Book the architecture reviewOr take the Blueprint as a PDF →

Free. No system access. No obligation. You keep the drawing.

What you get

  • Your architecture today, drawn
  • The waste map
  • Costs before and after, with estimates
  • Your target architecture
  • Options for your business problem

What it costsNothing