Threat detection on AWS with GuardDuty and EventBridge

Turn on GuardDuty across the org and route high-severity findings to Slack and auto-remediation with EventBridge.

Amazon GuardDuty is AWS-native threat detection you turn on rather than build from scratch. It ingests CloudTrail management events, VPC Flow Logs, and DNS logs (and optional EKS audit logs, S3 data events, and Malware Protection for EC2) and matches them against AWS-maintained threat intelligence and ML models. Findings like UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration — role credentials used from an IP outside your accounts — or crypto-mining on a compromised instance surface without you writing correlation rules from day one.

The operational work is not enabling GuardDuty in one account and forgetting it. Delegate administration to a security account, auto-enroll every member including new accounts, route findings through EventBridge to somewhere humans or automation act, and filter severity so you page on 7.0–8.9 (High) rather than drowning in Low informational noise. The AWS security for DevOps engineers track covers GuardDuty alongside IAM, org-wide guardrails, and incident response patterns.

What a real finding looks like

Findings include severity (1.0–8.9), type, affected resource, and geographic context. Instance credential exfiltration — when temporary role credentials from an EC2 instance are used from an unexpected network — is a classic signal that a workload was compromised and an attacker is pivoting to the AWS API. Treat High severity as a paging candidate until you have enough history to tune.

Enable across the whole organization

Designate a GuardDuty administrator account in AWS Organizations, enable the detector there, then create an organization configuration that auto-enables new and existing member accounts. Verify with list-members that every account shows RelationshipStatus: Enabled — drift happens when accounts are created outside your org automation.

aws guardduty enable-organization-admin-account \
  --admin-account-id 222233334444
 
aws guardduty create-detector --enable
 
aws guardduty update-organization-configuration \
  --detector-id $DETECTOR_ID \
  --auto-enable-organization-members ALL

Route findings to action with EventBridge

GuardDuty publishes to EventBridge automatically. Match on source: aws.guardduty and filter detail.severity to 7 and above for pages. Send Medium findings to a Slack channel or security dashboard. Wire a Lambda target for unambiguous auto-remediation — isolate the ENI, revoke active sessions for the IAM user, snapshot the volume for forensics — but keep human approval on destructive actions until you trust the rule.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7.0] }]
  }
}

Where this goes next

GuardDuty tells you something went wrong; IAM boundaries and SCPs reduce what a stolen credential can do. Pair detection with OIDC federation for CI (no long-lived keys), VPC endpoints so exfiltration paths are visible, and a runbook that ties GuardDuty finding types to concrete response steps. The AWS security for DevOps engineers path covers detection, IAM, and org-wide guardrails on AWS.

Related posts