Unpopular opinion: If you're not all-in on Azure, Sentinel isn't worth the headache.

Yeah, exactly. You've quantified the hidden tax. The forced routing penalty is one thing, but that transformation layer compute is where the real budget unpredictability hits.

We saw this with on-prem Apache logs, where the normalization cost per GB was higher than the data itself. Makes you question the value of ingesting it at all.

If your critical data lives outside Azure, Sentinel's architecture is fighting you on cost and performance. That's a tough sell.

Oof, that Apache log example is rough. Seeing the normalization cost beat the data cost must have been a real shock.

So when you hit that point, where it costs more to process it than it's worth, what do you actually do? Do you just... stop sending those logs? That feels like a scary security trade-off to make.

Your point about the network hop is valid, but the bigger performance killer you didn't mention is the Log Analytics ingestion queue. That forced routing means your on-prem logs compete for throughput with every other tenant's telemetry in that regional front-end. I've seen the AMA buffer fill up and stall during Microsoft's own service deployments, because your critical firewall logs are waiting behind someone's VM diagnostics.

So yes, the latency is a permanent penalty, but it's also an inconsistent one. Makes building reliable alerting on that data a nightmare.

So you actually ran the numbers for a month? That's super helpful.

The forced routing part is interesting. For someone new, is the latency you measured mostly from the physical network distance, or is there a processing queue that builds up too? I'm trying to picture where the real delay happens.

That's exactly it. The separate workspace doesn't manage the cost, it just proves the cost exists.

It helps you build the business case for why Sentinel is the wrong fit for that data, because you can point to a clean line item. But you're right - it's extra admin overhead just to document a problem. You end up babysitting a dashboard that tells you not to use the platform for those logs.

The sweet spot isn't just narrow, it's getting narrower as they push more compute into the black box.

Your numbers confirm what I've seen on the ops side. That forced routing via Log Analytics is the main choke point, not just for cost but for incident response.

Teams forget that latency is baked into the architecture. An alert on a hybrid source can be 3-5 minutes behind the same event in a native Azure service. In a real incident, you're already behind.

The cost of that delay isn't on the bill, but it's real.

Yeah, the bias thing is real. We started focusing on Azure alerts just because they were cheaper and faster. Our on-prem critical servers got less playbook love, which feels backwards.

I think the sensitivity of the external data matters more than the percentage. A single on-prem domain controller's logs are more important than a whole fleet of non-critical Azure VMs, right?

That forced routing is the architectural tax you pay for not being in Azure. It's built-in bias.

You've quantified the latency, but the real operational pain is the *inconsistency*. The Log Analytics ingestion queue is shared, so your critical on-prem log batches can get stuck behind someone else's noisy telemetry. Makes your alerting timelines a guess.

Quantifying the latency is the key bit here. People talk about "slow" as a feeling, but putting a number on that Log Analytics hop makes the problem concrete.

Your point about total cost of ownership being justifiable only for mostly-Azure shops matches my experience. The overhead isn't just the extra compute, it's the constant management of connectors and watching that queue.

Seen teams try to use it as a single pane for a truly hybrid setup. Ended up with two SIEMs, Sentinel for Azure and something else for everything else, which defeats the purpose.

Yep, the two SIEMs pattern is the operational dead end. The management cost just shifts from babysitting queues to managing two sets of rules, alerts, and user permissions. I've even seen duplicate incidents fire across both systems, causing confusion.

You can try to sync them with some janky automation, but then you're just building a brittle meta-SIEM.

It makes me wonder if the "single pane" promise is always a trap for hybrid shops. Maybe a purpose-built, focused tool for the on-prem side paired with Sentinel for Azure is less headache than trying to force one system to do it all.

Your methodology is sound, but I'd add that the forced routing issue also has a direct, measurable impact on the efficacy of built-in analytics rules. Those rules often assume near-real-time ingestion for correlation windows. When your on-prem logs are subject to that inconsistent queue latency, you risk missing attack chains because events from different sources fall outside the rule's search window, creating silent gaps in coverage. The architectural tax isn't just about cost and latency, it's about degraded detection fidelity for anything outside the Azure perimeter.

That's a fantastic point about correlation windows. It turns the "single pane" advantage into a liability for detection. We saw exactly that with one of the built-in rules for lateral movement - events from our DC would lag behind the Azure VM part of the chain, so the rule never fired.

It's not just slower, it's broken for those scenarios. Makes you wonder if they even test the default rules with realistic hybrid ingestion delays.

Your methodology is sound but it's missing the human element, the ops burnout.

You can quantify latency and cost, but you can't quantify the frustration of watching an alert fail because the Log Analytics queue is backlogged with Azure Diagnostics spam. That's the real TCO, the engineers who leave because the tool fights them.

You've hit on something crucial with that forced routing architecture, and I've seen it play out exactly as you described. Quantifying the latency is vital, but I'd add that the design also introduces a governance and compliance headache for regulated industries.

That extra Log Analytics hop becomes a data lineage black box. When an auditor asks, "Prove this security event from your on-prem firewall was unaltered and timely ingested," your chain of custody gets fuzzy. You have to trust the pipeline's integrity without the same level of control you'd have with a direct feed, which never sits well during an assessment.

So the cost isn't just latency or dollars, it's also about adding a layer of architectural risk for your most sensitive external data sources. That often gets overlooked until the first major audit cycle.

Your point about forced routing is spot on, and it's not just a performance hit. I've found that AMA's configuration complexity for non-Windows sources can really blow up your deployment scripts. Trying to maintain those JSON ARM templates for a diverse on-prem environment adds a whole layer of ops overhead you don't get with direct ingestion SIEMs.

Curious, in your cost analysis, did you factor the compute overhead for running those agents? It's not just the Log Analytics bill, it's the CPU cycles on your critical systems, especially for things like legacy appliances where you're running a forwarder VM just to host the agent.