GuardDuty at scale: delegated admin, suppression rules, and EventBridge routing

One place for every account

In AWS Organizations, a delegated administrator account sees findings for every member account and can enable GuardDuty automatically for new ones. Analysts then work in one console and one API, and member account owners cannot quietly disable it.

Snippet

aws guardduty enable-organization-admin-account --admin-account-id 111122223333
# in the admin account
aws guardduty update-organization-configuration --detector-id "$DET" --auto-enable-organization-members ALL

A suppression rule that stays narrow

Suppression rules archive matching new findings automatically. They should match on several fields, never type alone. Here, a sanctioned vulnerability scanner in the security account triggers Recon:EC2/Portscan from known instances; the rule matches type, account, and instance tag together.

Snippet

aws guardduty create-filter --detector-id "$DET" --name approved-scanner-portscan --action ARCHIVE --rank 1 \
  --description 'Approved scanner fleet; owner vuln-mgmt; review 2027-05-01' \
  --finding-criteria '{"Criterion":{
    "type":{"Eq":["Recon:EC2/Portscan"]},
    "accountId":{"Eq":["444455556666"]},
    "resource.instanceDetails.tags.value":{"Eq":["approved-scanner"]}}}'

Routing what matters

GuardDuty publishes findings to EventBridge. A rule matching severity 7 and above sends them to an SNS topic or chat integration for on-call. Lower severities flow to the SIEM for daily review instead of paging anyone.

Snippet

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

aws events put-rule --name gd-high-to-oncall --event-pattern file://gd-high.json
aws events put-targets --rule gd-high-to-oncall --targets Id=oncall,Arn=arn:aws:sns:us-east-1:111122223333:secops-oncall

Worked review of a suppression request

A team asks to suppress every Recon:EC2/Portscan finding because their scanner is noisy. The reviewer narrows it to the scanner’s account and tag, as above, and adds a review date. A month later, a Portscan finding from a web server in a different account arrives untouched by the rule and turns out to be a compromised container scanning its neighbours. A type-only rule would have archived it.

Diagram

Broad versus narrow suppression

Match on who and where, not only what.

Type only

Matches. Every Recon:EC2/Portscan

Hides. Real scans from compromised hosts

Review. Rarely revisited

Type plus account plus tag

Matches. The approved scanner fleet

Hides. Only expected activity

Review. Owner and date in the description

Check yourself

1. Why should a suppression rule never match on finding type alone?

2. Which service delivers GuardDuty findings to on-call targets?

3. What does a delegated administrator account provide?