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, namely CloudTrail, VPC Flow Logs, and DNS, with ML and threat intelligence
- 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 third-party dependencies for known CVEs on every build
- It requires you to author and maintain your own custom detection rules and threat signatures for every account and Region
Why enable GuardDuty in Regions you do not actively use?
- Attackers do not care which Region you normally use; an unmonitored Region is a free place for them 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 of their own
- It is a hard prerequisite that must be enabled in every unused Region before any active Region
Where should GuardDuty findings go for reliable response?
- To EventBridge for alerting and automation, with Security Hub aggregating them alongside the other findings
- 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 across the account, or test application-layer code for vulnerabilities
- 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 that suddenly start calling from an unfamiliar location or network
- Detect reconnaissance port scans that probe your instances from suspicious external source addresses on the internet
You got correct