AWS Regions where the GuardDuty detector is turned off
What does ZopNight detect here?
Amazon GuardDuty is a Regional threat detection service, and ZopNight flags a Region where discovery finds no detector, or a detector whose status is not `ENABLED`. The check reads detector status rather than tags, stays silent when detectors cannot be listed, and carries a $0 saving because the gap is missed threats, not spend.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1100 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Threshold | no detector, or status not ENABLED |
| Source | ZopNight |
| Permissions used | guardduty:ListDetectors · guardduty:GetDetector |
Where it applies
Why a disabled detector leaves a Region unwatched
GuardDuty is the AWS service that turns account activity into threat findings. Once a detector is on, it automatically ingests foundational data sources: CloudTrail management events, VPC flow logs from EC2 instances, and DNS logs. Nothing else has to be configured for it to start producing findings about unusual API calls, credential misuse or instances talking to known bad hosts.
The catch is scope. AWS describes GuardDuty as a Regional service whose setup must be repeated in each Region, and recommends enabling it in all supported Regions, including the ones you do not use. An attacker with stolen keys will happily launch resources in a Region nobody looks at.
Seeing detector status Region by Region
A Region with no detector returns an empty list. Where a detector exists, read its status:
aws guardduty list-detectors --region us-east-1 --query 'DetectorIds[]' --output text
aws guardduty get-detector --region us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34e56789f0 --query 'Status'Status is either ENABLED or DISABLED. Looping the first command over
aws ec2 describe-regions --query 'Regions[].RegionName' --output text gives a full picture.
What ZopNight has to observe first
The finding depends on one value: the enabled flag ZopNight records from GuardDuty during discovery. It fires only when that flag says the detector is off. A Region with no detector at all is recorded as off, so it is flagged too. Tags play no part, so labelling a resource cannot hide or trigger the finding.
Cases where no finding appears
If discovery could not list GuardDuty detectors for a Region, for example because the scanning role lacks
guardduty:ListDetectors, the enabled flag is missing and the rule says nothing. If the list works but a
detector’s status cannot be read, that detector is recorded as off and is flagged. That makes the
check conservative: a silent Region is not proof that GuardDuty is running there, so confirm with
the CLI above if your role is narrowly scoped.
The cost side: a free trial, then usage-based billing
ZopNight reports no saving here. Turning GuardDuty on adds a usage-based charge driven by the volume of events it analyses. When you enable GuardDuty for the first time in a Region, the account is enrolled in a 30-day free trial for that Region, and usage metrics during the trial let you estimate the monthly bill before paying for it.
Enabling GuardDuty everywhere it should run
- For a single account, create a detector in each Region:
aws guardduty create-detector --enable --region us-east-1- For an organization, designate a delegated GuardDuty administrator account from the Organizations management account and auto-enable member accounts.
- Review which protection plans are on; some protection plans are enabled and included in the 30-day trial by default, and you can opt out of any of them.
- Export findings to an S3 bucket and route high-severity findings to your alerting channel through EventBridge or SNS.