AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
Microsoft Sentinel works particularly well with Microsoft 365, Defender, Entra ID, and Azure.
Native integrations bring security evidence together, while free data sources and Microsoft licensing benefits can reduce the cost of monitoring that environment.
Microsoft Sentinel has separate charges for analytics and data lake use. Supporting Azure services can add further costs, so ingestion volume alone does not explain the invoice.
The main meters are:
Data entering analytics tables, charged through pay-as-you-go or a daily commitment. Simplified pricing combines Log Analytics ingestion and Microsoft Sentinel analysis; older classic arrangements can show them separately.
Keeping data in analytics beyond its included period. Check table settings and eligibility before assuming all records have 90 days included.
Separate per-GB charges for data ingested into lake-only tables. Mirroring analytics data into the lake does not add these two charges.
Retained data outside the analytics window, including lake-only records. Microsoft applies a uniform 6:1 compression assumption for this storage meter.
Uncompressed data scanned by applicable KQL queries and jobs. The storage compression assumption does not reduce the volume billed for a scan.
Applicable compute for notebooks, jobs, and custom graph builds, based on resources and running time.
A record can incur different charges as it moves from collection to retention and later analysis. Review those stages separately.
Use Cost Management to group charges by resource, service, and meter. Include Microsoft Sentinel, Azure Monitor, and Log Analytics where applicable, then identify collectors, Logic Apps, storage, exports, and other supporting resources.
Moving evidence into another store can reduce one meter while adding export, storage, retrieval, and operational costs. It also does not refund analytics ingestion that has already happened.
Onboarding to the data lake changes applicable legacy archive, search, and Auxiliary billing arrangements. Basic Logs still need their own assessment. Do not assume every Azure Monitor table plan becomes interchangeable.
The reference prices below are for East US in USD, checked on November 3, 2026. Actual rates depend on region, currency, agreement, and current offers. The percentage column compares each listed rate with pay-as-you-go analytics ingestion; the billing units and time periods still differ.
Lake ingestion and processing together are $0.15 per GB at these rates, about 3.5% of pay-as-you-go analytics ingestion. Storage, queries, and compute remain additional costs. That comparison does not establish a 96.5% reduction in the total cost of a table.
Use the Microsoft Sentinel cost estimator or Azure pricing calculator for an initial forecast, then replace assumptions with measured volumes and your effective billing rates. Include ongoing historical searches and supporting resources.
Free sources, capped allowances, and included retention reduce different parts of the bill. Confirm which benefits apply before changing collection.
For 2,000 eligible Microsoft 365 seats, the 5 MB allowance provides up to 10 GB per day for qualifying data. It is not a general credit against firewall logs or every SaaS source.
Free Defender alerts also do not make their underlying endpoint, identity, and email event tables free to ingest. Native Defender advanced hunting history and records ingested into a Microsoft Sentinel workspace are different storage arrangements.
Review benefit allocations in Cost Management exports. Microsoft 365 benefit meters can include Free Benefit - M365 Defender Data Ingestion and Free Benefit - M365 Defender Analysis, depending on the arrangement.
Free Benefit - M365 Defender Data Ingestion
Free Benefit - M365 Defender Analysis
For Defender for Servers Plan 2, verify enablement on the receiving Log Analytics workspace and the eligible collection path. Supported security events qualify; not every Windows channel does. Under simplified pricing, the allowance applies to Microsoft Sentinel ingestion. Classic pricing has different treatment.
Use normal operating periods for forecasts. A trial month or a month with incomplete deployment can understate the ongoing bill.
Start with the largest tables, then identify the devices, event categories, and fields producing the volume. Record each table’s purpose, owner, tier, retention, and current dependencies.
This query lists the fifteen largest billable tables over the last thirty days. Usage.Quantity is in megabytes, so dividing by 1,000 gives decimal gigabytes.
Usage.Quantity
Usage | where TimeGenerated > ago(30d) | where IsBillable == true | summarize BillableGB = round(sum(Quantity) / 1000, 2) by DataType | sort by BillableGB desc | take 15
Use this to prioritize the review. Multiplying every result by the pay-as-you-go rate will not reproduce an invoice that includes commitments, benefits, different table plans, and retention.
For billing comparisons, use complete UTC days and reconcile the result with the cost export. A rolling thirty-day query can include partial days.
For CEF data, examine the products and actions contributing to CommonSecurityLog. _BilledSize is measured in bytes.
CommonSecurityLog
_BilledSize
CommonSecurityLog | where TimeGenerated > ago(7d) | summarize Events = count(), BilledGB = round(sum(_BilledSize) / 1e9, 2) by DeviceVendor, DeviceProduct, DeviceAction | sort by BilledGB desc
Once a large category is identified, drill into the appliance or source identifier. Compare record counts with average record size. A sudden increase may come from more activity, duplicate delivery, or a configuration change that enlarged each message.
For Windows security data, review the largest event categories:
SecurityEvent | where TimeGenerated > ago(7d) | summarize Events = count(), BilledGB = round(sum(_BilledSize) / 1e9, 2) by EventID, Activity | sort by BilledGB desc | take 20
High volume is a reason to investigate the source, not sufficient reason to remove it. Establish which detections, hunts, and incident questions depend on those events.
Check duplicate collection routes as well. Overlapping collectors, diagnostic settings, and DCR assignments can send equivalent records more than once. Compare source identifiers, event timestamps, and collection paths before removing a route.
For bulky records, inspect individual fields. Repeated text in AdditionalExtensions may be reducible, but the same field can contain useful commands, URLs, users, and identifiers.
AdditionalExtensions
A table with no observed query activity deserves review. Some evidence is retained for rare investigations, and some consumers are not represented in a simple query audit.
Enable query auditing through the workspace diagnostic settings to collect LAQueryLogs. Auditing does not backfill earlier activity, and storing the audit records can incur charges.
LAQueryLogs
This query compares billable volume with table-name tokens found in available query audit records:
let billable = Usage | where TimeGenerated > ago(30d) and IsBillable == true | summarize BillableGB = round(sum(Quantity) / 1000, 1) by DataType; let queried = LAQueryLogs | where TimeGenerated > ago(90d) | extend Tokens = extract_all(@"([A-Za-z_][A-Za-z0-9_]*)", QueryText) | mv-expand Token = Tokens to typeof(string) | summarize Queries = dcount(CorrelationId), Users = dcount(AADEmail), LastQueried = max(TimeGenerated) by Token; billable | join kind=leftouter queried on $left.DataType == $right.Token | project DataType, BillableGB, Queries = coalesce(Queries, 0), Users = coalesce(Users, 0), LastQueried | sort by BillableGB desc
The result is a candidate list for dependency analysis. It is not a deletion list.
Before changing a table, inspect:
Scheduled alert executions are excluded from Azure Monitor’s user-context query audit. Review enabled rule definitions and any functions they call.
A query using an ASIM parser can depend on a raw table without naming it directly.
Review stored queries, API consumers, playbooks, and scheduled jobs.
Check relevant analytics, UEBA inputs, and product capabilities that rely on the source.
Identify evidence that may be needed infrequently but would be difficult or impossible to reconstruct later.
The KQL above uses text matching rather than full dependency resolution. Comments and strings can create false matches, while indirect functions and case differences can hide real use. It also counts audited queries without establishing that they succeeded.
Current Azure Monitor documentation identifies Defender advanced hunting as a query client. Avoid a blanket assumption that all hunting and investigation queries are excluded. Run known queries through the interfaces your team uses and verify which audit records actually appear.
Microsoft Sentinel SOC optimization recommendations can provide another input. Finish the review with a named owner and a decision: retain in analytics, move to the lake, reduce detail, archive elsewhere, or stop collection.
To reduce ingestion charges, change what is collected or stored before it reaches the chargeable destination. Filtering an investigation query changes the search result, not the earlier ingestion bill.
Start with confirmed duplication and unnecessary detail, then consider broader reductions only after checking their security effect.
Select the required Windows security events through AMA settings and XPath, or adjust device logging where appropriate. Confirm whether other destinations still need the events.
Supported collection paths can filter rows, modify fields, normalize values, and mask content before storage. Preserve the destination schema and required investigation fields.
Supported tables arriving through other collection paths can use workspace transformation DCRs. Eligibility varies by table and connector.
The Defender portal provides supported controls for discarding selected records or routing retained records between analytics and the lake.
The following examples demonstrate transformation mechanics using the virtual source table. They are not default production policies.
source
// SecurityEvent: drop Windows Filtering Platform connection and bind events source | where EventID !in (5156, 5158)
Events 5156 and 5158 provide permitted-connection and local-port-bind evidence. Removing them can reduce volume, but also removes that detail from the selected collection path. Check required detections and whether another source supplies equivalent evidence for the same assets and period.
// Syslog: keep authentication facilities in full, drop debug and info elsewhere source | where Facility in ("auth", "authpriv") or SeverityLevel !in ("debug", "info")
This retains authentication facilities and drops debug or informational records elsewhere. Security-relevant application activity can use other facilities, so validate actual messages from each source.
// CommonSecurityLog: blank the bulky extension field on allowed traffic only source | extend AdditionalExtensions = iif(DeviceAction in ("allow", "accept"), "", AdditionalExtensions)
This blanks AdditionalExtensions on matching allowed traffic. Check the source’s action values and the field contents before applying it. Allowed connections can carry malicious activity, and the extension field may hold essential evidence.
Test matching records, non-matching records, missing fields, and unexpected values. Keep the previous configuration and verify required fields and events after deployment.
Standard ingestion-time KQL transformations operate on individual records and do not support multi-record summarize aggregation. Microsoft’s newer multi-stage transformation capability is in preview and has separate supported processors and constraints. Evaluate it separately from standard transformKql behavior.
summarize
transformKql
For Analytics tables in Microsoft Sentinel-enabled workspaces, Microsoft exempts transformations from the filtering ingestion charge. Basic tables can incur that charge when more than half the incoming volume is dropped. Lake processing uses its own meter.
The portal controls also need care: a filter condition evaluating to true discards the matching record. A split condition evaluating to true routes it to Analytics, with other retained records going to the lake. A standard DCR where clause instead retains matching rows. Validate both outcomes and allow for configuration propagation.
where
Discarded records do not automatically remain in the lake. Establish a separate retention route first if the evidence must be preserved.
Choose the destination according to how and when the SOC needs the data. A large source may contain both time-sensitive detection evidence and background history.
Moving data out of analytics changes its available detection and query paths. Existing rules and ordinary analytics queries may need redesign. A scheduled lake search is not equivalent to a real-time detection.
Check restrictions on XDR and solution tables before designing a split.
A summary can retain useful counts, bytes, source, destination, protocol, and time windows while reducing repeated detail in analytics.
Design it around a specific question. Grouping only by destination can destroy the host-level detail needed to identify which system made a connection.
Summary rules and applicable lake jobs can produce compact analytics output while retaining raw evidence in the lake. Include the source query, output ingestion, retention, and processing delay in the cost model.
Summarizing records after full analytics ingestion does not remove the original ingestion charge.
At the listed rate, scanning 10,000 uncompressed GB costs $50. Repeating it daily for thirty days costs $1,500 before storage or other processing. That is roughly the cost of ingesting 350 GB into pay-as-you-go analytics.
Restrict recurring searches by time, table, and relevant entities. A small result set does not necessarily mean a small scan. Use suitable summaries for repeated questions and review actual consumption.
For notebooks, include active vCores and running time. Stop unused sessions and review jobs that continue after the investigation that created them has ended.
Set analytics retention for the period requiring ready investigation access, then total retention for the full preservation requirement.
Keeping a year of evidence does not necessarily require keeping every record in analytics for a year. Set total retention against investigation needs and documented preservation requirements.
Table-management documentation describes a thirty-day default and an eligible extension to ninety days for Microsoft Sentinel solution tables. Verify actual settings and billing eligibility.
Supported lake retention can extend to twelve years. Select periods by evidence purpose rather than using the maximum everywhere.
Native Defender advanced hunting includes thirty days. Extending supported data into Microsoft Sentinel introduces the applicable ingestion and storage arrangement.
Reducing analytics retention from 180 to 90 days while keeping total retention at 180 preserves older records in the lake, with a different query path.
A shorter analytics window can change access immediately. Microsoft documents a thirty-day safeguard before removal following reduced total retention; this does not preserve the former analytics experience.
Increasing retention cannot recover records already deleted. Test the retrieval path before shortening the period investigators depend on.
Dashboards, detections, and investigations run directly on the data.
Older indices on cheaper storage, still queryable for hunts.
Compressed storage that is restored or thawed before analysis.
Object storage you own, kept for audits, legal holds, and forensics.
These labels describe access patterns, not four interchangeable Microsoft Sentinel billing plans. Record the actual service, retention setting, and retrieval process behind each policy.
SIEM log retention covers wider preservation requirements and planning considerations.
External archive can suit evidence retained for infrequent use. Azure Blob Storage has online access tiers and an offline archive tier, with different retrieval costs and delays.
Model export charges, storage operations, retained size, retrieval, possible early-deletion charges, and any later ingestion required for analysis. Exported JSON can also be larger than the billable data recorded inside Log Analytics.
Check export support for the selected tables. Continuous workspace export handles supported newly arriving data; it does not automatically provide a historical backup or establish the export route for lake-only tables.
Preserve timestamps, identifiers, and schema information, then test a realistic retrieval. Record how long it takes to produce searchable evidence.
A commitment tier trades a daily minimum charge for a lower effective ingestion rate. Overage uses that tier’s rate, while unused daily capacity does not carry forward.
Compare candidate tiers against each complete UTC day in a representative period, then add the totals. Monthly averages can hide unused capacity on quiet days.
Using the listed East US rates:
Reconcile benefit treatment and effective prices before using this arithmetic as an invoice forecast.
Size the tier against the volume expected after filtering and tier changes. Otherwise, successful reduction work can leave a fixed charge for capacity the workspace no longer uses.
You can increase a tier at any time, restarting the 31-day minimum commitment period. Lowering it or returning to pay-as-you-go requires that period to have ended. A reduction is not applied automatically when ingestion falls.
The 50 GB/day public-preview promotion currently accepts enrollment through December 31, 2026, with promotional pricing retained until March 31, 2027. At the listed $161.25 daily rate, it breaks even against pay-as-you-go at 37.5 GB/day. Confirm eligibility and restrictions before budgeting for it.
Microsoft Sentinel pre-purchase commit units apply to eligible analytics costs during a one-year term. They are separate from Security Copilot compute units and do not pay for data lake capabilities. Evaluate them after expected remaining consumption is understood.
Ordinary workspace commitments cannot simply be pooled across unrelated workspaces. Dedicated Log Analytics clusters provide a separate aggregation arrangement for qualifying same-region workspaces, starting at 100 GB/day collectively. Include the cluster requirements and billing behavior in that comparison.
Consider a workspace ingesting 400 GB/day into analytics. The following design reduces analytics ingestion, retains selected raw evidence in the lake, and filters specified Windows events.
The volumes illustrate the cost model. They are not recommended filtering percentages for every environment.
Using the listed East US prices:
The 100 GB tier plus 47 GB of overage costs $435.12/day, about 42% of the original daily cost.
Ingestion and processing cost $33.45/day, about 3%.
223 GB × 365 days ÷ 6 gives the compressed storage basis. At $0.026/GB/month, that is about $11.76/day, or 1%, using a thirty-day billing-month approximation.
The modeled total is approximately $480.33/day, compared with $1,037.33/day before the changes. That is about 46% of the original cost, or 54% lower, for the included meters.
This excludes benefit grants, lake queries, notebook compute, extended analytics retention, summary-output ingestion, external archive costs, and engineering work. The lake-storage figure represents steady state after a year of accumulation. The DNS matching job still needs pricing.
The firewall split must preserve the records required by actual detections and investigations. Keeping only denies and threat alerts can miss malicious allowed connections.
Moving DNS matching to a scheduled job changes detection timing. The 30 GB filtered from SecurityEvent is not retained in Microsoft Sentinel by this design.
SecurityEvent
Also account for the current commitment. Ingestion volume can fall before fixed commitment charges can be reduced. Measure the cost once the permitted tier change has taken effect.
A useful review produces an agreed change plan with expected savings, security dependencies, an owner, and a way to verify the result.
Export representative costs and complete daily ingestion periods. Record the region, pricing model, commitment, benefit usage, table tiers, retention, and supporting Azure resources.
Identify outages, incident surges, backfills, and seasonal jobs so they do not distort the forecast.
For expensive tables, identify the producers, consumers, required fields, preservation requirements, and owner. Distinguish infrequently used evidence from information without a current security purpose.
Review rules, functions, built-in features, integrations, and incident requirements before approving removal. The wider assessment is covered in augmenting Microsoft Sentinel.
Start with confirmed duplication or unnecessary fields and event categories. Preserve the previous configuration and test a limited source group.
Check required records, entity mapping, rule behavior, and investigation detail. An unchanged alert count alone does not establish that coverage was preserved.
Validate replacement queries before moving data. Model summaries, raw retention, recurring scans, and their delays together. Set analytics and total retention explicitly, then resize the commitment against the remaining volume.
Compare actual billed cost and security operation before and after the change. Record expected savings, observed savings, accepted changes in detail or timing, and who approved them.
Keep the reason for each decision with its configuration. Later connector or policy updates should not quietly undo the optimization.
Monitor unexpected growth and unexpected loss of data together. A cheaper month caused by a broken collector is a coverage problem.
This query compares each table’s recent seven-day billable volume with the preceding seven days:
Usage | where TimeGenerated > ago(14d) and IsBillable == true | summarize ThisWeekGB = sumif(Quantity, TimeGenerated > ago(7d)) / 1000, LastWeekGB = sumif(Quantity, TimeGenerated <= ago(7d)) / 1000 by DataType | extend ChangePct = round(100.0 * (ThisWeekGB - LastWeekGB) / LastWeekGB, 1) | where ThisWeekGB > 1 | sort by ChangePct desc
New tables may have no previous-week baseline. The query also excludes small tables and sources that stopped completely because of its ThisWeekGB > 1 condition. Pair it with source-health monitoring and handle new or silent sources separately.
ThisWeekGB > 1
Use a regular review schedule:
Review ingestion anomalies and spend notifications. Cost Management budgets and the Send-IngestionCostAlert playbook can help, but notifications do not automatically stop collection.
Send-IngestionCostAlert
Review Table insights for large tables, volume changes, and last received data. Its estimates use public list prices, not private rates or commitment discounts.
Reconcile commitments, benefit records, lake scans, notebook activity, retention, and the actual invoice.
Repeat dependency reviews and test retrieval of archived evidence.
Review new connectors, collection policies, large deployments, backfills, and source migrations.
Set an owner for each alert and a response procedure. Any enforced query or compute limit can also affect an investigation or scheduled job. Microsoft’s preview lake cost controls can take up to four hours to enforce, so they are not an instantaneous spending stop.
Review temporary offers before they expire. The current 50 GB promotion enrollment deadline is December 31, 2026. Also update operating procedures for the end of Microsoft Sentinel support in the Azure portal after March 31, 2027.
ThreatDefence includes Microsoft Sentinel data management in its AI SOC service. Each source is assessed for detection and investigation value, then kept in analytics, reduced before ingestion, moved to the lake, or archived. The 24x7 SOC checks that detections still work after every change. In most environments, this reduces Microsoft Sentinel data costs by 50 to 70%.
The service connects through a service principal with Log Analytics Reader for KQL and Microsoft Sentinel Responder for incident work, assigned by an authorized Owner or User Access Administrator. These roles support assessment and incident operations. Changes to collection, tiers, or retention require separately authorized engineering permissions.
Network detection and response can answer some detection questions that would otherwise depend on raw traffic logs. Any substitution is checked against the required evidence rather than treated as a complete replacement for network history.
A free Microsoft Sentinel cost and coverage review examines your workspace and shows where costs can be reduced and where coverage needs attention before anything changes.
Explore Microsoft Sentinel MDR
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
No. Analytics pricing primarily follows ingested data through pay-as-you-go or daily commitments. Lake ingestion, processing, storage, queries, and applicable compute have separate meters. Microsoft 365 licenses can provide eligible data allowances, but not unlimited per-user ingestion.
Yes, after the 31-day minimum commitment period ends. Increasing the tier restarts that period. Falling ingestion does not automatically select a lower tier.
No. It covers up to 5 MB per eligible user per day from specified data types. Ineligible sources and eligible usage above the allowance remain chargeable. Check qualifying licenses, tables, and actual benefit application.
Eligible Defender alerts and incidents are free to ingest. Underlying endpoint, identity, and email event tables can incur charges, subject to applicable benefits. Select the required data types deliberately.
Analytics-table transformations in Microsoft Sentinel-enabled workspaces are exempt from Azure Monitor’s filtering ingestion charge. Basic tables can incur it when more than half the incoming data is dropped. Lake processing is a separate charge.
Yes. Microsoft offers a Microsoft Sentinel cost estimator with meter-level projections, and the Azure pricing calculator provides another estimate. Use measured daily volumes, retention, query activity, and effective prices to build a realistic budget.
No. Included Security Copilot capacity does not pay for Microsoft Sentinel lake storage, queries, or advanced data insights. Microsoft Sentinel pre-purchase commit units and Security Copilot compute units are separate.
No. They use public list prices for the table’s tier and region. Use the invoice and Cost Management exports to establish charges after commitments, benefits, and private pricing.
Scheduled alert executions are excluded from Azure Monitor’s user-context query auditing. Inspect rule definitions and their functions separately. Coverage of other query paths should be verified with known test queries; a missing audit entry does not prove that a table is unused.
What Is SIEM as a Service?
SIEM Use Cases
AI SIEM