Amazon GuardDuty
GuardDuty is a managed threat-detection service. It continuously analyzes your AWS activity — VPC Flow Logs, CloudTrail events, DNS queries, EKS audit logs — and uses machine learning, anomaly detection, and threat-intelligence feeds to flag suspicious behavior, raising a finding with a severity and enough context to investigate.
Its headline value is that it works without any agents on your hosts for core sources: you enable it, and AWS reads the logs it already has and applies its detection models — close to the zero-config it is marketed as.
What GuardDuty Watches
Foundational sources, on once you enable the service, are CloudTrail management events, VPC Flow Logs, and Route 53 DNS query logs. Protection plans are paid opt-ins that add more sources: S3 Protection (CloudTrail S3 data events), EKS Protection, Malware Protection for EC2 and S3, RDS Protection, Lambda Protection, and Runtime Monitoring (which adds an agent for deep EC2/ECS visibility).
Most accounts start with core only and add protection plans matching their workload.
Findings
Each finding has a type (like CredentialAccess:IAMUser/AnomalousBehavior), a severity (Low/Medium/High), a target resource, and a threat actor when known. Common categories include reconnaissance, backdoor/command-and-control, cryptomining, anomalous credential use, privilege escalation, and exfiltration.
Findings flow to the console, to EventBridge for alerting and automation, and optionally to Security Hub for cross-service aggregation.
Multi-Account Setup
With AWS Organizations, a delegated administrator account enables GuardDuty across every member account, sees all findings in one console, and applies one configuration. Running it in only some accounts means an attacker who pivots through your less-monitored accounts stays invisible.
GuardDuty — active threat detection from logs — what is happening that looks malicious right now.
AWS Config — configuration posture and compliance — what is configured and whether it meets rules.
Security Hub — aggregation — pulling GuardDuty, Config, and other findings into one scored view.
- Enabling GuardDuty only in the Regions you actively use — unused Regions are free hiding spots for an attacker.
- Assuming someone watches the console instead of routing Medium/High findings to EventBridge for real alerts.
- Ignoring or muting noise instead of writing suppression rules, so genuine findings get lost.
- Triaging High-severity findings in days rather than hours — they are usually genuine.
- Expecting GuardDuty to cover application-layer security or compliance — it watches AWS API and network activity, not your code or posture.
- Running it per-account without a delegated administrator, fragmenting visibility across the organization.
- Enable GuardDuty in every Region of every account.
- Set a delegated administrator via Organizations and centralize findings.
- Route findings to EventBridge and alert on Medium and High severity.
- Suppress known false positives with rules instead of ignoring the console.
- Forward findings to Security Hub to combine with other security services.
- Enable the protection plans that match your workload (EKS, RDS, S3 malware).
Knowledge Check
How does GuardDuty detect threats?
- It analyzes logs AWS already has (CloudTrail, VPC Flow Logs, DNS) with ML and threat intel — core sources need no agents
- It installs a kernel-level monitoring agent onto every EC2 instance in the account automatically the moment you first enable it
- It scans your application source code and its dependencies for known CVEs during each build
- It requires you to author and maintain your own custom detection rules and threat signatures
Why enable GuardDuty in Regions you do not actively use?
- Attackers do not care which Region you use; an unmonitored Region is a free place to operate undetected
- To reduce the per-Region analysis cost by qualifying the whole account for bulk volume pricing tiers across Regions
- Because GuardDuty findings only ever surface in Regions that carry no production workloads
- It is a hard prerequisite that must be enabled in unused Regions before any active Region
Where should GuardDuty findings go for reliable response?
- To EventBridge for alerting and automation (and Security Hub for aggregation) — not left for someone to watch in the console
- Only into the GuardDuty console, where a designated on-call engineer can periodically refresh the page and review the list of findings by hand
- Into the application's own production database table for the dev team to query alongside business data
- To the root account's email inbox exclusively, as the single notification channel for every finding
What is GuardDuty NOT designed to do?
- Assess compliance posture or test application-layer code — use Config/Security Hub and app-layer testing for those
- Detect cryptomining traffic leaving compromised instances by inspecting their outbound DNS lookups and network flow patterns
- Flag anomalous IAM credential use, such as access keys suddenly calling from an unfamiliar location
- Detect reconnaissance port scans probing your instances from suspicious external source addresses
You got correct