Amazon GuardDuty Explained: Data Sources, Protection Plans, Extended Threat Detection and Org-Wide Rollout

Amazon GuardDuty is the threat detection service most AWS customers turn on first. It needs no agents for its core detections and no log pipeline of your own. Interview questions about it usually test cloud detection in general: what it can see, what it cannot, and how you would run it across hundreds of accounts.

What it is

GuardDuty is a regional, managed threat detection service. It analyses AWS data sources with threat intelligence and machine learning and produces findings about likely malicious activity: compromised credentials, crypto-mining, data exfiltration, reconnaissance, malware and more.

Foundational data sources are on by default:

• CloudTrail management events
• VPC Flow Logs
• Route 53 Resolver DNS query logs

GuardDuty reads them through its own duplicated streams, so you do not need to enable trails or flow logs for it.

Protection plans add coverage:

• S3 Protection
• EKS Protection (Kubernetes audit logs)
• Runtime Monitoring, an agent for EKS, ECS on Fargate and EC2
• Malware Protection for EC2, for S3 and for AWS Backup
• RDS Protection and Lambda Protection
• AI Protection, added in July 2026 for Amazon Bedrock and SageMaker AI

How it works

Finding types follow a pattern: ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact. For example, Recon:EC2/PortProbeUnprotectedPort or CryptoCurrency:EC2/BitcoinTool.B!DNS. Severity runs from Low (1.0 to 3.9) to Critical (9.0 to 10.0).

Extended Threat Detection, launched in December 2024, is on by default at no extra cost. It correlates findings and weaker API signals over a 24-hour window into attack sequence findings such as AttackSequence:IAM/CompromisedCredentials or AttackSequence:S3/CompromisedData, and later sequences for EKS, EC2 instance groups and ECS clusters. Every attack sequence finding is Critical.

Runtime Monitoring uses a GuardDuty security agent (on EKS, the aws-guardduty-agent add-on) that observes process execution, file access and network connections using eBPF and related kernel features.

How to use it

Day one: enable it across the organisation

# From the management account, in each Region you use
aws guardduty enable-organization-admin-account \
    --admin-account-id 111122223333 --region eu-west-1

Then, from the delegated administrator account, set auto-enable for all member accounts (--auto-enable-organization-members=ALL) and choose which protection plans to auto-enable. Use the same delegated administrator in every Region, and do not use the management account for it. Enable GuardDuty in every Region, including those you do not use: attackers like quiet Regions, and global service events are only analysed where GuardDuty runs.

Week one: route findings and learn the baseline

1. Send findings to EventBridge (source aws.guardduty) for alerting and automation. New findings arrive in near real time; repeat occurrences are aggregated every six hours by default, which you can shorten to 15 minutes.
2. Integrate with Security Hub (now called Security Hub CSPM in AWS documentation) or your SIEM so cloud findings sit next to the rest of your alerts.
3. Generate sample findings to test the pipeline end to end before a real one arrives.
4. Check DNS coverage: if your instances use your own resolvers, GuardDuty's DNS-based detections are blind.

Every day: tune without blinding it

• Suppression rules archive new matching findings automatically. Write them narrowly and reactively for known benign patterns, such as port-scan findings from your own vulnerability scanner or SSH brute-force findings on a bastion that is meant to be internet-facing. Remember that suppressed findings no longer feed Extended Threat Detection.
• Entity lists (recommended since August 2025) mark trusted or threat IPs, domains and file hashes. Trusted entries win over threat entries, and lists only apply to public addresses.
• Investigate with finding details, Amazon Detective, or the GuardDuty Investigation feature (in preview since June 2026), and follow AWS's remediation guide for the resource type.

Where it stops

• Regional. It must be enabled and administered Region by Region.
• DNS blind spot with non-AWS resolvers.
• Runtime gaps. Runtime Monitoring does not cover EKS on Fargate or EKS Hybrid Nodes.
• Detection, not prevention. It tells you something happened; containment is your automation or your responders.
• No raw logs. For investigations you still need your own CloudTrail, flow logs and DNS logs retained.

How it comes up in interviews

• "GuardDuty fires UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration. What do you do?" Scope the role, revoke sessions, find the source, check what the credentials did.
• "Roll out GuardDuty to 300 accounts." Delegated administrator, all Regions, auto-enable, routing, sample findings, and narrow suppression.
• "What can GuardDuty not see?" Application-level abuse, DNS through your own resolvers, data access without S3 Protection, and anything outside AWS.

Sources

Checked on 13 November 2026: Amazon GuardDuty User Guide pages on what GuardDuty is, foundational data sources, finding format, finding severity, Extended Threat Detection and attack sequence finding types, Runtime Monitoring (including EKS and kernel support), managing accounts with AWS Organizations and designating a delegated administrator, auto-enable preferences, EventBridge and Security Hub integration, suppression rules, entity and IP lists, and the document history.