Amazon GuardDuty
Continuous, ML-driven threat detection across CloudTrail, VPC Flow Logs, DNS logs, and runtime telemetry — agentless for foundational coverage, extensible via protection plans. This module pairs deep "how it actually works" understanding with the exam-reasoning layer the Security Specialty exam tests.
Detective — primary role
Responsive — via EventBridge
Governance — org auto-enable
90 days
Finding retention (inactive)
30 days
Free trial on enable
Severity Scale — Memorize This
LOWRoutine, low confidence
MEDIUMSuspicious activity
HIGHLikely compromise
CRITICALETD attack sequence only
How GuardDuty Actually Works
The Core Mechanism — Not Just "It Reads Logs"
- Direct internal access — GuardDuty reads CloudTrail management events, VPC Flow Logs, and DNS query logs straight from AWS's own telemetry pipeline. You never configure these sources yourself, and disabling your own CloudTrail trail does not blind GuardDuty.
- Baseline modeling — for each account and resource, GuardDuty's ML builds a behavioral baseline: typical API call patterns, typical network destinations, typical login times/locations/instance types calling certain APIs. Findings fire when activity deviates from that baseline.
- Two detection modes working together — signature-based (matches against AWS's curated threat-intelligence feeds of known-malicious IPs/domains — fast, high-confidence) and anomaly-based (ML deviation from the account's own learned baseline — catches novel behavior, but needs time to "learn" what's normal for a new account).
- Protection plans extend the input surface, not a separate detection engine — S3/EKS/Lambda/RDS/Runtime telemetry simply becomes additional signal feeding the same correlation and ML systems that already evaluate CloudTrail/Flow Logs/DNS.
⚠️ The Recurring Exam Theme
Nearly every GuardDuty question tests one of three things: (1) do you know GuardDuty is detective only and needs EventBridge for any "response"/"remediation" requirement, (2) can you pick the right protection plan for a described signal, or (3) can you distinguish GuardDuty from Inspector, Macie, Config, CloudTrail Insights, and Detective — five services that sound similar but answer fundamentally different questions.
Exam Domain Mapping
| Domain | Where GuardDuty Shows Up |
|---|
| Threat Detection & Incident Response | The centerpiece — finding types, severity model, Extended Threat Detection attack sequences, EventBridge-driven automated response |
| Security Logging & Monitoring | Foundational data sources, Security Hub aggregation, multi-account finding consolidation |
| Identity & Access Management | Credential-compromise findings, STS session remediation, delegated administrator model |
| Data Protection | S3 Protection, RDS Protection, Malware Protection scope and limits |
| Management & Security Governance | Organizations auto-enable, per-region configuration, cross-account cost and protection-plan management |
Exact percentages shift slightly between exam guide revisions — GuardDuty consistently sits inside the most heavily-weighted domains regardless of version, so it's worth prioritizing.
Decision Tree — Mental Model
Threat
Unauthorized/anomalous behavior, compromised credentials, malware, malicious network/DNS activity, suspicious DB logins, container/runtime compromise
↓
Security Goal
Continuously detect this without deploying my own SIEM/log analysis pipeline
↓
AWS Service
Amazon GuardDuty
Foundational (always on)
+ S3 Protection
+ EKS Protection / Runtime
+ EC2/ECS Runtime Monitoring
+ Malware Protection
+ Lambda Protection
+ RDS Protection
Extended Threat Detection (auto)
↓
Implementation
Enable via Organizations delegated administrator (dedicated security account). Auto-enable for all current + future accounts, all regions. Select protection plans per workload.
↓
Monitoring
Findings → Security Hub (aggregation/scoring). Findings → EventBridge (routing). High/Critical → Detective (investigation).
↓
Remediation
EventBridge rule → Lambda/SSM Automation: isolate instance, revoke/rotate IAM credentials or STS sessions, notify SOC, or SCP-based account isolation for severe compromise.
Final Summary
Must Memorize
- 4 severity levels — Critical = ETD Attack Sequence only
- Protection plan ↔ scenario mapping (S3/EKS/EC2-ECS/Malware/Lambda/RDS)
- GuardDuty = detective, never "blocks" or "prevents"
- Foundational sources need no manual log setup
- Suppression ≠ cost reduction; Trusted IP list ≠ network control
Must Understand
- How ETD correlates discrete findings into attack-sequence narratives
- The EventBridge-driven automated remediation pattern
- The distinction triangle: GuardDuty (behavior) vs Inspector (vulnerabilities) vs Macie (sensitive data) vs Config (config state)
- STS temporary credentials vs IAM access keys for remediation
Can De-prioritize
- Exact dollar pricing figures
- Console UI navigation specifics
- Historical finding-type string names — focus on categories
Exam appearance probability: HIGH
Protection Plans & Capabilities
Foundational detection is always-on; everything else below is an opt-in protection plan that widens GuardDuty's signal surface.
2.1 Foundational Data Sources Frequently misunderstood
PurposeBaseline threat detection from control-plane & network metadata
SourcesCloudTrail mgmt events, VPC Flow Logs, DNS query logs
- GuardDuty has direct internal access — you do NOT need to enable CloudTrail, VPC Flow Logs, or Route 53 resolver logging yourself.
- Limitation: S3 and Lambda data events require their specific protection plans — foundational tier doesn't cover them.
- Exam relevance: many candidates assume manual log enablement is a prerequisite. It isn't.
2.2 S3 Protection High exam relevance
PurposeDetect threats to S3 data
HowAnalyzes S3 data-event logs even without your own trail enabled
- Use case: anomalous
GetObject patterns suggesting exfiltration, unusual permission changes on buckets.
- Trap: distinguishing this from Macie — Macie classifies what data exists; S3 Protection flags anomalous access.
2.3 EKS Protection (Audit + Runtime) High exam relevance
EKS ProtectionAnalyzes EKS audit logs for suspicious API activity
Runtime MonitoringAgent-based — inspects process/file/network inside pods
- Audit log analysis alone won't catch in-container malware execution — that needs Runtime Monitoring.
- "Detect a malicious process running inside a container" → Runtime Monitoring, not just EKS Protection.
2.4 EC2/ECS Runtime Monitoring Recently changed
PurposeDetect runtime threats — process execution, file access, network connections
DeploymentLightweight agent, automatic agent configuration via SSM / launch integration
- Use case: detect a reverse shell or crypto-mining process spawned on a compromised instance.
- Runtime Monitoring ≠ Malware Protection — different mechanisms, complementary (see 2.5).
2.5 Malware Protection (EC2/EBS & S3) Medium-high
EC2 variantFinding-triggered EBS snapshot scan — not continuous
S3 variantScans new objects on PUT — not retroactive by default
- When a finding suggests an EC2 instance may be compromised, GuardDuty auto-snapshots attached EBS volumes and scans for malware.
- Know it's event-triggered, not a constant AV agent.
2.6 Lambda Protection Medium
PurposeDetect malicious activity from Lambda network traffic
HowAnalyzes function network activity logs
- Use case: function connecting to known crypto-mining endpoints or malicious IPs.
- Often the right answer for "serverless + outbound traffic to a malicious domain."
2.7 RDS Protection Medium
PurposeDetect suspicious login activity against Aurora/RDS
CoverageAurora (MySQL/PostgreSQL-compatible) and RDS login events
- Keyword "suspicious database login attempts" → RDS Protection.
2.8 Extended Threat Detection (ETD) High — exam-fresh
WhatCorrelates lower-severity findings into one Critical Attack Sequence finding
CostAutomatically enabled, no extra cost
- e.g. credential compromise → privilege escalation → exfiltration shown as ONE incident.
- Coverage spans IAM/credential sequences,
AttackSequence:EKS/CompromisedCluster, AttackSequence:EC2/CompromisedInstanceGroup, AttackSequence:ECS/CompromisedCluster.
- Includes MITRE ATT&CK mapping, incident summary, remediation guidance; can pull exposure/vulnerability context from Security Hub (Inspector findings).
- "Multi-stage attack narrative + single consolidated finding + MITRE ATT&CK" → ETD, not Security Hub, not Detective.
2.9 Threat Lists, Trusted IP Lists & Entity Lists Medium
Threat ListKnown-bad IPs/domains → generates findings on match
Trusted IP ListKnown-good IPs → suppresses findings for that IP only
Entity ListExtends to domains; can trigger Impact:EC2/MaliciousDomainRequest.Custom or suppress
- Limitation: Trusted IP lists don't disable the detection logic itself — only suppress findings for that specific IP.
- "Authorized scanner IP causing false positives" → Trusted IP list, not a suppression rule.
2.10 Suppression Rules High-trap
PurposeAuto-archive findings matching defined criteria
HowFilter-based, supports Matches/NotMatches with wildcards
- Does not stop billing — GuardDuty still analyzed the underlying data; only the finding's visibility changes.
- Suppressed findings are excluded from ETD sequencing — don't over-suppress signals that matter for correlation.
2.11 Multi-Account Management (Organizations) High exam relevance
ModelDelegated administrator — dedicated security-tooling account, not management
CapabilityAuto-enable GuardDuty + protection plans for all current and future member accounts
- "Ensure GuardDuty is automatically enabled for every new account" → Organizations + delegated admin + auto-enable.
AWS Exam Thinking
Requirement → Keywords → Expected Answer → why every distractor fails.
Detect compromised credentials / anomalous API behavior
anomalous activitycredential compromiseno agent
Expected AnswerAmazon GuardDuty
| Distractor | Why it's wrong |
|---|
CloudTrail | Only logs events — no analysis |
Config | Checks configuration state, not behavior |
CloudWatch | Needs custom metrics/alarms you'd build yourself |
Detect malware on a compromised EC2 instance
malwarescan EBS volumecompromised instance
Expected AnswerGuardDuty Malware Protection (EC2)
| Distractor | Why it's wrong |
|---|
Inspector | Scans for vulnerabilities/CVEs, not active malware |
Macie | S3 data-classification only |
Systems Manager | No native malware engine |
Multi-stage attack narrative (recon → priv-esc → exfiltration)
attack sequenceMITRE ATT&CKcritical severity
Expected AnswerGuardDuty Extended Threat Detection (Attack Sequence finding)
| Distractor | Why it's wrong |
|---|
Security Hub | Aggregates findings but doesn't generate the correlated narrative itself |
Detective | Reactive/manual investigation, not an automatic finding |
| Individual findings | These are the inputs to ETD, not the answer |
Anomalous S3 access pattern suggesting exfiltration
unusual GetObjectdata exfiltration
Expected AnswerGuardDuty S3 Protection
| Distractor | Why it's wrong |
|---|
Macie | Finds what sensitive data exists, not who's anomalously accessing it |
| S3 Access Logs + Athena | You'd have to build the detection logic yourself |
CloudTrail | Raw logs only |
Malicious process / reverse shell on EC2 or container
runtime behaviorin-memoryreverse shell
Expected AnswerGuardDuty Runtime Monitoring
| Distractor | Why it's wrong |
|---|
| Foundational GuardDuty | No OS-level visibility |
Inspector | Pre-deployment vulnerability scanning, not live behavior |
Config | Configuration drift, not runtime |
Suspicious database login pattern
RDS / Auroraanomalous login
Expected AnswerGuardDuty RDS Protection
| Distractor | Why it's wrong |
|---|
CloudTrail / VPC Flow Logs / CloudWatch Logs | None natively classify "anomalous" vs "normal" login behavior — that's GuardDuty's ML job |
Suppress findings from your own authorized scanner
known scanner IPreduce false positives
Expected AnswerTrusted IP list
| Distractor | Why it's wrong |
|---|
| Suppression rule | Broader/criteria-based, and excludes findings from ETD; not the cleanest match for "a known good IP" |
| IAM policy | Irrelevant to GuardDuty findings |
| Disable GuardDuty | Removes all detection, not targeted |
GuardDuty enabled automatically for every new account
organization-widecentralized findings
Expected AnswerOrganizations delegated administrator + auto-enable
| Distractor | Why it's wrong |
|---|
| Manual per-account enablement | Doesn't scale, won't cover future accounts |
| CloudFormation StackSets only | Can help deploy, but isn't the GuardDuty-native mechanism the exam wants |
| Config aggregator | Unrelated to GuardDuty |
Security Controls Mapping & Integrations
4 — Controls Mapping
Detective
Finding generation across all protection plans — e.g. UnauthorizedAccess:EC2/SSHBruteForce, Recon:IAMUser/MaliciousIPCaller
Detective (advanced)
Extended Threat Detection attack sequences — e.g. AttackSequence:IAM/CompromisedCredentials
Responsive (via integration, not native)
EventBridge → Lambda/SSM Automation triggered by a finding — e.g. auto-quarantine an EC2 instance (isolated SG, removed from target group) when UnauthorizedAccess:EC2/MaliciousIPCaller.Custom fires
Remediation (via integration)
Lambda revokes temporary IAM credentials triggered by UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration — calls iam:DeleteAccessKey or attaches a deny-all policy
Governance
Org-wide auto-enable, delegated administrator, mandatory protection plans via Control Tower/Organizations — new account → GuardDuty enabled within minutes, findings flow to central security account
⚠️ GuardDuty is NOT preventive
It never blocks an API call or network connection. Questions implying GuardDuty "stops" something are testing whether you know it's detection-only.
5 — Integrations
Security Hub
WhatFindings flow automatically (ASFF format) once Security Hub is enabled
WhyCentralized cross-service aggregation alongside Inspector, Macie, Config, Access Analyzer
PatternGuardDuty → Security Hub → EventBridge → ticketing/SOAR
EventBridge
WhatEvery finding generates an EventBridge event
WhyThe automation backbone — auto-remediation without polling
PatternFinding → rule (filter severity/type) → Lambda or Step Functions
Organizations
WhatDelegated administrator model
WhyCentralized ops without granting management account direct security tooling access
PatternManagement delegates → security account auto-enables for all current + future members
Amazon Detective
WhatOne-click "Investigate" pivots into Detective's behavior graph
WhyGuardDuty says something happened; Detective shows what else happened around it
PatternFinding (alert) → Detective (root-cause) → response
IAM
WhatService-linked role grants read access to log sources
WhyLeast-privilege access without manually wiring log permissions
S3, EKS, EC2/EBS, ECS, Lambda, RDS
WhatEach protection plan integrates with the relevant service's logs/runtime
WhyTailor detection breadth to actual workload footprint
Costs, Limits & Quotas
Pricing Model
BasePay-as-you-go, 30-day free trial on enable
FoundationalPer GB of CloudTrail / Flow Logs / DNS logs analyzed
S3 ProtectionPer number of S3 data events analyzed
EKS ProtectionPer audit log volume (+ separate Runtime Monitoring vCPU-hour pricing)
Runtime MonitoringPer vCPU-hour of monitored compute
Malware ProtectionPer GB scanned (EBS snapshots / S3 objects)
RDS / Lambda ProtectionPer data volume analyzed
Common Cost Mistakes
- Enabling S3 Protection in accounts with very high S3 API volume without estimating data-event cost first
- Enabling Runtime Monitoring broadly across large fleets without considering vCPU-hour accumulation
- Assuming suppression rules reduce cost — they don't, data is still analyzed and billed
- GuardDuty is regional — enabling it everywhere multiplies cost across regions, even unused ones (also a security best practice, so it's a cost/security tradeoff)
Cost Optimization
- Use the 30-day trial + estimator before org-wide rollout
- Enable protection plans selectively per account based on actual workload
- Centralize via delegated admin for consolidated cost visibility
⚠️ Exam angle
A question contrasting "reduce noise" vs "reduce cost" is testing whether you know suppression addresses noise only.
Limits & Quotas
ScopeRegional service — enable per-region explicitly
Finding retentionActive findings retained/updated 90 days of inactivity before archival
Delegated adminOnly one per organization
Trusted IP listsSmall fixed cap per account — curated, not a general allow-list
Threat/Entity listsAlso count-limited per account
Member accountsAligns with Organizations limits (thousands via delegated admin)
Scaling Considerations
- New org accounts with auto-enable configured get GuardDuty (+ selected protection plans) automatically
- Runtime Monitoring rollout at scale uses SSM Fleet Manager / EKS add-ons, not manual install
⚠️ Regional trap
Findings, suppression rules, threat lists, and trusted IP lists are all per-region. A suppression rule created in us-east-1 does not apply to findings generated in eu-west-1 — and (see Quiz, Specialty Q8) the org auto-enable configuration itself is also per-region.