Matching Findings with Event Patterns

You do not want to react to every event — only the ones that matter. An event pattern is the filter that decides which events a rule acts on.

A precise pattern means your automation fires exactly when a real threat appears and stays quiet otherwise, avoiding both missed alerts and noisy false triggers.

An event pattern is JSON that mirrors the structure of the events it matches. You specify the fields and values you care about; an event matches only if every specified field matches.

Fields you omit are ignored, so a pattern can be as broad or as narrow as you need.

The most common filter is source — for example "aws.guardduty" or "aws.macie".

Combined with detail-type, this narrows events to a specific kind from a specific service. It is the natural starting point for any security rule before you refine further.

You often want to act only on serious findings. By matching nested fields in detail, a pattern can require, say, a GuardDuty severity at or above a threshold.

EventBridge supports numeric matching like greater-than, so a rule can fire only for high-severity findings and ignore low-risk noise.

Patterns support richer operators: prefix matching, exists checks, anything-but, and IP-address CIDR matching.

These let you express precise conditions — match any finding type starting with "UnauthorizedAccess", or any event whose region field exists but is not your home region.

GuardDuty produces dozens of finding types like Recon, CryptoCurrency, or InstanceCredentialExfiltration.

By matching the detail.type field, you can route different threats to different remediations — credential theft to one Lambda, cryptomining to another — so each gets the response it deserves.

A pattern that never matches is a silent failure. Use the EventBridge console's sandbox to paste a sample event and confirm the pattern matches it.

Testing with real event samples before deploying prevents the embarrassing and dangerous case of automation that simply never fires.

Too broad a pattern triggers remediation on benign events, causing disruption — imagine isolating instances on every low-severity informational finding.

Scope patterns to genuine threats. The art is matching enough to catch real incidents while excluding the routine noise that should not invoke automated action.

The same pattern syntax works for any event source: Config rule compliance changes, Security Hub findings, Macie discoveries, or specific CloudTrail API calls.

Learning event patterns once lets you build security automation across your entire AWS estate using one consistent matching language.

Rather than one giant pattern trying to catch everything, build several focused rules, each with its own pattern and target.

One rule isolates instances on credential findings; another only alerts on low-severity recon; another reacts to Macie discoveries. Smaller, single-purpose rules are easier to test, reason about, and adjust than one sprawling catch-all.

A matched event is only useful when paired with a target. The pattern decides whether to act; the target decides what to do.

Together they form a rule: this kind of finding, of this severity, triggers this specific remediation. That pairing is the heart of every automated response.

Pick the precise filter.

An event pattern is the JSON filter that decides which events a rule acts on, matching fields like source, detail-type, and nested detail values. Use numeric matching for severity thresholds and advanced operators (prefix, exists, anything-but, CIDR) to scope precisely. Match specific GuardDuty finding types to route distinct remediations, test patterns in the sandbox, and avoid over-matching so automation fires on real threats only.