L14. Amazon GuardDuty: Threat Detection Fundamentals

Agentless by Design

Amazon GuardDuty is a managed threat detection service that continuously analyzes existing log sources rather than requiring you to deploy or manage any agents. It ingests CloudTrail management and S3 data events, VPC Flow Logs, DNS query logs, EKS audit logs, RDS login activity, and Lambda network activity. Because it works off logs and API activity AWS already generates, enabling GuardDuty is a control-plane setting, not a fleet-wide software rollout, which is exactly why it shows up so often in exam scenarios about detection at scale with minimal operational overhead.

How Findings Get Generated

GuardDuty combines three techniques to produce findings: machine learning models trained on known attack patterns, anomaly detection against a baseline of normal account behavior, and integrated threat intelligence feeds (including AWS-curated lists and feeds from partners) that flag known-malicious IPs and domains. Every finding carries a severity rating of low, medium, or high, which lets a SOC triage a flood of findings by impact instead of reading each one individually. A high-severity finding might indicate an EC2 instance communicating with a command-and-control server; a low-severity finding might just be a port scan against an instance that never responded.

Centralized, Org-Wide Management

GuardDuty is enabled on a per-account basis, but it does not have to be managed account by account. A delegated administrator account, designated at the AWS Organizations level, can centrally configure GuardDuty for every member account, including automatically enabling it for accounts that join the organization later. Member accounts inherit that configuration without an administrator having to log into each one separately, which is the pattern the exam expects for any multi-account GuardDuty question.

Acting on Findings Automatically

GuardDuty findings are published as events to Amazon EventBridge, and an EventBridge rule can match on finding type or severity to trigger an automated response: a Lambda function that revokes credentials or isolates a resource, a Step Functions workflow for a multi-step playbook, or an SNS notification that pages the on-call team. This finding-to-EventBridge-to-response pattern is the backbone of automated remediation across GuardDuty and Security Hub alike.

Optional Protection Plans

GuardDuty's core analysis is free of extra configuration, but five optional protection plans extend coverage into specific services:

Malware Protection deserves special attention: it does not scan everything continuously. It triggers a scan of the EBS volumes attached to an EC2 instance or container workload specifically after GuardDuty has already flagged that resource as potentially compromised through another finding, giving responders malware evidence without them having to snapshot and scan manually. Exam tip: If a scenario says "no agents" and "across many accounts" in the same sentence, GuardDuty with a delegated administrator is almost always the intended answer.