Skip to main content
emnode
Sign up
Compliance High severity

AWS Security Hub · GuardDuty

GuardDuty.1: GuardDuty threat detection is not enabled

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub GuardDuty.1 check?

GuardDuty.1 fails when Amazon GuardDuty is not enabled in the account/Region.

Why does GuardDuty.1 matter?

GuardDuty is AWS's managed threat-detection service: it analyses CloudTrail, VPC flow, and DNS data for signs of compromise like crypto-mining, credential exfiltration, and reconnaissance. Without it, that detective layer is missing entirely, and many attacks that GuardDuty would surface in minutes go unnoticed.

How do I fix GuardDuty.1?

  1. Enable GuardDuty in every active Region.
  2. Delegate administration to a security account and auto-enable it for all member accounts in the organization.
  3. Route findings to Security Hub and an alerting pipeline so detections are actioned, not just stored.

Remediation script · bash

# Enable the GuardDuty base detector in every Region (run from the delegated admin account).
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  existing=$(aws guardduty list-detectors --region "$region" --query 'DetectorIds[0]' --output text)
  if [ "$existing" = "None" ]; then
    aws guardduty create-detector --enable \
      --finding-publishing-frequency FIFTEEN_MINUTES --region "$region"
    echo "$region: GuardDuty detector created"
  fi
done

# Turn on Inspector EC2/ECR/Lambda scanning for this account and Region.
aws inspector2 enable --resource-types EC2 ECR LAMBDA

# Enable Macie (free bucket inventory clears Macie.1; discovery jobs are scoped separately by risk).
aws macie2 enable-macie --status ENABLED --finding-publishing-frequency FIFTEEN_MINUTES

Full walkthrough (console steps, edge cases and verification) in the lesson Enable threat detection and vulnerability scanning.

Is GuardDuty.1 a false positive?

The control recommends enabling GuardDuty in every Region (including opt-in or otherwise-unused Regions), so an account that you've deliberately locked down to a small set of approved Regions with an SCP will fail in each Region you intentionally don't operate in, even though no resources live there. The underlying guardduty-enabled-centralized rule does support a central-account parameter, but Security Hub doesn't populate it, so a member account managed by a delegated GuardDuty administrator is still evaluated on its own local enablement. Where a Region is genuinely off-limits by design, suppress the finding (or scope the standard to your active Regions) with a note pointing at the governing SCP, rather than turning GuardDuty on in a Region you forbid everything else in.

Full lesson Enable threat detection and vulnerability scanning Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for GuardDuty controls ↗ Check your own account for GuardDuty.1 →
Part of the learning path See what's happening

More GuardDuty controls