Build GuardDuty finding filter configurations with criteria for severity, type, and resource attributes.
Build GuardDuty finding filter configurations with criteria for severity, type, and resource attributes.
Required Fields
DetectorIdNameFindingCriteria.CriterionOutput will appear here...Build a GuardDuty finding filter that auto-archives noisy, low-value findings by severity, finding type, or resource attribute, without hand-writing the FindingCriteria JSON. Findings are scored 0.1-8.9 (Low under 4, Medium 4-6.9, High 7-8.9); an archived finding still exists but stops triggering EventBridge rules and SNS notifications, so it stops paging anyone.
A security engineer notices GuardDuty has been quietly archiving nothing and Slack has 40+ unread #security-alerts pings from the sandbox account overnight, all Recon:EC2/PortProbeUnprotectedPort at severity 5, generated by the team's own automated port-scanning test suite hitting its own test instances. They use the builder to scope a filter to accountId.Eq the sandbox account plus that exact finding type, set Action to ARCHIVE at Rank 10 so it doesn't shadow anything else, and paste the JSON into the team's existing Terraform module. Production's identical finding type, different account ID, keeps alerting normally.
Set Action to ARCHIVE, never NOOP, for anything you actually want silenced — NOOP filters exist for testing criteria matches in the console without changing finding behavior, and it's an easy copy-paste mistake to ship one to production.
Scope archive filters as tightly as the noise source allows (specific accountId, specific resource.instanceDetails tag, specific finding type) rather than a broad severity.Lt cutoff — a wide low-severity filter silently eats new Low finding types AWS adds later, not just the ones you were trying to suppress today.
Findings evaluated by a filter with Rank 1 that use ARCHIVE never reach any Rank 2+ filter, so audit existing filters with the GuardDuty console's 'Filter' tab before adding a new low-rank one — a forgotten catch-all from a past incident silently eats findings you now need.
The builder assembles the FindingCriteria.Criterion object GuardDuty's CreateFilter and UpdateFilter APIs expect, mapping each condition you pick (severity, finding type, resource fields, accountId, updatedAt) to the correct comparator key (Eq, Neq, Gt, Gte, Lt, Lte, Exists, EqExactMatch), and validates that DetectorId, Name, and at least one Criterion entry are present before letting you copy the output, since GuardDuty's API rejects a filter with an empty criteria object.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.