Amazon GuardDuty

Amazon GuardDuty is a threat detection service. It continuously analyses log and event data from an AWS account against threat intelligence feeds and machine learning models, and raises a finding when it sees behaviour that indicates compromise. It consumes its data sources through independent, duplicate streams — there is nothing to configure in CloudTrail or VPC Flow Logs to make it work, and enabling GuardDuty does not change existing logging.

Foundational data sources

Three sources are ingested automatically and at no additional charge as soon as GuardDuty is enabled in a Region:

• AWS CloudTrail management events — control-plane activity such as AttachRolePolicy, CreateSubnet or CreateTrail.
• VPC Flow Logs — IP traffic to and from network interfaces on EC2 instances.
• Route 53 Resolver DNS query logs — available only when instances use the AWS-provided DNS resolver. Instances configured with an external resolver produce no DNS data for GuardDuty.

CloudFront access logs are not a GuardDuty data source. CloudFront, IAM, STS, S3 and Route 53 are global services whose CloudTrail events are recorded in one Region; GuardDuty replicates those events into every Region where it is enabled, which is why enabling it everywhere — including Regions with no workloads — is the recommendation.

What it looks for

• Credentials used from an unusual location, from an anonymising network, or in a way that departs from the learned baseline for that principal
• Calls from IP addresses and domains on threat intelligence feeds
• Attempts to disable CloudTrail logging or otherwise cover tracks
• Reconnaissance: port scanning, unusual API enumeration, repeated failed sign-ins
• Cryptomining and command-and-control traffic from instances and containers

Protection plans

Beyond the foundational sources, GuardDuty offers optional, chargeable protection plans that bring in further log and event sources:

• S3 Protection — CloudTrail S3 data events
• EKS Protection — Amazon EKS audit logs
• Runtime Monitoring — operating-system, network and file events from EC2 instances, EKS clusters and ECS on Fargate, via a security agent
• Malware Protection for EC2 — scans EBS volumes attached to an instance with a suspicious finding
• Malware Protection for S3 — scans newly uploaded objects; this one can be used on its own, without enabling the rest of GuardDuty
• RDS Protection — login activity on supported Amazon Aurora and Amazon RDS engines
• Lambda Protection — Lambda network activity logs
• AI Protection — CloudTrail data events from Amazon Bedrock and Amazon SageMaker AI

Extended Threat Detection is enabled automatically at no extra cost. It looks across data sources, resource types and time for sequences of individually unremarkable events that together form an attack, and raises an attack-sequence finding.

Responding to findings

Findings appear in the GuardDuty console and are emitted to Amazon EventBridge, and they can be forwarded to AWS Security Hub CSPM. EventBridge is the hook for automation: a rule filters the finding types that matter and invokes a Lambda function or an AWS Step Functions workflow.

flowchart LR subgraph Sources["Data sources"] CT[(CloudTrail management events)] VPC[(VPC Flow Logs)] DNS[(Route 53 Resolver DNS query logs)] Plans[(Optional protection plans)] end CT & VPC & DNS & Plans --> GD[Amazon GuardDuty] GD -->|Findings| EB[Amazon EventBridge] GD -->|Findings| SH[AWS Security Hub CSPM] EB -->|Notification| SNS[SNS topic] EB -->|Orchestration| SF[Step Functions] EB -->|Custom logic| Lambda[Lambda] SH --> SEC([Security team]) SNS --> Chat([Chat or email]) SF --> Auto([Automated remediation])

A Step Functions workflow triggered from a finding typically does some combination of: isolating a compromised EC2 instance by moving it to a quarantine security group, revoking the session credentials of the principal involved, snapshotting volumes for forensics, adding an address to a network ACL deny list, notifying the security team, and opening a ticket.