GuardDuty threat detection

Agentless findings from CloudTrail, flow, and DNS.

You cannot write every detection rule yourself across dozens of accounts. GuardDuty is the managed detector that continuously analyzes the logs you already produce and raises prioritized findings, so your effort goes into response rather than building analytics from scratch.

What it watches, agentlessly

GuardDuty consumes CloudTrail management and S3 data events, VPC flow logs, and DNS query logs — no agent to deploy — and correlates them against AWS threat intelligence and behavioral baselines. It flags things like credentials used from a new country, an EC2 instance talking to a known-bad IP, anomalous IAM calls, and crypto-mining patterns. Additional protection plans extend it to EKS runtime, RDS login activity, Lambda, and S3/EBS malware.

# Delegate GuardDuty to the security account, then auto-enable every account
# (and every FUTURE account) so coverage is an org property, not a checklist.
aws guardduty enable-organization-admin-account --admin-account-id 333333333333
 
aws guardduty update-organization-configuration \
  --detector-id DET123 --auto-enable-organization-members ALL \
  --features '[{"Name":"RUNTIME_MONITORING","AutoEnable":"ALL"}]'

Coverage everywhere is the point

The biggest failure mode is partial coverage — enabled in some accounts and regions but not others, leaving exactly the blind spot a quiet attacker wants. Delegate administration to your security account, auto-enable all members, and aggregate findings centrally. GuardDuty detects and alerts; it does not sit inline blocking traffic, so its value is realized only when its findings flow into a response pipeline.