Resources / Blog / A Detection Engineer's Guide to Cutting SIEM Costs

September 4, 2025

A Detection Engineer's Guide to Cutting SIEM Costs

Blog

Asante Babers

Detection Wizard

About

Darwin Salazar

Head of Growth

About

Introduction

What if you could trim your SIEM bill significantly by just filtering event types that aren’t relevant to security from being ingested into your SIEM?

It might sound too good to be true, but, after over two decades of combined detection engineering and security experience, we’ve found that a significant percentage of SIEM costs come from storing low-value events like:

Successful sign-outs
Health check pings
Irrelevant metadata
Duplicative or redundant events

These types of logs can account for a significant portion of daily event volume, silently inflating SIEM costs while offering minimal detection or investigative value.

Monad helps security teams reclaim that spend by enabling engineers to filter out unnecessary noise before it hits your SIEM.

‍In this post, I'll show you how filtering just one log source - Okta - can cut your costs for that source by ~50%, saving tens of thousands annually. Apply similar optimizations across multiple log sources, and you can achieve meaningful reductions in your overall SIEM spend.

The True Cost of Low-Signal Events

Okta’s System Logs is one prime example that I’m very familiar with. They capture rich context for every authentication event, including logins, logouts, and debug metadata. While compliance requirements may mandate preserving this data, not all of it is essential for real-time threat detection.

You can satisfy compliance and incident response needs by archiving a complete copy of all logs in cost-effective cold storage (like S3), while only sending high-value security events to your expensive SIEM. When an incident occurs, you can still query S3 for historical context, reconstruct user sessions etc. There's no compliance requirement that says you need to store routine sign-outs in a system that costs $25/GB/day when S3 costs $0.023/GB/month.

At a high level:

user.session.end (sign-out) events can account for a portion of all Okta logs
These events have low threat detection value, but contribute significantly to SIEM costs
Filtering them out pre-SIEM while archiving everything to S3 gives you the best of both worlds: complete audit trails for compliance and forensics in cheap storage, while your SIEM budget focuses on events that actually matter for threat detection

Other Low-Value Okta Events to Consider Filtering

Beyond sign-outs, many other Okta event types offer little or no value for threat detection:

Important: We're not entirely discarding these events. They're archived to S3 for compliance and forensics. When needed, teams can retrieve the full history within minutes.

In this post, we'll walk through value-based filtering step-by-step: how to identify and drop low-value events before they inflate your SIEM costs. (We'll cover smart routing in a follow-up post, where we'll explore sending different events to different destinations based on their security value.)

‍
Sample Okta Sign-Out Event (Pre-Transformation)

{
  "eventType": "user.session.end",
  "severity": "INFO",
  "outcome": {
    "result": "SUCCESS"
  },
  "actor": {
    "id": "00u1abcd123",
    "type": "User"
  },
  "debugContext": {
    "debugData": {
      "requestId": "abcd1234efgh5678",
      "dtHash": "a7b8c9d10e112f13...",
      "requestUri": "/login/signout",
      "url": "/login/signout?code=***"
    }
  },
  "request": {
    "ipChain": [
      {
        "ip": "192.0.2.1",
        "geographicalContext": {
          "city": "San Francisco",
          "state": "CA",
          "country": "US"
        }
      }
    ]
  }
}

~2,570 bytes per event—sign-out events and debug fields create unnecessary bloat when routed to SIEM.

The Solution: Filter Before You Ingest

Through event filtering and selective field removal, Monad customers can route only high-value security events to SIEM while archiving the full dataset to cost-efficient storage.

Transformation Strategy

For a given log source, identify low-value or irrelevant events and fields.
Send high-risk or admin activity events to SIEM (e.g., failed logins, privilege escalation)
Drop low-signal events, like routine sign-outs, from SIEM entirely
Optionally remove verbose fields (like debugContext) from other event types where those fields aren’t security-relevant
Archive all events to S3 to maintain compliance and searchability

Sample Case Study: Cost Comparison

Methodology

Event volume and size estimates are based on typical Okta System log samples with an average of ~2.5KB per event including metadata. Splunk costs are calculated using a commonly referenced rate of $25/GB/day as outlined in this Last9 breakdown of Splunk Pricing. AWS S3 storage is priced at $0.023/GB/month for standard storage in the us-east-1 region per AWS Official Pricing Page. Actual customer costs may vary based on compression, negotiated rates, deployment specifics, and other variables.

Before Monad Transformation

Event Size: 2,570 bytes
Events/Day: 1,000,000
Total Storage: 2.57 GB/day
Monthly S3 Cost: $1.77 (2.57 GB × 30 days × $0.023)
Monthly Splunk Cost: $1,927.50 (2.57 GB/day × $25/GB × 30 days)
Total Monthly Cost: $1,929.27

