Skip to main content
compliance · aws

Regions where GuardDuty threat detection is confirmed off

resource types
1
rule IDs covered
1
severity
critical

What does ZopNight detect here?

GuardDuty analyses VPC flow logs, CloudTrail events, and DNS query logs without any agents to install, yet ZopNight still finds accounts running with 0 detectors. The rule fires only when discovery explicitly confirms enabled=false for a region. An unreadable status abstains rather than raising a false security alarm.

Signal and threshold

How ZopNight evaluates Regions where GuardDuty threat detection is confirmed off.
Field Value
Rule IDsRC-1100
Categorycompliance
Severitycritical
Metricnone — pure configuration read
Sourceguardduty_disabled.go

The detection layer you get without deploying anything

GuardDuty is unusual among security controls in that enabling it changes nothing about your workloads: no agents, no sidecars, no performance cost. AWS feeds it the telemetry it already has (VPC flow logs, CloudTrail management events, DNS query logs), and it reports compromised instances, credential exfiltration, cryptomining, and reconnaissance patterns. An account without it is not missing a nice-to-have; it is missing the baseline answer to “would we even know if a key leaked?”

Confirmed off, not merely unknown

The discoverer records the detector state for the region into the resource’s metadata as an explicit enabled flag. The rule raises a finding only when that flag reads false. When the value is absent or unparseable, because the status call failed or the region was unreachable, the rule abstains, because a security finding built on missing evidence is itself a kind of false alarm. So a fired finding here means the detector state was positively read and it was off.

Per-region is the trap

GuardDuty is enabled region by region, and that is how coverage gaps happen: the primary region gets a detector on day one, and the seventeen regions nobody deploys to, which is exactly where an attacker prefers to operate, stay dark. The account-level fix is worth more than any single finding: enable GuardDuty through AWS Organizations with a delegated administrator, auto-enrolling every current and future account and region so the gap cannot reopen.

Confirm a region’s state

Terminal window
aws guardduty list-detectors --region eu-west-1 --query 'DetectorIds'

An empty list means no detector exists in that region; a returned ID can be checked with aws guardduty get-detector --detector-id <id> --query 'Status'.

Cost, since someone will ask

GuardDuty prices on analysed event and log volume, with a 30-day free trial per account that shows the real number before commitment. For most accounts it lands far below the cost of the engineering hours a single undetected incident consumes. The finding itself carries no dollar value: turning detection on saves nothing on the invoice and everything on the incident that never gets a post-mortem.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·