The objection that stops most cost conversations
Every Cribl pitch eventually hits the same question from the SOC or compliance side of the room. If the pipeline is cutting forty to seventy percent of ingest volume, what happens when we actually need that data back. What about the incident response scenario where we are trying to reconstruct a breach from six months ago. What about the audit request where a regulator wants a specific event we dropped to save money.
It is the right question. It is also the wrong framing.
Reduction at the pipeline layer does not mean dropping logs. It means routing them. The expensive SIEM tier receives only what actually drives detection and alerting. Everything else, including the dropped firewall allow logs, the Windows event noise, the health-check chatter, and the full audit trail, streams in parallel to object storage at a fraction of the cost. When an incident or an audit request arrives, the pipeline replays the exact events back into the SIEM, or into any other destination, on demand.
The data is not gone. It was never stored in the wrong place to begin with.
Where reduction actually happens
The mental model most people carry into a Cribl conversation is a single pipe. Data comes in at the top, and the pipeline drops a percentage at the bottom. With that model, reduction sounds like lossy compression. Forty percent reduction equals forty percent of events discarded.
The actual architecture is a fan-out. A single event enters the pipeline and can be written to multiple destinations in different shapes, at different fidelities, under different retention policies. The Splunk route receives a filtered, enriched, high-signal version of the event. The S3 or Cribl Lake route receives the full original event in an open format for long-term storage. The APM route receives only the metrics that belong to an operational dashboard.
Reduction is a property of the Splunk route, not of the pipeline as a whole. The cold storage route is unreduced. The compliance archive is unreduced. The forensic copy is unreduced. What got reduced was the expensive part of the system, not the data itself.
The cost delta that makes this work
Splunk ingest pricing is denominated in dollars per gigabyte per day of commitment, which converts to a list effective cost of roughly five to seven dollars per actual gigabyte ingested at mid-volume, and higher with Enterprise Security or other premium add-ons. Microsoft Sentinel analytics tier is currently around $2.76 per gigabyte. Datadog bills logs twice, once at ingest and once at index, with custom metrics commonly representing thirty to fifty percent of a mature account.
Object storage prices for the same gigabyte are roughly $0.02 to $0.05 per month at list, before compression. Parquet compression typically buys a factor of five to ten on log data. After compression, a gigabyte of raw logs costs somewhere between $0.002 and $0.005 per month to retain indefinitely on S3, Azure Blob, Cribl Lake, or Google Cloud Storage.
The ratio matters more than the absolute numbers. A gigabyte of logs in the SIEM analytics tier costs between 100 and 1,200 times more per year than the same gigabyte in object storage, depending on the tier and the compression ratio you achieve. That gap is what makes the architecture viable. If you can move eighty percent of volume from the expensive tier to the cheap tier, and still reach every byte on demand, you have cut the bill without losing the data.
The replay mechanism
The replay path depends on two choices made at the pipeline. The first is the storage format. Cold storage is most useful when it is written in an open, queryable format. Parquet is the common choice because it is columnar, compressed, and readable by almost every analytics engine. OCSF, ECS, or ASIM schemas layered on top of Parquet make the data correlatable across sources without reverse engineering vendor field names.
The second is schema consistency. If your pipeline normalizes data before it writes to cold storage, the archive contains uniform field names, uniform timestamps, and uniform user and device identifiers. Six months later, when an investigation needs to reconstruct a login sequence across a firewall, an identity provider, and an endpoint, the query runs in one language against one schema. No per-source translation.
With those two decisions in place, replay is a routine operation. The pipeline reads the relevant events from object storage, filters by the time window and source or indicator of compromise, and re-streams them into whichever destination the investigation needs. That destination can be the original Splunk or Sentinel cluster, a specialist forensic platform, a data lake query engine, or a newer SIEM you are evaluating. The source of truth stays in object storage. The consumers are interchangeable.
What this looks like during a real incident
Assume a security analyst gets an alert on a suspicious authentication from an external IP. The alert fired in Splunk because the pipeline routed authentication events into the Splunk analytics tier. Good so far.
The analyst pivots and asks the obvious follow-up questions. What did this IP do in the thirty days before the alert fired. Did any other users in this organizational unit see the same source IP. What firewall activity preceded the authentication. Those events are not in Splunk, because the pipeline decided during the initial ingest that firewall traffic and low-privilege activity did not belong in the expensive tier.
They are in S3 or Cribl Lake, in the original format, enriched with user and device context, schema-aligned to OCSF. The analyst issues a Cribl Search or a lake query against the relevant time window and source filter. Results stream back and can be promoted into the SIEM for correlation with the active alert, or queried in place for the investigation.
The analyst is not waiting days for a tape restore or a cold archive rehydration. The analyst is querying live data in a cheaper tier, replaying exactly what is needed, and leaving the rest of the archive untouched. The SIEM bill does not move, because the replay targets a specific investigation scope rather than a blanket re-ingestion.
The same pattern applies to audit requests. When a regulator asks for a specific event from fourteen months ago, the compliance team queries the archive directly or replays the filtered result into the SIEM for export. The full fidelity original was never dropped.
How this differs from SIEM archive tiers
Most SIEMs now offer some version of a lower-cost retention tier. Splunk has SmartStore for indexer-managed S3 tiering and a separate Dynamic Data Self Storage option for long-term archive. Sentinel has Basic Logs and Auxiliary tiers. Elastic offers frozen tiers through its searchable snapshot model. These are useful products, and in many cases a Cribl-routed architecture will use them for portions of the archive.
The architectural distinction is about control. With a SIEM-managed archive, retention, schema, and replay policy live inside the vendor. The tier exists to serve that vendor's primary platform. Exports are possible but friction-heavy. If you ever move off that SIEM, the archive moves with you as a separate, vendor-specific migration project.
With a pipeline-managed archive, retention lives in your object storage, schema lives in your pipeline, and replay targets any destination. The archive survives vendor migrations unchanged. If you move from Splunk to Sentinel, the pipeline replays historical events from the same S3 bucket into the new SIEM with a new route, no data conversion, no re-collection from hosts.
That independence is what makes the replay strategy durable. You are not betting on a single SIEM's archive product being there in five years. You are betting on open formats, which have longer useful lives than any enterprise software contract.
What you do not lose by reducing
Full-fidelity data. Every event the pipeline receives lands in cold storage with its original content intact, unless you explicitly chose to drop it for PII or compliance reasons before persistence.
Compliance coverage. Retention on object storage is a policy setting on a bucket. Most regulatory frameworks accept immutable object storage with access controls and integrity verification, which S3 Object Lock and Azure Blob immutability policies provide natively. Your audit trail is stronger, not weaker, because it sits in a system designed for long-term retention rather than in a SIEM whose retention can be changed by any admin with the right role.
Investigation depth. Analysts can query the archive for anything the alert did not capture. The limitation on investigation depth in most environments is not data availability. It is data affordability. Reducing to a cheaper tier increases the amount of history you can afford to keep, which increases investigation depth.
Replay flexibility. Any event can be replayed into any destination, so the archive is usable for a new SIEM evaluation, a forensic platform, or a one-off regulator request without rebuilding the collection layer.
What reduction does actually cost
Two things change in practice. The first is that detection engineers need to agree on which events belong in the analytics tier and which do not. That is a real conversation, because it forces explicit prioritization on a pipeline that historically accepted everything by default. The payoff is that the prioritization is captured in pipeline logic, not in tribal knowledge, and new sources can be onboarded with clear routing rules instead of automatic full-tier ingestion.
The second is that investigation workflows change slightly. Analysts learn to query the archive directly for context rather than assuming everything is in the SIEM. This is a minor tooling shift for most SOCs, and Cribl Search, Splunk federated search, Sentinel basic-logs KQL, and data lake query engines all support the pattern.
Neither of these is data loss. Both are tradeoffs that most teams accept immediately once they see the cost delta.
Where to start
Pick one high-volume source, usually firewall traffic or Windows event logs, and route it through a Cribl pipeline for thirty days. Configure the pipeline to write the full original event to object storage and a filtered subset to your SIEM. Run a replay scenario on week three, pulling a specific IP's activity from the archive back into the SIEM to simulate an incident lookup. Measure the cost of the reduced SIEM ingest against the cost of the archive storage. The ratio is usually decisive.
The pattern scales from there. Each additional source that moves to the routed model reduces the analytics tier load and expands the archive. The SIEM gets leaner. The archive gets deeper. And when the audit request or the incident lookup arrives, the answer is already in cold storage, waiting to be replayed.
Reduction at the pipeline layer is not a compromise between cost and coverage. It is the only architecture that improves both at the same time.
Related reading
The replay strategy is one slice of a broader architectural shift. If you are working through adjacent pieces, these blogs and pages cover the neighboring ground in more detail.
- Route Before You Index: How Cribl Reduces Splunk Costs 40 to 70 Percent is the companion piece for teams evaluating which sources belong in the SIEM versus the archive in the first place. It walks through the firewall-allow reduction case, which is the most common starting point for the replay pattern described above.
- SIEM Migration Without the 9-Month Disaster covers how the same replay mechanism doubles as a migration engine. When the archive is schema-aligned and stored in an open format, historical data re-streams into a new SIEM without re-collecting from hosts.
- Firewall Allow Logs: Why You're Paying Splunk $500K a Year for Data Nobody Searches expands the cost delta on a single source category and demonstrates the analytics-tier-versus-archive math in concrete dollars.
On the platform side, our Cost Optimization solution page lays out the full routing model across SIEM, APM, and object storage tiers. If your specific driver is platform independence, the Vendor Lock-In page describes how open-format archives decouple data from any single SIEM contract. For teams actively planning a platform transition, the SIEM Migration solution maps replay into a source-by-source cutover that eliminates the parallel-run period.
The discovery call
If you are evaluating whether this architecture applies to your environment, the fastest path to a defensible number is a one-source, thirty-day test. Route a single high-volume source through a Cribl pipeline with a dual write to your SIEM and to object storage. Measure the cost delta. Execute a single replay to prove the forensic path works under a real incident scenario. At the end of thirty days you have a SIEM cost curve, an archive query time, and a replay playbook that every downstream source can inherit.
Schedule a discovery call and we will scope the single-source test against your current SIEM, your current storage posture, and the specific sources driving your ingest volume. A thirty-minute call is usually enough to pick the right pilot source and agree on the replay scenario to validate.
The SIEM bill is a lagging indicator of a decision you already made about where your data lives. Change the decision, and the bill follows.