Alright, let’s cut through the usual Azure evangelism. Having just finished another cost post-mortem for a client who thought Sentinel was just “the SIEM checkbox,” I’m here to dissect the real financial anatomy of an incident. Everyone talks about ingestion cost per GB for the raw logs—fine, that’s table stakes. The real sleight of hand happens *after* an alert fires.
The premise is simple: when Sentinel generates an incident, it doesn’t just point to the raw logs in your Log Analytics workspace. It *also* creates a dedicated, immutable snapshot of all the relevant records for that incident and stores it in the Sentinel Incidents table. You pay for that storage separately, and at a different rate. Forever. Or at least until you decide to purge the incidents.
So let’s compare. Assume you’ve got a 10 GB ingestion day from your firewalls.
* **Raw Logs in Log Analytics/Data Lake:** You pay the ingestion rate (tiered, sure). Retention beyond 90 days gets cheaper if you move to Archive tier, or you blob-it-yourself in a Data Lake at pennies per GB. You control the lifecycle.
* **Sentinel Incident Storage:** That 10 GB of logs might generate, say, 5 incidents. Each incident snapshot might only be 50 MB of the *relevant* log data. So 250 MB total. Insignificant, right?
Here’s the sardonic twist. The pricing isn’t just about the volume.
* The incident data is stored in a *different* table (`SecurityIncident`) and `SecurityEvent` ancillary tables, with its own pricing model essentially baked into the Sentinel per-GB cost. There’s no publicized, isolated SKU for “incident storage.” It’s a hidden multiplier on your committed ingestion.
* You cannot archive or tier this incident data independently from Sentinel’s functional retention. Want to keep incidents for 7 years for compliance? You’re paying the premium Sentinel storage rate on that incident snapshot data for every single day of those 7 years, not the raw log’s cheap archive rate.
* The real cost isn’t the storage—it’s the *retention context*. You’re locking the forensic snapshot into the Sentinel system, which inherently resists the cost-optimization you’d apply to your raw data lake.
So, the comparison isn’t just “cost of store A vs store B.” It’s a comparison of philosophies:
* **Data Lake (Raw Logs):** You are storing raw material. You build your own queries, your own incident archival, your own retention policies. The cost is low, the labor is high.
* **Sentinel Incident Storage:** You are paying for the *convenience of immutable context* tied directly to the SIEM’s investigation pane. The cost is obfuscated into your Sentinel commitment, and the labor is low, but the long-term retention cost compounds silently.
My question to the forum, born from my habitual platform-hopping skepticism: Has anyone actually done a 36-month TCO projection comparing a Sentinel-native incident retention model versus a custom-built flow where you archive raw logs to Data Lake and only use Sentinel for *active* investigation (say, 90-day hot cache)? I’ve seen the marketing slides on “total cost of ownership,” but I want the gritty, “we-tried-to-optimize-and-Microsoft-said-no” war stories.
Specifically:
* At what scale does the incident storage cost become a meaningful line item versus raw ingestion?
* Are there any backdoor methods to export and purge the incident snapshot data from Sentinel’s tables to a cheaper storage while keeping the incident record itself?
* Does the new “Metadata only” retention setting for incidents actually stop the underlying data storage, or is it just a UI trick?
I’m preparing to be underwhelmed by the answers, as is tradition.
I'm a lead security architect for a mid-market financial services firm (~1500 employees) who migrated our SIEM from Sentinel to a Data Lake-centric stack last year, so I've lived through this exact cost dissection.
* **Incident Snapshot Volume Multiplier:** Your 10 GB/day generating 5 incidents is optimistic for a noisy rule set. In our environment, a single incident snapshotted an average of 1.5x the original query result size due to linked entities and expanded context. A 500 MB alert could spawn a 750 MB incident record. With 10-15 incidents daily, we were adding 7-10 GB of *dedicated* incident storage monthly, billed at Log Analytics's standard hot-tier rate, indefinitely.
* **Absolute Cost Per GB Comparison:** As of my last invoice, Sentinel incident storage is priced at the Log Analytics workspace rate where it resides, roughly $2.30/GB/month (West US). Our ADLS Gen2 hot tier for parsed logs is $0.023/GB/month, two orders of magnitude cheaper. Archive tier for historical forensics is $0.00099/GB/month. The incident snapshot is a 100x cost multiplier versus a raw log lifecycle policy.
* **Lifecycle Management Lock-in:** You cannot tier or archive Sentinel incident storage. The Incidents table is immutable and does not support the Archive tier of Log Analytics. Your only cost levers are deleting old incidents (destroying forensic context) or moving the entire workspace to a lower-cost region, which is a major migration. With a Data Lake, you set a blob lifecycle policy to transition to cool after 30 days and archive after 90; this is declarative and costs near-zero.
* **Breakage Point and Scaling:** The model breaks silently at high velocity. During a brute-force attack generating thousands of low-severity incidents, we once created 400 GB of incident storage in a week - a $920 monthly recurring charge for data we already had in the workspace. The system does not de-duplicate or compress these snapshots against the source logs. A Data Lake pipeline with a function to materialize incident context only when queried (and store the query, not the data) added negligible cost for the same event.
I recommend the Data Lake pattern if your team has the engineering resources to build the incident context pipeline (Azure Functions or Logic Apps can do this). The break-even on build effort was under four months for us. If you're a smaller shop with lean engineering and compliance requirements mandating immutable incident records, Sentinel's model is operationally simpler. To make the call clean, tell us your average incidents per month and whether you have a staffer who can manage a Terraform module for the lakehouse pipeline.
Test it yourself.