Microsoft Sentinel SIEM: What We've Learned Deploying It in Production
Microsoft renamed "Azure Sentinel" to "Microsoft Sentinel" in November 2021. The product kept the branding long after the name changed, so most teams searching for it still reach for the old name. That confusion is minor compared to the architectural decisions that actually determine whether a Sentinel deployment works at scale.
We have stood this up across financial services, ISV, and government tenants. The patterns that cause pain are almost always the same: workspace topology chosen too early, ingestion costs underestimated by a factor of three, and analytics rules cloned from community repos and left untuned. This note covers what we now do differently.
Why Sentinel Exists and Where It Fits
Sentinel is a cloud-native SIEM and SOAR built on top of Log Analytics workspaces. That lineage matters. Log Analytics is the query and storage engine; Sentinel adds the detection layer, incident management, playbook orchestration via Logic Apps, and UEBA. If you already send data to Log Analytics for observability, you are already paying for some of this.
The gap it fills is real. Traditional on-prem SIEMs like Splunk or QRadar require you to own the infrastructure, manage indexers, and negotiate per-GB pricing with a vendor on annual cycles. Sentinel charges on ingestion volume directly, and the math changes depending on how much you actually send. Under roughly 100 GB/day the pay-as-you-go rate looks attractive. Above that, commitment tiers drop the per-GB rate substantially. The threshold where Sentinel becomes expensive relative to alternatives is around 300-500 GB/day for a single tenant, though that number moves based on the region and how aggressively you filter before ingest.
Workspace Topology: The Decision You Cannot Easily Undo
A single workspace per tenant is the right default for most organizations. Multi-workspace deployments exist for regulatory isolation requirements, not performance. We have seen teams split workspaces by environment (dev/prod) or by business unit, then spend months wiring up cross-workspace queries that should not need to exist.
The concrete tradeoff: cross-workspace KQL queries using workspace() references work, but they increase query cost and add latency. Analytics rules that span workspaces require managed identity and additional permissions plumbing. The Fusion ML detection engine, which correlates low-fidelity signals into high-confidence incidents, does not cross workspace boundaries.
If your organization has a hard regulatory requirement separating certain log types, use table-level RBAC inside a single workspace before you reach for workspace separation. Most audit requirements can be satisfied by restricting read access to specific tables rather than routing data to a separate workspace.
Data Connectors That Actually Matter
Sentinel has over 200 data connectors. The ones worth your attention in a typical Azure-centric environment:
- Microsoft Defender XDR connector pulls endpoint, identity, cloud app, and email signals into a unified incident experience. This is high-signal data and almost always worth ingesting.
- Azure Activity logs are cheap and necessary. Every ARM-level change lands here.
- Microsoft Entra ID sign-in and audit logs are required for any identity-centric detection. Enable the diagnostic settings at the Entra tenant level, not just per-subscription.
- Azure Firewall and NSG flow logs are the highest-volume sources in most environments. Filter aggressively before ingest using a DCR (Data Collection Rule) transformation. Drop allowed traffic from known-good RFC1918 ranges before the data hits the workspace.
Syslog and CEF from on-prem sources still works, but it routes through a Linux forwarder VM. Size that VM correctly: we have seen a Standard_B2s forwarder fall over at 5,000 events per second, which is not a lot for a mid-size firewall.
KQL Detection Engineering in Practice
KQL is the query language. It reads like a pipeline and is genuinely good once you are past the first week. The community library at Azure/Azure-Sentinel on GitHub has over 600 detection templates. Do not enable them wholesale.
Each analytics rule runs on a schedule and generates a query charge against your workspace. Fifty rules running every 5 minutes on a large workspace adds up. More importantly, untuned community rules generate alert volumes that collapse an analyst queue within a week.
The pattern we follow: take a community rule, run it manually as a Log Analytics query against 30 days of historical data, count the results, then decide whether to enable it as-is, tune it, or park it.
A concrete example. The community rule for impossible travel sign-ins is valuable but fires on VPN exits and known proxy services. Here is a stripped-down version of what we tune it to before enabling:
let known_vpn_ranges = dynamic(["198.51.100.0/24", "203.0.113.0/24"]);
let travel_threshold_km = 500;
let time_window = 1h;
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where not(ipv4_is_in_range(IPAddress, known_vpn_ranges))
| where UserType != "Guest"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, LocationDetails
| sort by UserPrincipalName asc, TimeGenerated asc
| extend prev_time = prev(TimeGenerated), prev_location = prev(Location), prev_user = prev(UserPrincipalName)
| where UserPrincipalName == prev_user
| extend elapsed_hours = datetime_diff('minute', TimeGenerated, prev_time) / 60.0
| where elapsed_hours < time_window / 1h and Location != prev_location
| project UserPrincipalName, IPAddress, Location, prev_location, elapsed_hours, TimeGenerated
This is not production-ready as-is. The geographic distance check requires enrichment via a watchlist or a custom function that maps country codes to coordinates. We maintain a Sentinel watchlist of known safe locations per user identity for high-value accounts. The point is to show the shape of a tuned rule: explicit allowlists, scoped to signed-in success events, filtered by user type.
SOAR Playbooks: Logic Apps Are Serviceable, Not Great
Sentinel's automation is Logic Apps under the hood. For simple response actions, a Logic App works fine: isolate an endpoint via Defender API, post an adaptive card to a Teams channel, open a ServiceNow ticket. We have shipped all of these.
The ceiling is low for complex orchestration. Logic Apps have limited loop control, weak error handling at the action level, and per-action pricing that can surprise you on high-volume incident queues. For anything beyond three or four API calls in sequence, we usually wire the Logic App to an Azure Function or a Durable Function chain and keep the Logic App thin.
The trigger latency from incident creation to playbook fire is typically 30-120 seconds. For automated containment this is acceptable. For real-time blocking decisions it is not, and you should be looking at Defender policies rather than Sentinel playbooks for sub-second response.
Ingestion Cost Control: The Decisions That Determine Your Bill
Three levers matter most.
First, DCR transformations. Data Collection Rules now support KQL-based filtering at ingest time. Data dropped here costs nothing. A well-written DCR on NSG flow logs can cut ingestion 60-80% without losing any detection value, because allowed outbound traffic to known CDN ranges is genuinely not interesting.
Second, the Basic Logs tier. Tables you query rarely but need to retain for compliance can be set to Basic Logs at roughly $0.50/GB versus the standard ~$2.30/GB. The tradeoff is that Basic Logs cannot be used in scheduled analytics rules, only in Search Jobs and manual queries.
Third, archive. Sentinel's data retention defaults to 90 days in the hot tier. After that, data moves to archive at around $0.02/GB/month. For compliance-driven retention out to 7 years this is the only path that does not bankrupt the security budget.
The workspace daily cap exists as a cost control but is dangerous to set too low. A workspace that hits its daily cap stops ingesting. You will miss events, and you will not know it until you look. We do not set the daily cap below 120% of the 30-day p95 ingestion volume, and we alert on any day that breaches 90%.
When to Call Us
If you are sizing a Sentinel deployment, redesigning a workspace that has grown too expensive, or need detection engineering work to ship real KQL rules against your environment, the right entry point is our detection engineering practice. For a conversation about where this fits in a broader cloud security architecture, reach out at /contact.