1.10 Cost Management

How Consumption plan pricing works

Sentinel playbooks built in this course use the Logic App Consumption plan. In the Consumption model, you pay per action execution. Every time a trigger fires, every action that runs, every connector call that executes, and every loop iteration that completes counts as a billable action. There is no fixed monthly charge, no reserved capacity, and no cost when the playbook is idle.

Azure also offers a Logic App Standard plan with fixed monthly pricing and dedicated compute. Standard plan pricing starts around $150 per month for the base workflow service plan. For Sentinel automation, the Standard plan almost never makes sense. Playbook execution volumes are too low and too variable to justify fixed infrastructure. The Consumption plan aligns costs directly with automation activity: if incident volume drops, costs drop with it.

The Consumption pricing has three tiers based on action type. Built-in actions (conditions, loops, variables, Compose, Parse JSON) cost approximately $0.000025 per execution. The first 4,000 built-in actions per month are free. Standard connector actions (the Sentinel connector, Office 365, Azure AD, HTTP) cost approximately $0.000125 per execution. Enterprise connector actions (SAP, IBM MQ, other premium integrations) cost more but are rarely used in security automation.

Logic Apps also bills for storage operations. Every trigger check, every run state update, and every entry in the run history consumes Azure Storage reads and writes. For a typical Sentinel playbook running hundreds of times per day, storage costs add a few cents per month. The storage cost is real but small enough that it rarely matters in cost discussions. Where storage costs can creep up is in playbooks that produce large outputs from Parse JSON or HTTP actions. Logic Apps stores the full input and output of every action in the run history for 180 days by default. Playbooks that retrieve large JSON payloads from external APIs accumulate more storage than playbooks that pass around incident IDs and short strings. If storage costs do appear on the bill, reduce the run history retention period in the Logic App workflow settings.

Estimating costs for a new playbook

Before deploying a playbook, estimate its monthly cost. The calculation requires two numbers: the number of actions per run and the expected number of runs per month.

Count the actions by walking through the Logic App designer. The incident trigger is one action. Each subsequent step is one action. A For Each loop counts as one action per iteration for every action inside the loop. A Condition action counts as one action plus one action for each step in the true or false branch that executes. A Scope counts as one action plus all the actions inside it that execute.

For the enrichment playbook from Section 1.4: the trigger (1 action) + Get Accounts (1) + For Each account (1 per account) containing a KQL query (1 per account) + HTTP to Graph API (1 per account) + Condition (1 per account) + Add Comment (1 per account). For an incident with 2 account entities, that is 1 + 1 + 2*(1+1+1+1) = 10 actions per run. At 50 incidents per day (1,500 per month), that is 15,000 actions per month. At the standard connector rate of $0.000125, the monthly cost is $1.88.

# Estimate monthly Logic App cost for a Sentinel playbook
# Adjust actions-per-run and incidents-per-day for your environment
$actionsPerRun       = 10
$incidentsPerDay     = 50
$daysPerMonth        = 30
$standardConnRate    = 0.000125
$builtInRate         = 0.000025
$freeBuiltInActions  = 4000
# Split: assume 3 built-in (condition, compose, variable) + 7 connector
$builtInPerRun       = 3
$connectorPerRun     = $actionsPerRun - $builtInPerRun
$totalRuns           = $incidentsPerDay * $daysPerMonth
$totalBuiltIn        = ($builtInPerRun * $totalRuns) - $freeBuiltInActions
$totalConnector      = $connectorPerRun * $totalRuns
$builtInCost         = [Math]::Max(0, $totalBuiltIn) * $builtInRate
$connectorCost       = $totalConnector * $standardConnRate
$monthlyCost         = $builtInCost + $connectorCost
Write-Host "Monthly runs:       $totalRuns"
Write-Host "Built-in actions:   $([Math]::Max(0,$totalBuiltIn)) (after 4,000 free)"
Write-Host "Connector actions:  $totalConnector"
Write-Host ("Estimated monthly:  `${0:C2}" -f $monthlyCost)

Monthly runs:       1500
Built-in actions:   500 (after 4,000 free)
Connector actions:  10500
Estimated monthly:  $1.33

The numbers confirm what most teams discover: Logic App execution costs for Sentinel automation are trivially low. A ten-playbook automation stack running at full production volume typically costs $10-15 per month in Logic App actions. The cost is so low that it rarely appears as a meaningful line item in the Azure bill.

Where the real costs hide

Logic App actions are cheap. The services those actions call are not. Every HTTP action that calls an external API consumes that API's quota. Every KQL query that runs against Log Analytics consumes query capacity. Every Graph API call counts against the tenant's throttling limits.