After Monad Transformation

Events:

SIEM Events/Day: 820,000 (1,000,000 - 180,000 low-value events)
S3 Archive: 1,000,000 events/day (everything still archived)

Storage Calculation:

Each event reduced from 2,570 bytes to 1,545 bytes (40% field reduction)
820,000 events × 1,545 bytes = 1.267 GB/day
Monthly S3 Cost: $1.77 (unchanged - still archiving all Okta logs)
Monthly Splunk Cost: $950.25 (1.267 GB/day × $25/GB × 30 days)
Total Monthly Cost: $952.02

Cost Impact

Here's where the savings becomes real - in our case study, the monthly SIEM cost for Okta logs drops from $1,947.70 to just $970.95 (a 50.14% reduction):

Annual Savings: $11,721 per million daily Okta events
3-Year Savings: $35,181
Percentage Savings: 50.7% reduction in Okta log costs

Note: To keep this case study simple and digestible, we use round numbers and focus on a single low-value event type (Okta sign-outs). In practice, achieving these levels of savings typically requires identifying and filtering multiple low-signal event types and optionally removing non-essential fields (like debugContext) across all event types where appropriate.

Scale Context: The 1 million daily Okta events used in this example represents a large enterprise deployment. While exact user counts vary based on authentication patterns, application portfolio, and security policies, this volume typically indicates a large organization with thousands of active users and extensive SSO adoption.

Scaling the Impact

The beauty of this approach is that it scales linearly with your log volume. The more events you process, the more you save. Here’s what that looks like with the 50.7% volume reduction for our Okta System Log data source:

This is tens of thousands in annual savings for just filtering on one single data source.. Imagine what that looks like when extrapolated out across all your data sources being ingested into your SIEM. Depending on scale, we can start getting to 6 and 7 figures in annual savings.

Implementing Filtering with Monad

Setting up this filtering in Monad is straightforward using our visual transformation builder. We provide pre-built operations that you can configure for any log source.

To drop Okta sign-out events, you simply:

Add a "drop record where value eq" operation to your pipeline
Configure it to drop records where eventType equals user.session.end
Save and deploy to your Okta data pipeline

The transformation builder offers a library of 15+ operations like:

drop record where value eq: Perfect for filtering out specific event types
drop key: Remove unnecessary fields like debugContext
flatten: Restructure nested data
mutate: Transform field values
And many more...

Once you configure the "drop record where value eq" operation for Okta's eventType field, you can reuse this same transformation across all your Okta pipelines. Similarly, if other log sources have an eventType field with user.session.end values, the transformation would work there too. The key is that the operation looks for specific field names and values in your data.

Once deployed, you'll immediately see the impact in your pipeline metrics. The screenshot below shows a real Okta pipeline after applying this transformation - notice how sign-out events are dropped before reaching Splunk, while everything still flows to S3 for compliance:

Okta to Splunk Pipeline with event filtering + OCSF transformation

The power of Monad's transformation approach is that these operations are:

Composable: Chain multiple operations to build complex transformations
Reusable: Apply the same transformation logic wherever the field structure matches
Visual: No coding required - just configure, drag-and-drop, and deploy
Transparent: See exactly what's happening to your data in real-time
Sandbox-powered: Validate transformations in our sandbox using synthetic data templates before deploying to production

Conclusion

Not all logs are created equal. By dropping low-signal events like Okta sign-outs from real-time pipelines, and pruning noisy fields across other logs, organizations can:

Cut Okta log costs by up to 50% - saving thousands monthly on just one log source
Reduce alert fatigue and analyst load - less noise means better threat detection
Stay compliant without overpaying for storage - full audit trail in S3 at a fraction of the cost
Scale visibility without scaling budget - savings grow linearly with log volume

The Path to Meaningful Savings: This case study demonstrates how optimizing just one log source (Okta) can save thousands monthly. However, since any single log source typically represents only a portion of total SIEM volume, achieving substantial overall cost reduction requires applying similar optimizations across multiple sources - firewall logs, proxy logs, cloud infrastructure logs, and others.

Note: While the savings are significant, it's crucial for security teams to carefully evaluate which events and fields are safe to drop. Removing the wrong telemetry could impact future investigations or detection coverage. Monad can help teams apply these transformations safely with full archiving in S3 to ensure nothing is lost forever.

Better security doesn't start with ingesting all the logs - it's about making smart choices. When you can maintain the same detection capabilities at half the cost, you're freeing up budget for talent and tools that can actually help drive better outcomes.