Amazon GuardDuty: 6 Habits That Turn Threat Detection Into Your Safety Net

I ignored GuardDuty for way too long. It sat enabled in one account, quietly stacking up findings nobody looked at, and I told myself the alerts were just noise. Then I actually read the finding detail on a Medium-severity EC2 finding and realized how much context it packs — the API calls, the timeline, the actor IP history. That changed how I treat it. Now GuardDuty is part of my security baseline, and these are the six habits that made the difference.

## 1. Enable it org-wide, not just in your main account

GuardDuty is opt-in per Region, per account. The most common failure I see is a team enabling it in their production account and forgetting the other nine accounts in the org — including the sandbox where someone's experiment is doing something weird at 2 AM. If you use AWS Organizations, set up a delegated GuardDuty administrator and let it auto-enable for new accounts as they join. Threats don't respect your account boundaries, so your detection shouldn't either.

## 2. Triage by severity, not by recency

GuardDuty findings come in Critical, High, Medium, and Low. My rule: Critical and High get looked at immediately, Medium gets a same-day review, Low gets reviewed in a weekly batch. Sorting by "newest first" and working down the list is how alert fatigue wins. The severity rating already did the prioritization work for you — trust it and act accordingly.

## 3. Wire findings to EventBridge on day one

A finding that lands in a console nobody opens is a finding that doesn't exist. The single highest-leverage thing you can do is send Critical and High findings to EventBridge and route them somewhere a human actually looks — an SNS topic, a Slack channel, a PagerDuty service. I route Critical findings straight to an incident channel and Medium/Low to a daily digest. Five minutes of EventBridge rule setup turns GuardDuty from a dashboard into a detection pipeline.

## 4. Suppress deliberately, with an expiry date

Not every finding is an incident. Pen-test windows, legitimate scanning tools, and known research workloads will generate findings you don't need to act on. The right move is a suppression rule that documents *why* it's suppressed — never just ignoring the service. And put an expiry on it. A suppression rule without a review date becomes a blind spot that outlives the reason it was created.

## 5. Validate findings against CloudTrail before you call it an incident

GuardDuty findings are rich, but I never declare an incident off a single finding. Cross-check with CloudTrail: pull the event history for the principal, look at what happened in the minutes before and after, and if you need to go deeper, run the trail through Athena. Finding plus trail evidence is how you move from "something looks off" to "here's exactly what happened, and here's the blast radius."

## 6. Switch on the protection plans you actually need

The base GuardDuty detector is only the start. S3 protection, EKS protection, RDS protection, Lambda protection, and Malware Protection for EC2 and S3 are separate plans — off by default, each with its own cost. I enable Malware Protection on EC2 and S3 protection everywhere because those are my highest-risk surfaces, and I skip the rest until the workload justifies it. Revisit this quarterly: enable what's worth it, and don't pay for detection on resources that don't exist.

## Key takeaways

- Enable GuardDuty org-wide with a delegated administrator so new accounts are covered automatically.
- Triage by severity (Critical/High now, Medium today, Low weekly) instead of newest-first.
- Route findings to EventBridge on day one so a human actually sees them.
- Use suppression rules with documented reasons and expiry dates — never silent ignoring.
- Validate every finding against CloudTrail before calling it an incident.
- Turn on the extra protection plans selectively and review them quarterly.