Originally published May 13, 2025. Updated August 19, 2026 with current cost benchmarks, customer results, and a rebuilt architecture diagram.
TL;DR: SIEMs bill by volume, so the fastest way to cut the bill is to stop sending them data they were never going to use. Map your sources and your destinations, price each source against your SIEM’s rate card, then route high-fidelity security events to the SIEM and push everything else — DNS, DHCP, proxy, compliance archives — to cheaper tiers. Most teams find 40–70% of what they ingest does not belong in the SIEM. Realm customers have cut 83% of firewall volume for $254,901 a year and 86% of high-volume log data with zero detection gaps. Estimate your own savings in ten seconds.
Key takeaways
- The bill is a routing problem, not a storage problem. Traditional SIEMs charge by GB/day, so every log you send to the wrong destination is a recurring line item.
- Roughly 90% of what most SOCs collect is routine noise. Firewall allows, successful authentications, DHCP, DNS, and debug logs drive volume without driving detection.
- Measure before you cut. Baseline daily volume by source, convert it to dollars per source, then tag each log type Critical, Useful, or Unused.
- Send the SIEM only high-fidelity, real-time security events. Everything else belongs in a data lake, a cold archive, or nowhere at all.
- Validate every cut against the detections you actually run. A reduction you cannot prove was safe is a reduction your SOC will not approve.
- 40–70% reduction is the normal range, and single high-volume sources routinely go higher — 83% and 86% in the two customer results cited below.
Security teams today face a daunting challenge: an explosion of security data and skyrocketing SIEM costs. As organizations deploy more firewalls, endpoint agents, cloud services, and network sensors, the daily volume of logs has surged. In a modern SOC, it’s not uncommon to field thousands of security alerts per day, with some teams reporting over 100,000 alerts daily. Yet as much as 67% of alerts are never investigated, often because analysts are drowning in low-value noise. All this data comes at a price, literally. SIEM and XDR platforms that charge by ingestion volume are straining budgets. Even a moderate deployment pulling in ~100 GB of logs daily can incur around $150,000 per year in SIEM licensing fees. And with average log volumes growing about 50% year-over-year, those costs (and the data overload) will continue to rise.
In our first post, we introduced the concept of a security data fabric as a smarter, more efficient way to handle all that telemetry without drowning in cost or complexity. Now, in this blog, we’re going hands-on.
This post is for the engineers in the trenches. We’ll walk through how to look at your data sources, understand where your logs are going, and estimate how much value (and cost) each destination delivers. You’ll come away with a practical framework for cutting SIEM costs without losing the visibility your team depends on.
Let’s dig in.
The SIEM Cost Crunch and Why Log Volume Management Matters
For many enterprises, SIEM cost optimization has become a pressing issue. Traditional SIEMs charge based on data volume (GB per day or events per second), which means the more logs you ingest, the more you pay. As security data expands, budgets can spiral out of control. Enterprises ingesting terabytes of data daily often spend millions of dollars yearly on SIEM tools. This creates a painful trade-off: pay exorbitant fees or limit what you send to the SIEM (potentially missing valid data).
Why are we collecting so much data in the first place? The truth is that not all logs are equally helpful. In practice, many collected logs provide little to no detection value. Organizations often ingest everything by default, and the firewall allows and denies every authentication attempt, system debug messages, and “just in case.” Over time, this leads to data bloat: huge volumes of events stored in an expensive SIEM, even though perhaps 90% of that data is routine noise. The outcome is both financial and operational inefficiency. You’re paying to store mountains of irrelevant data, and your analysts are wading through noise to find the real threats.
This is where log volume management becomes critical. You can drastically cut costs and noise without losing essential visibility by intelligently culling the deluge of events. For example, filtering out redundant or low-risk logs can shrink SIEM ingest volumes dramatically. Many organizations report 40–70% reductions in log volume sent to high-cost platforms without losing visibility. In other words, you can see the signal instead of the noise, and pay only for the data that truly matters.
Effective log management doesn’t mean throwing data away indiscriminately. It means understanding your data, where it comes from, who needs to use it, and how long it needs to be kept, and then making informed decisions about where each stream of data should live. This brings us to the concept of a security data fabric as the architectural answer to the SIEM cost crunch.
Understanding Your Data Sources and Destinations
To get a handle on log costs, start by mapping out your data sources and data destinations. In a typical enterprise security stack, you might have sources such as:
- Firewall and Perimeter Devices: Network firewalls, IDS/IPS, VPN gateways producing connection logs, threat alerts, and traffic metadata.
- Endpoints and Servers: EDR/EPP agents, operating system event logs, server application logs, and IoT device telemetry.
- Network Infrastructure: Switches, routers, WLAN controllers, DNS servers, and other network devices emitting syslogs and flow records.
- Cloud and SaaS Services: Cloud platform logs (e.g., AWS CloudTrail, Azure AD), SaaS security logs (from Okta, Office 365, Salesforce, etc.), and identity/IAM logs.
- Security Tools: Outputs from DLP, vulnerability scanners, email security gateways, data from SOAR or threat intel platforms.
Each of these sources generates a firehose of events. Now, consider your data destinations, the platforms or tools where this data ends up for analysis or retention. Common destinations include:
- SIEM (Security Information and Event Management): Your primary analysis and correlation engine used by the SOC. (Often the most expensive destination.)
- XDR Platforms: Extended Detection & Response tools that ingest endpoint, network, and cloud telemetry to detect threats across domains.
- MDR Services: Managed Detection and Response providers that you send logs or alerts to for third-party monitoring.
- Data Lakes or Archives: Big data platforms (like a security data lake in Snowflake or an S3 archive) used for long-term storage, compliance, or retrospective analysis.
The key insight is that not every destination needs every log. Different teams and tools have distinct data needs. Here’s how to think about routing logs with intention:
| Destination | Send it | Keep it out |
|---|---|---|
| SIEM | Send itAuth failures, privilege escalations, critical alerts, malware and policy detections, identity anomalies, lateral movement indicators | Keep it outSuccessful logins to non-sensitive assets, bulk firewall allows, bulk DNS queries, debug-level application logs |
| Data lake | Send itRaw full-fidelity logs from all sources, threat-hunting and ML datasets, benign-but-voluminous DNS, DHCP, and proxy data | Keep it outAnything you need correlated in real time — lakes give you depth, not speed |
| MDR / MSSP | Send itFinal alerts and incidents with context, high-severity detections, IOC matches and escalated triage cases | Keep it outRaw syslog, non-alerting telemetry, duplicate data already covered in your contract, anything carrying PII or PHI |
| Compliance archive | Send itAdmin logins and configuration changes, firewall connection records, audit trails for financial or regulated systems | Keep it outThe live SIEM — unless an active policy requires real-time visibility on that data |
| XDR | Send itLet it collect its own native endpoint and identity telemetry directly | Keep it outThe same logs duplicated into the SIEM, which is how you end up paying two ingestion fees for one event |
For Your SIEM: Prioritize High-Fidelity, Real-Time Security Events
The SIEM is your central detection engine—but it’s also your most expensive destination. Limit what you send to:
- Authentication failures and privilege escalations
- Critical system errors and alerts
- Malware or policy violation detections
- Asset or identity anomalies
- Lateral movement indicators (e.g., new internal RDP connections)
Avoid sending:
- Successful logins (unless for sensitive assets)
- Firewall allows or DNS queries in bulk
- Debug-level application logs
Review the top 10 log types by volume in your SIEM. They likely don’t belong there if they don’t align with a detection rule or a runbook.
For Your Data Lake: Offload Full-Fidelity Logs for On-Demand Analysis
Data lakes are ideal for:
- Retaining raw logs from all sources
- Supporting threat hunting, forensics, and machine learning
- Storing benign-but-voluminous data (e.g., DNS, DHCP, proxy logs)
They’re cheaper and more flexible than a SIEM, but lack real-time correlation. Use them for depth, not speed.
Route “noisy but contextual” logs like DNS, DHCP, and NetFlow to your data lake only. At ingest, normalize everything to a consistent schema like OCSF (Open Cybersecurity Schema Framework). This ensures you can correlate and search across all your logs later with consistent, high-quality results, even if they weren’t used in real-time detection.
If you would rather not run the lake yourself, Data Haven keeps a complete, searchable copy of everything you reduce out of the SIEM, so the events are still there when an investigation or an audit asks for them.
For Your MDR or MSSP: Send Only Enriched, Actionable Alerts
Managed services don’t want to sift through raw telemetry. Give them:
- Final alerts or incidents with context
- High-severity detections from your SIEM/XDR
- IOC matches or escalated triage cases
Avoid sending:
- Raw syslogs
- Non-alerting telemetry
- Duplicate data already covered in your contract
Set up forwarding rules to send only alerts tagged as “high,” “critical,” or “needs review.” Before flipping the switch, double-check with your MDR what data they actually ingest and respond to. Assumptions here can be expensive.
Just as important: inspect outgoing logs for sensitive data like PII or PHI. Accidentally sharing regulated information with an external vendor could violate customer agreements or internal compliance standards. Privacy Guard handles this at the pipeline layer, redacting regulated fields on the way out without stripping the values your detections still need.
For Compliance and IT Teams: Archive What’s Required, Access When Needed
Retention and audit teams care about completeness, not speed. Place these logs in low-cost cloud storage:
- Admin logins and configuration changes
- Firewall connection records
- Audit trails for financial or regulated systems
Avoid routing to live SIEM unless there’s an active policy requiring real-time visibility.
Automate archiving rules that move logs to cold storage after 30–90 days. If auditors only request data quarterly, don’t pay for 24/7 access.
For Your XDR: Avoid Duplicating What It Already Collects
Many XDR tools natively collect endpoint and identity telemetry. If that’s the case:
- Let XDR collect its native data (e.g., CrowdStrike, Defender)
- Don’t send the same logs into your SIEM unless absolutely necessary
- Use your data fabric to route flows, not duplicate them
Audit your XDR connectors. If it’s already collecting from a log source directly, disable redundant forwarding to the SIEM to avoid double ingestion fees.
Security Data Fabric Architecture: Mapping Sources to Destinations
Once you know your sources and destinations, the next step is implementing a smart traffic cop in your architecture, that’s the role of a security data fabric. A security data fabric is essentially a unified data pipeline purpose-built for security, sitting between all those data sources and all your destinations. Its job is to centralize control over what data goes where, in what format, and at what frequency. Instead of every tool ingesting directly from each source (creating a tangle of feeds and lots of duplicate or irrelevant data in expensive places), the fabric acts as an intelligent broker.
Sources
Destinations
Figure 1: Example of a security data fabric architecture.
In the diagram above, notice how the Security Data Fabric ingests from all sources, but then makes decisions on where to send each piece of data:
- Critical security events (after normalization and enrichment) are sent to the SIEM, ensuring the SOC has important signals in real time without paying to index useless data.
- Endpoint telemetry and other data needed by the XDR platform can be forwarded in a compatible format (and perhaps omitted from the SIEM if the XDR handles those).
- Key alerts or incidents can be routed to an MDR service or ticketing system, ensuring your external monitoring partner or IR team gets the necessary information.
- Meanwhile, raw logs or full log archives can stream into a low-cost data lake or cloud storage bucket, fulfilling retention requirements and allowing deeper analysis outside the SIEM.
This architecture provides a few significant advantages:
1. Cost Control: You can dramatically reduce the volume ingested into high-cost tools by filtering out redundancies and low-value events. (For example, you might drop verbose debug logs or index only summaries of high-frequency events.) Only the data that’s worth the cost makes it to the SIEM.
2. Noise Reduction: Curating the data before it hits your analysts’ consoles reduces alert fatigue. The fabric might suppress or deduplicate noisy events so the SIEM doesn’t repeatedly trigger on the same benign activity.
3. Flexibility: A fabric decouples sources from destinations. Want to send firewall logs to a new analytics tool or split off a feed for a fraud detection team? The fabric can do that without touching the firewall or burdening the SIEM. It also eases migrations. If you switch SIEM vendors or add an XDR, you don’t need to re-engineer dozens of integrations; the fabric layer redirects the data flow.
4. Centralized Management: Instead of maintaining log collection scripts on every system or custom ETL jobs for each destination, you manage data routing in one place. This is far easier to maintain and govern. (It’s worth noting: organizations that try to build this in-house often find it “scales poorly, is error-prone, and hard to maintain” without dedicated engineering effort.)
In essence, the security data fabric gives you a single pane of glass for your security telemetry. You regain control by deciding which logs go to the SIEM, which can be shunted to cheaper storage, and which might not need to be collected at all. The result is the ability to own your data strategy instead of letting the SIEM licensing model dictate what you can afford to monitor.
If you are at the stage of evaluating vendors for this layer, the third post in this series walks through what to look for in a security data fabric, and we have written a direct comparison of Cribl and its alternatives if that is on your shortlist.
Practical Steps to Right-Size Your Logging (and Budget)
Adopting a security data fabric approach starts with some practical groundwork. Here are key steps and considerations for engineers to begin log volume management and cost reduction:
1. Measure Your Daily Log Volume
Start by establishing a baseline. Use your SIEM’s dashboards or license usage reports to determine how much data is ingested daily. Break it down by source wherever possible (e.g., firewalls: 30%, EDR: 25%, cloud logs: 20%, etc.). This will help you identify where your most significant data contributors are.
Also, take note of ingestion spikes and anomalies. Are there sources that suddenly generate large volumes during patch cycles, reboots, or outages? These patterns are key to optimizing later.
Export 7–14 days of ingestion metrics by source and load them into a spreadsheet. Add a column to estimate the daily cost per source based on your SIEM’s pricing model. This quick exercise often highlights low-value, high-cost sources hiding in plain sight.
Once you’ve built that baseline, set up real-time alerts for dramatic fluctuations. Spikes might indicate misconfigurations, malicious activity, or even downstream issues with detection workflows. They’re also crucial for maintaining SLA performance if your team is responsible for fast response times.
2. Calculate Your Ingestion Costs
Translate your log volume into dollars. Calculate your monthly and annual spend per source category if your SIEM or XDR tool charges by GB/day. Even if your vendor offers “ingestion tiers,” you can estimate overage or burst costs from recent peaks.
This is also a good moment to review storage and retention charges. Some SIEMs charge separately for historical searches or “hot” vs “cold” storage tiers. The mechanics differ enough between vendors that it is worth reading your own: we have broken down Microsoft Sentinel, CrowdStrike NG SIEM, Sumo Logic, and Google SecOps pricing model by model.
The Realm SIEM Cost Calculator turns your daily ingest, source mix, and detection count into two numbers in about ten seconds: how much of your data has to stay, and what your estimated cost reduction is.
Estimate your savings →If your SIEM doesn’t expose cost-per-source breakdowns, create one manually using estimated volume x cost per GB. Present this in your next budget review to highlight optimization opportunities and justify routing changes.
3. Identify High-Volume, Low-Value Logs
Now it’s time to separate signal from noise. Engage with SOC analysts, threat hunters, and IR teams to understand which logs are used for detection, investigation, or compliance, and which ones aren’t.
Common culprits for noise:
- Firewall allows (vs. denies)
- Successful authentications
- DHCP logs
- DNS queries
- Web proxy logs
- Repetitive endpoint heartbeat/status messages
Look for logs that are high-frequency but low-fidelity. These often contribute little to detection efficacy but drive up ingest costs.
This is also the step where the conversation usually stalls, because “low-value” is a judgment call and nobody wants to be the person who cut the field a detection needed. Two things make it tractable: Clarity AI profiles each source down to the field level and recommends what is safe to reduce, and Detection Integrity checks every proposed cut against the detections you actually run — Sigma, SPL, KQL, CQL, SentinelOne, Cortex XDR — and protects the exact fields each one depends on.
Pull a sample day’s logs and sort them by event count. Then tag each log type as Critical, Useful, or Unused. Use this to prioritize what can be filtered, summarized, or offloaded to cheaper storage.
4. Reallocate Logs to the Right Destinations
This is where cost savings really materialize. Once you’ve mapped value and volume, reroute logs accordingly:
- Critical real-time alerts → SIEM or XDR
- Detailed telemetry for investigation → data lake
- Compliance logs → archive or cheap cold storage
- IT operations data → internal tools or databases
Avoid duplicating data across destinations unless necessary. For example, if your XDR already ingests EDR logs, you may not need to send them to your SIEM too.
Create a routing matrix that shows each log source and where its data should go. Then, start implementing changes one source at a time. Start with low-risk sources like the firewall or internal DNS.
5. Tune Retention and Granularity
You don’t need to keep every log forever. Set different retention windows for each destination:
- 30 days in SIEM for fast queries
- 180+ days in cold storage or archive
- Long-term compliance retention in cheap cloud buckets
Also consider adjusting the granularity of logs, summarizing repetitive entries, dropping debug-level messages, or storing only metadata for high-volume sources like DHCP.
Automate log tiering: Set up rules that move logs from your SIEM to cold storage after 30 days, or store full logs for 7 days and summaries afterward. Most data fabric platforms can orchestrate this without manual intervention.
Collaborate with stakeholders, your SOC analysts, compliance officers, IT admins, and external partners throughout these steps. Make sure the new data routing still meets each group’s needs. Done correctly, you’ll maintain or even improve everyone’s visibility while significantly cutting costs. It’s common to find that after tuning, your SIEM might be ingesting only half the daily volume it used to, focusing on the most valuable 30–50% of data. The rest is handled by cheaper layers or not at all, immediately reflecting reduced licensing usage.
What This Looks Like on Real Data
The 40–70% range above is the number teams generally land on across a full estate. On a single high-volume source, the first one you point at, it is usually higher. Two published examples:
Vensure Employer Solutions went after the single most expensive driver of their SIEM spend: FortiGate firewall logs. Daily ingestion on that source dropped from 350 GB to 60 GB, and their annual cost on it fell from $215,535 to $36,640. Denied connections, unusual port activity, and policy violations kept reaching the SIEM in full.
“Realm’s Data Filtering module allows us to remove data that would never be needed for detection or an investigation. This saves us a significant amount of operational budget, which can be repurposed for other strategic priorities. This is a game-changer for budget-constrained security teams.”
— Dwayne Smith, Sr. VP Information Security & Global CISO, Vensure Employer SolutionsA global consulting and advisory firm watched its Microsoft Sentinel spend grow from $75K to $200K over three years, driven by firewall and proxy logs. A 40-hour manual filtering effort the year before had barely moved the number. Validating every cut against their live CrowdStrike rule set, they cut Fortinet and Zscaler volume by 86% with zero detection gaps, and moved their three-year retention requirement out of Sentinel entirely — which by itself offset roughly a third of the bill.
Both followed the same sequence this guide describes: pick one high-volume source, measure it, price it, confirm what actually feeds a detection, and route the rest somewhere cheaper.
Conclusion: Spend Smarter on Security Data
In the face of relentlessly growing log volumes and tightening budgets, taking control of your security data pipeline is one of the smartest and most impactful moves a security team can make. Organizations can dramatically reduce SIEM costs by adopting a security data fabric architecture and practicing disciplined log volume management while improving visibility, agility, and operational resilience.
The key is simple: send the right data to the right place. High-fidelity, time-sensitive logs belong in high-performance tools like your SIEM or XDR. Everything else, contextual logs, compliance data, and archival records, can be filtered, summarized, or rerouted to lower-cost destinations without sacrificing coverage.
Teams that embrace this approach are already seeing the benefits:
- Lower ingestion and storage bills
- Less analyst fatigue from alert noise
- Faster incident investigations
- Greater freedom to evolve or migrate their tooling
And they’re doing it without making trade-offs on visibility or compliance. A well-architected security data fabric provides the flexibility to adapt, the control to enforce, and the intelligence to optimize, so you’re not held hostage by log volume growth or vendor pricing models.
At Realm.Security, we designed our platform specifically for this challenge. We believe security engineers shouldn’t need professional services, brittle regex scripts, or six-month deployments to manage their data. Our platform puts you back in control, enabling you to filter, route, and optimize log flows in minutes, not months.
If you’re ready to reduce SIEM costs and reclaim control over your security data architecture, let’s talk. Schedule a demo today!
Reducing SIEM Costs: Frequently Asked Questions
How much can you reduce SIEM costs with a security data fabric?
Many organizations report 40 to 70 percent reductions in log volume sent to high-cost platforms without losing visibility. Realm customers land in and above that range on the sources they start with: Vensure Employer Solutions cut FortiGate firewall volume reaching Sumo Logic by 83 percent for $254,901 in annual savings, and a global consulting firm cut Fortinet and Zscaler volume reaching Microsoft Sentinel by 86 percent with zero detection gaps. Savings scale with how much of your ingest is high-volume, low-fidelity data, which is why the first step is measuring your daily volume by source.
What is a security data fabric?
A security data fabric is a unified data pipeline purpose-built for security, sitting between all your data sources and all your destinations. Its job is to centralize control over what data goes where, in what format, and at what frequency. Instead of every tool ingesting directly from each source, the fabric acts as an intelligent broker: it filters, normalizes, and enriches events in motion, then routes each one to the destination that actually needs it.
Which logs should go to your SIEM and which should go somewhere else?
Send your SIEM high-fidelity, real-time security events: authentication failures and privilege escalations, critical system errors and alerts, malware or policy violation detections, asset or identity anomalies, and lateral movement indicators. Avoid sending successful logins unless they are for sensitive assets, bulk firewall allows or DNS queries, and debug-level application logs. Noisy but contextual data such as DNS, DHCP, and NetFlow belongs in a data lake, compliance records belong in low-cost archive storage, and managed services should receive only enriched, actionable alerts.
How do you calculate your SIEM ingestion costs?
Translate your log volume into dollars. If your SIEM or XDR charges by GB per day, calculate your monthly and annual spend per source category. Even if your vendor offers ingestion tiers, you can estimate overage or burst costs from recent peaks. Review storage and retention charges separately, because some SIEMs bill differently for historical searches or hot versus cold storage tiers. If your SIEM does not expose cost-per-source breakdowns, build one manually using estimated volume multiplied by cost per GB.
Does reducing SIEM log volume break your detections?
It can, if the reduction is done blind. That is the risk that stops most teams from pulling the volume lever at all. The safeguard is to check every proposed cut against the detections you actually run and protect the exact fields each one depends on before the change ships. Realm calls this Detection Integrity, and it produces a report showing what was reduced, what was protected, and your MITRE ATT&CK coverage before and after. A global consulting firm used it to cut 86 percent of its high-volume log data with zero detection gaps.
What is the difference between a security data fabric and a security data pipeline?
In practice the terms describe the same architectural layer and are often used interchangeably. Fabric emphasizes the connective breadth of the layer, while pipeline emphasizes the directional flow of data through it. Both refer to the tier between your sources and your destinations that collects, filters, normalizes, enriches, and routes security telemetry so that expensive tools only ingest data that carries real value.
Where do you start reducing SIEM costs?
Start with one high-volume source, usually firewall logs. Measure its daily volume, price it against your SIEM’s rate card, confirm with your SOC analysts which of those events feed a detection or a runbook, and route the rest to cheaper storage. Starting with a single low-risk source gives you a real savings number and a repeatable pattern before you touch anything sensitive.
See what your SIEM bill could look like → Two numbers in ten seconds: how much of your data has to stay, and what you would save.
