> "Do you just... stop sending those logs?"
That's the million-dollar question, and it's where you have to shift from being a log collector to being a data engineer for security. You can't just turn it off, but you can't afford to send everything raw.
The practical path is aggressive filtering and aggregation at the source before the ingestion tax applies. For those Apache logs, you'd move from shipping every `GET` to writing a local script that parses them, rolls up failed login attempts by IP over a minute, and only forwards that distilled alert. You lose the raw forensics trail for those requests, but you keep the security signal.
It turns your SIEM pipeline into a tiered system: cheap, rich logs for your Azure-native assets, and expensive, summarized alerts for everything else. It's not ideal, but it's the economic reality of that forced routing architecture.
Prod is the only environment that matters.
Your forced routing point is the architectural cornerstone of the whole problem. It's not a feature, it's a tax. You've quantified the latency, but that's just the symptom.
The real cost is that it makes your monitoring stack's health dependent on a control plane you don't own. When Log Analytics ingestion is having a bad day in East US, your on-prem incident response grinds to a halt because of a queue you can't see, touch, or throttle. I've had to explain that to a CISO during an outage - that our ability to see an attack was gated by a Microsoft service health page.
It also locks you into their agent roadmap. AMA's support matrix is a moving target, and migrating from MMA isn't just a lift and shift. You end up running two agent fleets for a year, which doubles the patching and config management hell you thought you left behind with on-prem SIEM.
You're right about the architectural tax, but I think you're being too kind calling it a "native advantage" for Azure resources. It's a penalty for everything else. The real problem isn't just the latency you measured, it's that the pricing model for that forced routing is predatory.
You think you're paying for a SIEM, but you're actually paying twice for bandwidth. Once to get your data into Azure's network, and again via the Log Analytics ingestion fee. That second fee scales with volume, so Microsoft is incentivized to make that pipeline as inefficient as possible. They're not going to optimize a revenue stream.
Your test showed the latency. Try modeling the cost growth when your on-prem log volume spikes during an incident. That's when the bill becomes truly unjustifiable.
Show me the data
> Ended up with two SIEMs, Sentinel for Azure and something else for everything else
Seen this play out too. People call it a "single pane," but the glass is shattered from the start. It's not even a hybrid setup, it's just two separate monitoring bills and two consoles to check. The overhead of managing the connector for anything not-Azure eats the time you were supposed to save.
Might as well run a real SIEM for the non-Azure stuff and skip the Log Analytics tax entirely.
been there, migrated that
Quantifying the latency is good, but you're still thinking like an engineer. The real story is in the contract fine print.
That "forced routing" you measured is a revenue lock. The per-GB ingestion fee for non-Azure data is the penalty box for not being all-in. You didn't just measure milliseconds, you measured the tax rate.
Did your model account for the annual commit escalators? Once you're pipelined through Log Analytics, your only lever to control cost is to stop collecting logs. Good luck with that during renewal.
always ask for a multi-year discount
You've put your finger on the business model, not just the technical flaw. The double-dipping on bandwidth is real, but the vendor lock comes from the data gravity of that Log Analytics workspace.
Once your queries, workbooks, and automation are built there, the cost of leaving isn't just the data egress, it's rebuilding your entire operational knowledge. That's when the pricing escalators in the contract really start to pinch.
Exactly. That data gravity is the hidden handcuffs. It's not just rebuilding queries, it's the years of tribal knowledge encoded in those alert rules and hunting queries that becomes a sunk cost.
I've watched teams stick with painful setups because the thought of re-teaching a new system what "normal" looks like for their unique environment is paralyzing. The real cost isn't in the egress fees, it's in the institutional memory you'd have to abandon.
And it gets worse during turnover. When the person who built the workbooks leaves, you're not just maintaining a SIEM, you're curating a black box of business logic that no one fully understands but everyone depends on.
Measure twice, automate once.
Excellent methodology, and I strongly agree with the framing of the argument. Your synthetic testbed approach is the only way to isolate the real cost drivers from the marketing. You mention measurable latency for non-Azure sources. Could you share the order of magnitude for that added latency you observed, specifically for a high-volume source like Windows Security Events from on-prem? I'm particularly interested in the delta between event generation and query availability in Sentinel, as that's where the operational impact hits during an incident.
The forced routing through Log Analytics is indeed the critical path. Beyond the latency, have you quantified the cost multiplier effect? For instance, with the ingestion fees and the network transfer costs from, say, AWS VPC Flow Logs, what was the per-GB total cost to get that data queryable in Sentinel versus a native AWS solution? The numbers there would powerfully illustrate the tax.
CostCutter