Skip to content
Logmetry

Govern what enters the workspace

Microsoft Sentinel is the cloud-native SIEM built on a Log Analytics workspace: the Azure Monitor Agent and data connectors feed it through data collection rules, and detections are analytics rules written in KQL over the ASIM normalized schema. It is billed per GB as data enters the workspace, at pay-as-you-go rates or commitment tiers that reserve daily volume at a discount. We tier data before it reaches Log Analytics, normalize to ASIM upstream, and keep the full-fidelity history in a Lake beside it.

How a Microsoft Sentinel estate looks today

A Sentinel estate is billed per GB as data enters Log Analytics, verbose operational data at the same rate as security signal, with parsing pushed into every analytic rule.

How a Microsoft Sentinel estate looks todayAzure Monitor agents on every host and Microsoft cloud signals feed data connectors, each source in its own shape, into the Log Analytics workspace, where every GB is billed as it enters the Analytics tier. KQL detections read the workspace. Verbose operational data pays the same rate as security events, and what would cost too much is excluded or dropped to control the bill.YOUR ESTATEServers, VMs, containersAZURE MONITOR AGENTSAn agent per host, plus connectorsDefender, Entra, Microsoft 365Most of itEXCLUDED, OR DROPPEDTO CONTROL THE BILLAll of itDATA CONNECTORSEach source in its ownshape, no shared schemaPER GB INGESTEDMICROSOFT SENTINELBilled as data enters the workspaceTHE WORKSPACELog Analytics, per GBDETECTIONSKQL rules and incidents,Defender correlatedWHAT YOU PAY FOREvery GB entering theAnalytics tier is billed.Verbose operational datasits beside security events,at the same rate.Commitment tiers price thewhole flow, not the signal.Every analytic rule carriesits own parsing per source.
How a Sentinel estate looks today. Every GB is billed as it enters Log Analytics, security signal and verbose operational data at the same rate, and inconsistent source schemas push parsing into every analytic rule.

What Microsoft Sentinel does best

Sentinel is the cloud-native consolidation play that actually works: KQL is a serious analytics language, the Defender integration means endpoint, identity, and email signals arrive already correlated, and for Microsoft-heavy estates the operational fit is hard to argue with. Commitment tiers reward predictable volume with real discounts.

The friction is what reaches Log Analytics and in what shape. Sentinel expects data in a consistent schema, and inconsistent field names across firewalls, identity providers, and endpoints mean every analytic rule carries its own parsing logic. Billed volume climbs when verbose operational data lands in the Analytics tier alongside the security events that belong there.

What we do to a Microsoft Sentinel estate

Keep it and govern what flows in, shrink its footprint, cut what it costs, extend it with an agent, and replace only where replacement is honest.

The Logmetry Blueprint applied to a Microsoft Sentinel estateThe same estate now feeds a control layer you own, which normalizes to ASIM upstream and tiers data by value. Everything lands at full fidelity in a lake in your own storage, and only what earns the Analytics tier crosses into a right-sized workspace. Detections are unchanged. An agent you own works each Sentinel incident, following entities into the full history beside the workspace. Pins mark the five verbs: replace on the control layer, cut on the meter, shrink on the workspace, keep on the detections, extend on the agent.YOUR ESTATEServers, VMs, containersAZURE MONITOR AGENTSKept, pointed at the layerDefender, Entra, Microsoft 365All of itYOUR GROUNDTHE CONTROL LAYERNormalized to ASIM,tiered by valueAs code, in your reposREverything, full fidelityTHE LAKE, YOURSPER GB INGESTEDOnly what earns the tierCMICROSOFT SENTINELKept, right-sized, unchangedTHE WORKSPACESDETECTIONSUnchanged, on ASIM fieldsKThe incidentYOUR AGENTFollows entities into historythe workspace never heldEIt queries your historyWHAT CHANGEDBilled volume drops whiledetections keep their inputs.Sources arrive in ASIM shape,so the rules stay simple.The commitment tier getsright-sized to real signal.
The Logmetry Blueprint applied. Azure-native sources stream out through Event Hubs and hosts through the collector, all of it into a control layer that drops, aggregates, and normalizes to ASIM before anything lands back in the workspace. Full-fidelity history lands in a Lake beside it, and the Analytics tier bills only what earns it. The pins mark where each of the five verbs acts.
KKeep

The workspace, the analytics rules, and the Defender integration. Sentinel stays your SIEM, your team keeps working in it, and every KQL detection keeps firing on the same inputs it fires on today.

SShrink

Verbose operational data tiers to lower-cost paths before it reaches Log Analytics, while high-value security events keep the Analytics tier.

CCut

Billed volume drops while detections keep their inputs, and the commitment tier gets right-sized against what actually flows into the workspace rather than against what the estate happens to produce.

EExtend

An agent you own works Sentinel incidents, following entities into full-fidelity history the workspace never held.

RReplace

Never. The control layer sits in front of Sentinel, and the Lake beside it, so the workspace does what it is best at on the data that earns its tier.

The letters mark where each verb acts in the drawing above

ASIM upstream, the Lake beside

Normalizing to the ASIM schema upstream means firewall, identity, and endpoint events arrive in consistent fields, which keeps analytic rules simple across a large estate.

Migrations onto Sentinel stall when detections, parsers, and data sources are rebuilt by hand against an unfamiliar schema. We run the old SIEM and Sentinel in parallel against the same routed feed, so detections are validated firing in Sentinel before anything is retired. Yale New Haven Health moved 30,000+ endpoints onto Microsoft Sentinel in two weeks on exactly this pattern.

Full-fidelity copies land in object storage you own, so cheaper Sentinel tiers never mean losing access to raw history, and the next platform decision, whenever it comes, is a routing change.

Asked about Microsoft Sentinel estates

How do you control Sentinel ingestion cost without losing detections?

Tier data before it reaches Log Analytics. High-value security events go to the Analytics tier, verbose operational data to lower-cost paths, and full-fidelity copies to storage you own. The billed volume drops while every detection keeps its inputs.

Can you migrate us from Splunk to Sentinel?

Yes, as a parallel run rather than a leap. Both platforms receive the same routed feed while detections are rebuilt and validated in Sentinel, and the cutover is a routing percentage rather than a weekend. The dual-license window collapses from quarters to days.

Does the Lake compete with Sentinel?

No. The Lake holds what the workspace should not have to: full-fidelity history at object-storage cost, replayable into Sentinel on demand. The workspace does detection on the data that earns its tier. Each does the job it is priced for.

Start with the review

You share your diagrams, we review them with you, and you leave with your version of the Logmetry Blueprint drawn on your Microsoft Sentinel estate. No system access, no obligation.