Cloud Threat Detection Calculator

Detection score = account coverage × 0.5 + latency score × 0.3 + precision score × 0.2, where latency score = max(0, 100 − 3 × MTTD hours) and precision score = min(100, 2 × precision). Coverage carries half the score because a detection you have not enabled everywhere is not a detection, and latency carries 30% because dwell time is what turns an alert into a breach. Precision is deliberately capped at a doubling: 50% precision scores the full 100, since a cloud detection service that raises one real finding for every false one is performing very well by real-world standards.

Cost per confirmed finding is the number that ends the argument about whether to keep S3 data event analysis on, and dwell time is the number that predicts whether you will be writing a breach notification.

This calculator takes 12 inputs: Accounts in scope, Accounts with threat detection enabled, VPC flow log volume analysed, Flow log analysis price per GB, CloudTrail management events analysed, Management event analysis price per million, S3 data events analysed, S3 data event analysis price per million, Findings raised per month, Findings confirmed as real per month, Mean time to detect, Mean time to respond. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Rarely — it is a reason to tune it. Suppress by resource and finding type rather than turning off the finding class, because the same rule that fires on your benign vulnerability scanner is the one that will fire on a real reconnaissance sweep. Disabling it wholesale removes both.

Flow log analysis in network-heavy estates, S3 data event analysis in data-heavy ones. Both scale with workload rather than with security value, so scope data event analysis to the buckets that matter and consider sampling flow logs on high-volume, low-risk VPCs.