Summary
Security teams never set out to become storage administrators. But somewhere along the path from SIEM to cloud analytics to MDR, that’s exactly what happened. Logs leave your cloud, enter a vendor-owned lake, and suddenly detection becomes a storage problem you can’t see, predict, or control.
This post breaks down why traditional data lake–centric detection pipelines create hidden costs, retention creep, sovereignty exposure-and why modern MDR models like MDR Detect™ eliminate the entire category of “storage tax” by keeping your logs in your cloud.
The real problem: security data has outgrown the architectures built to store it
Data volumes are exploding, but detection value isn’t keeping pace.
Security logging continues to climb across enterprises, yet 84% of organizations now say cloud spend is one of their top challenges.
And the scale of that spend is accelerating fast. In 2025, organizations will spend roughly $723.4 billion on public cloud services – up from $595.7 billion in 2024. But with cloud waste stuck at around 32%, more than $200 billion of that investment is expected to vanish into unused or underutilized resources.
In short: security data is growing faster than security outcomes, and it’s happening inside storage you don’t control.
This is how detection becomes a storage problem – not because teams intend it, but because the architecture forces it.
The hidden tax: data lakes charge you for everything except outcomes
Traditional SIEMs and centralized MDR platforms make one assumption:
Ship everything to our lake, and detection will happen there.
What they don’t advertise is how much you pay for that pipeline, and in how many different ways.
Once logs enter a vendor-controlled lake, the meter starts running on:
- Ingestion (per GB)
- Retention (per day or per month)
- Replication across regions
- Query volume
- Compute cycles
- Analytics engines and rule packs
- Cold storage retrieval
- Egress or extraction when you want out
It’s not one bill.
It’s a cascade of bills.
And when data volume grows, even slightl, each line item grows with it.
Gartner has repeatedly warned about “SIEM cost bloat,” pointing to data ingestion and storage as the primary drivers of escalating SIEM and analytics spend. Their guidance is consistent: organizations must adopt smarter data practices – like tiering, filtering and in-place analytics – because storing everything in a centralized lake is no longer economically viable.
This means most organizations are paying for the gravitational pull of their data lake – not for the security value coming out of it.
Why data lakes keep getting more expensive – even when nothing changes
Here’s the part CISOs and CIOs consistently tell us feels “unfair”:
Cost inflation happens even when security posture hasn’t changed.
Why?
Because:
- Retention quietly extends
- Replication settings evolve
- New log sources appear
- Vendor-side analytics create additional copies
- Cloud platforms auto-tier and auto-index data in ways customers can’t see
AWS, Azure, and GCP all publicly acknowledge this:
More data stored → more metadata → more indexing → more compute.
For businesses, the effect shows up as creeping spend with no linear increase in detection value.
Put simply:
Your lake grows even when you’re not trying to grow it.
More data ≠ better detection (and the numbers back it up)
Security vendors have trained the industry to believe that more logs equals more coverage.
But this is where architecture, not outcomes, has taken control.
Many security teams acknowledge that a significant portion of their log volume contributes little or no detection value – yet still inflates SIEM and data-platform costs.
Industry analysts and seasoned practitioners regularly point out that only a small subset of SIEM rules generate meaningful alerts, while many rules remain noisy, redundant, or rarely triggered in real investigations.
Despite this, most organizations continue to collect and retain nearly all available telemetry by default, paying to store large amounts of low-value data simply because the architecture expects it.
This is the paradox of the modern SOC:
You pay for everything, but only a fraction helps you.
Worse: the noise hides the signal.
More storage → more ingest → more noise → more false positives → more work.
It’s a cycle that helps vendors sell storage, but does nothing for your outcomes.
You lose more than money: you lose control
When logs leave your cloud, four things happen instantly:
- Sovereignty becomes someone else’s problem
With 80% of organizations now worried about data residency and geopolitical risk, losing control over where logs live has become an audit liability. - Governance visibility collapses
You can’t govern what you can’t see across regions, replicas, and retention tiers. - Migration becomes a bureaucratic nightmare
Data lakes create vendor dependency by design.
Extraction is expensive, slow, and often incomplete. - Portability disappears
Your detection strategy becomes tied to their storage strategy.
Detection shouldn’t come at the cost of independence.
The warehouse trap (and how to escape it)
Vendor lakes feel simple at first. Then the data grows. Then the bill grows. Then the complexity grows.
It’s the digital equivalent of the “crate warehouse” scene in Raiders of the Lost Ark:
aisles of boxes, endless rows, no visibility – and someone is paying the power bill.
That’s exactly why so many organizations discover:
- Their SOC is paying for data no analyst touches
- Their retention settings are vendor defaults, not security decisions
- Their MDR provider runs detection in a lake they can’t audit
- Their cloud bill rises even when their security posture doesn’t
- Migrating off the platform would require re-ingesting terabytes of trapped history
This is not security.
It’s storage debt disguised as detection.
A better model: bring detection to the data
Here’s the architectural shift that removes the entire “data lake tax”:
Keep your logs.
Keep your cloud.
Let the MDR operate inside your environment- not outside it.
This is what MDR Detect™ does by default:
- No copying your logs into a vendor-owned lake
- No retention fees you didn’t choose
- No ingest charges tied to vendor storage footprints
- No hidden replication or egress surprises
- No migration headaches if you change vendors
Detection, enrichment, correlation, and automated response all run inside your cloud, under your governance, with your retention rules.
This single change eliminates the entire category of:
- Storage inflation
- Vendor lock-in
- Cloud cost unpredictability
- Multi-region replication surprises
- Compliance ambiguity
You get detection without becoming a storage operator.
Why this matters now (not in 3 years)
Three macro trends make this shift urgent – not optional:
- Cloud waste is rising, not shrinking
Flexera estimates that 27–32% of cloud spend is wasted, representing tens of billions of dollars in annual loss.
- Data sovereignty pressure is accelerating
80% of organizations now modify cloud architecture because of residency and geopolitical risk. - Detection failures increasingly stem from noise, not gaps
As log volume explodes, threat signal gets buried under non-detection data.
Your board is asking why costs keep rising when risk keeps rising too.
This architecture is the reason.
What to do next: move from “their lake” to “your cloud”
You don’t need a full transformation on day one. What matters is starting with visibility.
Here’s how most organizations begin the shift:
1. Inventory where your security logs actually live
Most discover 3–7 unintended copies across vendors, regions, or analytics tools.
2. Align retention with real regulatory requirements
Not vendor defaults. Not arbitrary 400-day settings.
3. Analyze how much of your cloud bill is tied to logging
Even a 10–20% reduction in ingestion yields major savings.
4. Switch to MDR models that operate in your environment
This is the step that restores sovereignty and cost control.
MDR Detect™ is built for this exact transition.
Final word: ask the only question that matters
When your detection pipeline relies on a vendor’s data lake, you have to ask:
Are we paying for detection – or are we paying for storage?
If the answer isn’t clear, the architecture isn’t working for you.
Your logs.
Your cloud.
Your rules.
That’s the future of detection – and MDR Detect™ makes it real.
FAQ
2. Does reducing log ingestion weaken detection quality?
Not necessarily. Many logs provide little or no detection value. Analysts and practitioners consistently observe that only a small subset of telemetry produces meaningful alerts. The key is intentional data management – understanding which logs support real investigations rather than collecting everything by default.
3. Why do organizations end up with multiple copies of the same security data?
Centralized SIEM and MDR pipelines often replicate data across regions, tiers, and analytics engines. Cloud platforms may also create additional metadata or derived indexes. These copies are usually invisible to customers, which makes governance harder and increases storage and compute costs.
4. How does log location affect sovereignty and compliance?
When logs move into a vendor-operated environment, organizations lose direct control over residency, replication, and retention. With rising geopolitical and regulatory pressures, this lack of visibility can introduce audit risk, especially when data crosses borders or is stored longer than required.
5. Why is it difficult and expensive to migrate away from a vendor data lake?
Data lakes are designed to centralize and retain large volumes of telemetry. Extracting that data – especially years of historical logs – requires re-ingestion, re-indexing, and large egress transfers. That makes switching vendors slow, costly, and operationally disruptive.
6. If data lakes are so costly, why do many organizations still rely on them?
Because the industry normalized “send us everything” as the default operating model for SIEM and MDR. Many teams inherited architectures built for a different era, where centralization was the only practical option. Today’s cloud scalability masks the true cost until the bill arrives.
7. What’s the alternative to vendor-centered data lakes for detection?
A shift toward in-place analysis – performing detection, enrichment, and correlation inside the organization’s own cloud environment. This approach reduces data movement, simplifies governance, and avoids paying for storage and replication the organization doesn’t control.
