GuardDuty

Amazon GuardDuty is a managed threat detection service that continuously analyzes data from CloudTrail management and data events, VPC Flow Logs, DNS logs, EKS audit logs, and S3 data events to identify malicious or unauthorized activity.

What GuardDuty Detects

• Compromised credentials: API calls from unusual locations or known malicious IPs
• Crypto mining: EC2 instances communicating with mining pools
• Data exfiltration: unusual S3 access patterns or DNS tunneling
• Privilege escalation: anomalous IAM activity
• Malware: EBS volume scanning for known threats
• Multi-stage attack sequences: Extended Threat Detection (ETD) correlates events across EC2, ECS, and EKS into attack timelines

How GuardDuty Is Structured

When you enable GuardDuty, it automatically starts ingesting the foundational data sources for the account: CloudTrail management events, VPC Flow Logs, and DNS logs. You do not need to enable those logs yourself, and GuardDuty's consumption of them is independent of whether you deliver them anywhere else. On top of that sit optional protection plans: S3 Protection, EKS Protection, RDS Protection, Malware Protection, Lambda Protection, Runtime Monitoring (EC2, EKS, and ECS on Fargate), and AI Protection for Bedrock and SageMaker CloudTrail data events. Extended Threat Detection is enabled automatically at no extra cost. First-time activation starts a 30-day free trial that includes all protection plans except Runtime Monitoring.

Findings are retained for 90 days, published to EventBridge in near real time for automation, and can be aggregated across an organization by designating a delegated administrator account via AWS Organizations, which is the sane way to run it at any scale beyond one account.

How It Goes Wrong in Practice

The most common operational failure is not a detection gap but a coverage gap. GuardDuty is enabled per Region, and attackers know that defenders concentrate on the Regions they use. A standard pattern after credential theft is to pivot to an unused Region, spin up compute for cryptomining or staging there, and operate where no detector exists. If you enable GuardDuty at all, enable it in every Region and enforce that through your Organizations setup rather than by hand.

The second failure mode is alerting without response. GuardDuty generates a finding such as unusual API activity or an instance querying a known mining pool domain, the finding sits in the console, and nobody is routing it to a human or an automation. Teams discover weeks of high-severity findings during a post-incident review. Findings need a path out: an EventBridge rule to a ticketing system, a chat channel, or an auto-containment Lambda for well-understood finding types. And be careful with suppression rules: findings that a suppression rule auto-archives are not sent to EventBridge at all, so an overly broad suppression filter silently disconnects your response pipeline.

Practical Check: Confirm Coverage and Pull High-Severity Findings

Verify a detector exists in the Region you are auditing:

aws guardduty list-detectors

An empty DetectorIds list means GuardDuty is not enabled there. With the detector ID, list findings at severity 7 and above (high and critical):

aws guardduty list-findings --detector-id 12abc34d567e8fa901bc2d34eexample --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'

Run the list-detectors check across all Regions in a loop; it is the fastest possible audit of your threat detection coverage.

Frequently Asked Questions

Does GuardDuty require agents or log configuration?

The foundational detection requires nothing: no agents, and no need to enable CloudTrail, VPC Flow Logs, or DNS logging yourself. The exception is Runtime Monitoring, which uses a security agent to observe OS-level behavior on EC2, EKS, and ECS-Fargate workloads.

Can GuardDuty block attacks?

No. GuardDuty is detection only; it generates findings and publishes them to EventBridge. Prevention and containment are your job, typically via EventBridge-triggered automation or an on-call runbook.

How do I manage GuardDuty across many accounts?

Use AWS Organizations and designate a delegated GuardDuty administrator account. Findings from member accounts are visible centrally, and EventBridge rules in the administrator account fire on member account findings, so response automation lives in one place.

Is there a way to test findings safely?

Yes. GuardDuty can generate sample findings from the console or API so you can validate your alert routing, and AWS provides tester scripts that trigger specific finding types in a dedicated account. Rehearsing the full path from sample finding to paged human is the cheapest security exercise you will ever run.