External threat intelligence APIs are the most common cost surprise. VirusTotal Premium costs roughly $900 per month for the standard tier. AbuseIPDB is free for basic lookups but rate-limited to 1,000 checks per day. Shodan costs $59-299 per month depending on the plan. If your enrichment playbook queries VirusTotal for every IP entity in every incident and your environment generates 50 incidents per day with an average of 3 IP entities each, that is 4,500 lookups per month. A playbook that enriches both IPs and file hashes doubles that volume.

Log Analytics query costs also matter at scale. Each KQL query in a playbook consumes data processing capacity. Sentinel's included data allowance covers most query volumes, but playbooks that run complex queries across large time windows at high frequency can generate measurable query charges. A playbook that runs SecurityEvent | where TimeGenerated > ago(90d) for every incident scans orders of magnitude more data than one scoped to ago(1h). The fix is straightforward: scope query time windows to the minimum needed for the enrichment. Most playbook queries need only the last hour of data. Use summarize and project to reduce the data returned to the specific fields the playbook needs rather than pulling full event records.

The cost management lesson: estimate external API consumption before deploying, not after. The Logic App cost is a rounding error. The API cost is the budget item.

Runaway cost scenarios

Two misconfiguration patterns generate unexpected costs. Both involve the playbook executing far more often than intended.

Pattern 1: Trigger filter mismatch. The automation rule is configured to trigger on "any incident" instead of a specific analytics rule or severity level. Every incident in the tenant fires the playbook, including informational incidents, test incidents, and incidents from analytics rules that generate hundreds of alerts per day. The playbook processes 5,000 incidents per month instead of the expected 500. Logic App costs increase ten-fold (still manageable), but external API costs increase ten-fold (potentially catastrophic for paid APIs).

Pattern 2: For Each loop on unbounded entities. The playbook uses a For Each loop over incident entities without a Take action to limit the iteration count. An analytics rule correlates a port scan and produces an incident with 200 IP entities. The For Each loop runs the VirusTotal lookup 200 times for a single incident. One incident consumes a full day's API quota for AbuseIPDB's free tier.

Both patterns are preventable. Scope automation rule triggers to specific analytics rules and severity levels. Add a Take action before For Each loops to cap entity processing at a reasonable limit (10-20 entities per incident). If an incident contains more entities than the cap, the playbook enriches the first batch and adds a comment noting that additional entities were not processed. The analyst reviewing the incident sees the comment, knows enrichment was partial, and can manually investigate the remaining entities if the incident warrants it. This cap protects both API quota and Logic App execution costs without losing visibility.

Setting up Azure Cost Management alerts

Azure Cost Management provides budget alerts that notify you when Logic App spending exceeds a threshold. Create a budget scoped to the resource group containing your Sentinel playbooks. Set the budget amount to 150% of your estimated monthly cost. Configure alert thresholds at 80% (early warning) and 100% (action required). Route the alert to the automation owner's email.

The budget alert catches both gradual cost increases (more incidents over time, more entities per incident) and sudden spikes (a new analytics rule generating unexpected volume). It does not catch external API costs because those are billed separately by the API vendor, not through Azure. For external APIs, set up the vendor's own usage alerts if available, or build a monitoring query that counts outbound HTTP actions per day in AzureDiagnostics and alerts when the count exceeds the expected range. The AzureDiagnostics approach gives you a single pane of glass for both Logic App health monitoring and API consumption tracking.

The monthly cost review

Cost management is not a one-time configuration. It is a recurring review in the monthly automation meeting alongside the operational metrics from Section 1.9.

The monthly review answers three questions. First, did actual Logic App costs match the estimates? Open Azure Cost Management, filter by resource type "Logic App" and the resource group containing your Sentinel playbooks, and compare actual spend against the budget. If costs exceeded the estimate by more than 25%, investigate whether incident volume increased, new playbooks were deployed without cost estimates, or a For Each loop encountered incidents with unusually high entity counts. Export the daily cost breakdown to identify specific dates where spending spiked; those dates correlate with incidents you can find in the Sentinel incident queue.

Second, are external API costs within budget? Review the API vendor dashboards for VirusTotal, AbuseIPDB, Shodan, and any other paid services. Track monthly consumption against the subscription tier limits. If you are consistently using more than 80% of a tier's quota, you are one noisy analytics rule away from overage charges.

Third, does the cost-per-incident justify the automation? Divide total automation cost (Logic Apps + external APIs + analyst time for monitoring and maintenance) by the number of incidents processed. Compare that per-incident cost against the estimated analyst time saved. If automation costs more per incident than manual processing, the playbook is not delivering value and should be re-scoped or retired.