I was working with a client recently to optimise their Sentinel deployment when I found out that their Sentinel Pricing tier had been changed from thier original commitment tier to a higher (and an incorrect) pricing tier. A tier that was not suitable for their daily ingestion volume and was adding extra thousands of dollars to their monthly bill!
There was no change record, so this was definitely an unapproved change. After some digging, I discovered the root cause was a misconfiguration in their Infrastructure-as-Code (IaC) pipeline that had silently changed the pricing tier of their Microsoft Sentinel workspace. This was resulting in thousands of dollars of extra cost per month per workspace.
This kind of issue is more common than you’d think, especially in environments where multiple teams push changes via automated pipelines. So I built a quick KQL query to help identify who changed the pricing tier, when it happened, and what it was changed to.
The Query
AzureActivity
| where _ResourceId contains "/microsoft.OperationalInsights/workspaces/"
| where OperationNameValue == "MICROSOFT.OPERATIONALINSIGHTS/WORKSPACES/WRITE"
| where ActivityStatusValue == "Start"
| extend requestBody = parse_json(tostring(parse_json(Properties).requestbody))
| extend skuInfo = requestBody.properties.sku
| extend SKU = tostring(skuInfo.name)
| extend Commitment_Tier = tostring(skuInfo.capacityReservationLevel)
| where isnotempty(skuInfo)
| project TimeGenerated, SKU, Commitment_Tier, Actioned_By = Caller
Why This Matters
If you accidently change the pricing tier of your workspace to one that is higher than your current tier, you can not revert the change for at least 30 days, which means you are bound to pay the extra cost for at least a month and in most cases it can be thousands of dollars of extra money paid.
In my client’s case, the change was made by a service principal used in a CI/CD pipeline. The IaC template had a default SKU that was higher than needed, and every deployment was silently enforcing it. It not only changed the prod workspace but also the dev workspace which did not have any regular data ingestion. This query helped pinpoint the exact moment the change occurred and who (or what) made it, this can also be used as a detection rule to alert relevant teams if a change of this nature is made in future.
If you’re using IaC, always validate your templates against cost impact,add code reviews and ensure PR approvals are carefully done.