If the AWS Certified Security – Specialty (SCS-C02) exam has a “default answer” for the question “how do you detect malicious or unauthorized activity across your accounts?”, that answer is Amazon GuardDuty. It appears throughout the Threat Detection and Incident Response domain, and understanding it in depth is one of the highest-return investments you can make in your prep. The broad threat detection and incident response guide surveys GuardDuty alongside Security Hub, Detective, Macie, and Inspector; this article zooms all the way in on GuardDuty itself — how it works, what it can and cannot see, and how the exam expects you to wire it into an automated response pipeline.
This is a single-service deep dive aimed at the Threat Detection domain of the SCS-C02. If you are still mapping out the whole exam, start with the SCS-C02 exam guide for 2026 and come back here for the detection layer.
What GuardDuty Is — and What It Is Not
Amazon GuardDuty is a managed threat detection service. You enable it, and it continuously analyzes activity in your AWS environment to surface findings that indicate compromise, reconnaissance, or misconfiguration-driven abuse. Three properties define it, and each maps to an exam trap:
- It is agentless for its foundational sources. GuardDuty reads AWS-native telemetry directly — you do not install anything or ship logs to it. (Runtime Monitoring is the exception, discussed below.)
- It does not require you to enable or store the underlying logs. GuardDuty consumes an independent, duplicate stream of VPC Flow Logs, DNS logs, and CloudTrail events. You do not have to turn on VPC Flow Logs or a CloudTrail trail for GuardDuty to analyze them, and enabling GuardDuty does not add to your CloudTrail/Flow Log bills. This is a favorite exam distinction.
- It is detective, not preventive. GuardDuty tells you something happened; it does not block it. Prevention lives in security groups, WAF, SCPs, and IAM. When a question asks you to stop traffic, GuardDuty is the wrong single answer — but it is the right trigger for an automated preventive action.
If you keep those three straight, you have already avoided the most common GuardDuty questions people get wrong.
The Data Sources: What GuardDuty Actually Analyzes
GuardDuty’s foundational detection draws on three always-on data sources plus a set of optional protection plans layered on top. Start with the foundational three:
| Data source | What it reveals |
|---|---|
| VPC Flow Logs | Unusual network traffic — connections to known-bad IPs, port scanning, cryptomining traffic, data exfiltration volumes |
| DNS logs | Queries to malicious domains, DGA (domain generation algorithm) patterns, DNS data exfiltration |
| CloudTrail management events | Suspicious API calls — disabled logging, credential exfiltration, unusual AssumeRole patterns, reconnaissance |
Two points the exam leans on. First, GuardDuty analyzes CloudTrail management events by default; CloudTrail S3 data events and EKS audit logs are analyzed only when you enable the corresponding protection plans. Second, GuardDuty uses threat intelligence feeds (AWS-curated plus third-party) and machine-learning baselines of normal behavior in your account — so a finding can fire either because an IP is on a known-bad list or because behavior deviates from your learned baseline.
The Anatomy of a Finding
Every GuardDuty detection is a finding, and the exam expects you to read one fluently. Finding types follow a consistent, decodable format:
ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!ArtifactFor example, UnauthorizedAccess:EC2/MaliciousIPCaller.Custom means an EC2 instance was contacted by an IP on your custom threat list, under the “unauthorized access” threat purpose. Learn the threat purposes — they tell you what stage of an attack you are looking at:
| Threat purpose | Meaning |
|---|---|
Recon | Reconnaissance — scanning, enumeration |
UnauthorizedAccess | Access from a suspicious source |
Discovery | Attacker exploring resources/permissions |
Exfiltration | Data being pulled out |
Impact | Destructive or abusive action (e.g., cryptomining) |
CryptoCurrency | Cryptomining activity |
Trojan, Backdoor | Malware communication patterns |
PenTest, Policy | Pen-testing tools or policy violations |
Each finding carries a severity on a 0.1–8.9+ scale, bucketed as Low (1.0–3.9), Medium (4.0–6.9), and High (7.0–8.9). Severity drives automation: a common pattern is “auto-remediate High findings, notify on Medium, log Low.” Findings also include rich context — the affected resource, actor IP and geolocation, the API called — which is what you feed into an investigation or a response.
Finally: a finding for a given type is updated, not duplicated, when the same activity recurs within a window (GuardDuty aggregates recurring occurrences), which keeps alert volume sane.
Protection Plans: Extending Coverage Beyond the Basics
Beyond the foundational three sources, GuardDuty offers protection plans you enable individually. Know what each one watches — the exam picks the right plan for a given scenario.
S3 Protection
Analyzes CloudTrail S3 data events (object-level GetObject, PutObject, etc.) to detect suspicious access to your buckets — for example, an unusual principal suddenly enumerating and downloading objects. This is the plan that turns “someone is exfiltrating from S3” into a finding. It pairs naturally with the controls in the S3 security guide.
EKS Protection
Two layers. EKS Audit Log Monitoring analyzes Kubernetes audit logs to catch suspicious control-plane activity (anonymous access, privilege escalation, exec into pods). EKS Runtime Monitoring adds an agent for on-host visibility into container behavior. If a question mentions detecting threats inside Kubernetes workloads, EKS Protection is the answer.
Malware Protection
Two flavors worth separating:
- Malware Protection for EC2 scans the EBS volumes of an instance implicated in a finding — GuardDuty creates a snapshot and scans it out-of-band, with no agent and no performance impact on the workload. It is triggered by another finding (e.g., suspicious traffic), making it a second-stage confirmation.
- Malware Protection for S3 scans newly uploaded objects for malware before they are consumed downstream — a preventive-flavored control for upload pipelines.
RDS Protection
Analyzes login activity to Amazon Aurora databases to detect suspicious or anomalous sign-in attempts (brute force, logins from unusual sources). No agent, no impact on database performance.
Lambda Protection
Monitors network activity from Lambda functions (via VPC Flow Logs for Lambda) to catch functions reaching out to malicious infrastructure — cryptomining or C2 callbacks from compromised function code.
Runtime Monitoring
The agent-based layer (via the GuardDuty security agent, deployable as an EKS add-on or on ECS/EC2) that gives on-host, in-process visibility — file, process, and network telemetry from inside the workload. This is the one place GuardDuty is not agentless.
| Protection plan | Primary data | Detects |
|---|---|---|
| S3 Protection | CloudTrail S3 data events | Suspicious object access / exfiltration |
| EKS Protection | EKS audit logs (+ runtime) | Malicious control-plane / container activity |
| Malware Protection (EC2) | EBS volume scan | Malware on implicated instances |
| Malware Protection (S3) | Object scan on upload | Malware in uploaded files |
| RDS Protection | Aurora login activity | Anomalous database logins |
| Lambda Protection | Lambda network activity | Malicious outbound from functions |
| Runtime Monitoring | On-host agent | Process/file/network behavior inside workloads |
Tuning: Suppression Rules, Trusted IPs, and Threat Lists
Raw detection is noisy; the exam expects you to know how to tune it without losing coverage.
- Suppression rules auto-archive findings that match a filter (for example, a benign vulnerability scanner in your own account generating
Recon:EC2/PortProbeUnprotectedPort). Suppressed findings are still generated and recorded — they are archived, not deleted, and still exported to Security Hub/S3. Use suppression to cut alert fatigue, not to blind yourself. - Trusted IP lists tell GuardDuty which IPs to treat as safe (it will not generate certain findings for traffic from them). Limited to secure, expected sources like your corporate egress.
- Threat IP lists are your own lists of known-bad IPs; GuardDuty generates
Customfindings when those IPs appear. This is how you fold your organization’s intel into GuardDuty.
A subtle exam point: trusted IP and threat lists are managed by the GuardDuty administrator account in a multi-account setup and apply org-wide — member accounts cannot override them.
Multi-Account: Delegated Administration Across an Organization
Almost every SCS-C02 scenario involves AWS Organizations, and GuardDuty is designed to be run centrally. The correct pattern — and the exam answer — is a delegated administrator:
- From the Organizations management account, designate a dedicated security/audit account as the GuardDuty delegated administrator.
- That account enables GuardDuty for the organization and can turn on auto-enable so every existing and future member account gets GuardDuty (and chosen protection plans) automatically.
- All member findings aggregate into the delegated administrator, giving one pane of glass.
This mirrors the centralized model in the multi-account governance guide. Two things to remember: the management account should not be the security tooling account (separation of duties), and auto-enable for new accounts is the control that prevents coverage gaps as the org grows.
GuardDuty is also regional — findings are generated and stored per Region. To cover an organization fully you enable it in every Region you operate in (and, for defense against attackers using unused Regions, ideally all of them). Aggregating multi-Region findings is typically done by exporting to a central Security Hub or S3.
Automated Response: GuardDuty + EventBridge
GuardDuty is only as useful as what you do with a finding. The canonical, exam-expected pipeline is GuardDuty → EventBridge → action:
- GuardDuty publishes every finding as an Amazon EventBridge event (roughly every 5 minutes for updates; new findings are near-real-time).
- An EventBridge rule matches on finding attributes — type, severity, resource — using an event pattern.
- The rule targets an action: an SNS topic for notification, a Lambda function for remediation, or Step Functions for a multi-step runbook.
A typical event pattern that fires only on high-severity findings:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{ "numeric": [">=", 7] }]
}
}From there, a Lambda might isolate a compromised EC2 instance by swapping it to a locked-down security group, revoke a session, or block an IP at a Network ACL. This is the auto-remediation pattern covered in depth in the incident response and auto-remediation guide. The exam loves this chain because it demonstrates the detective-to-preventive handoff: GuardDuty detects, EventBridge routes, and a targeted action contains.
For central visibility rather than action, GuardDuty findings also flow natively into AWS Security Hub, and can be exported continuously to an S3 bucket (encrypted with KMS) for long-term retention and analysis.
GuardDuty vs. Neighboring Services — Don’t Mix Them Up
| Service | Role | One-line distinction |
|---|---|---|
| GuardDuty | Threat detection | Continuously finds malicious/anomalous activity |
| Security Hub | Findings aggregation + posture | Central dashboard and compliance standards |
| Detective | Investigation | Visualizes and analyzes the “why/how” behind a finding |
| Macie | Data classification | Finds sensitive data (PII) in S3 |
| Inspector | Vulnerability assessment | Scans for CVEs and unintended network exposure |
The exam sentence structure tells you which to pick: “detect” → GuardDuty; “aggregate/compliance score” → Security Hub; “investigate root cause / build an attack timeline” → Detective; “discover sensitive data” → Macie; “find software vulnerabilities” → Inspector. Getting this table cold is worth several questions. For the observability side of the story, pair it with the logging and monitoring guide.
Cost Model (Enough for the Exam)
GuardDuty pricing is usage-based per data source: the volume of CloudTrail events and DNS logs analyzed, the gigabytes of VPC Flow Logs processed, and per-plan charges (S3 data events analyzed, EKS audit logs, GB scanned for malware, etc.). The exam rarely asks for numbers, but it does test the concept: you pay for what GuardDuty analyzes, there is a 30-day free trial to estimate cost, and — importantly — enabling GuardDuty does not incur separate CloudTrail or VPC Flow Log charges, because it reads its own independent copy.
Frequently Asked Questions
Does GuardDuty require me to enable VPC Flow Logs or CloudTrail?
No. GuardDuty consumes an independent, duplicate stream of VPC Flow Logs, DNS logs, and CloudTrail management events. You do not need to enable those logs yourself for GuardDuty, and doing so through GuardDuty does not add to your CloudTrail or Flow Log bills. (S3 data events and EKS audit logs, however, require the corresponding protection plans.)
What is the difference between GuardDuty and AWS Security Hub?
GuardDuty is a detection engine that generates threat findings. Security Hub is an aggregation and posture-management service that collects findings from GuardDuty (and Inspector, Macie, and others), runs compliance standards like CIS and AWS Foundational Security Best Practices, and gives you a single dashboard. You typically run both: GuardDuty detects, Security Hub centralizes.
How do I roll GuardDuty out across an entire AWS Organization?
Designate a dedicated security account as the GuardDuty delegated administrator from the Organizations management account, then enable auto-enable so all current and future member accounts are covered automatically. Findings aggregate into the delegated administrator. Remember GuardDuty is regional, so enable it in every Region you use.
Can GuardDuty automatically stop an attack?
Not on its own — GuardDuty is detective, not preventive. You get automated response by publishing findings to EventBridge and targeting a Lambda function, Step Functions runbook, or SNS topic that performs the containment action (isolating an instance, blocking an IP, revoking a session). GuardDuty detects; your automation reacts.
What are suppression rules, and do they delete findings?
Suppression rules auto-archive findings matching a filter to reduce noise from expected activity (like an internal scanner). They do not delete findings — suppressed findings are still generated, recorded, and exported to Security Hub and S3. They are archived, so they stay auditable.
Which GuardDuty feature detects malware on an EC2 instance?
Malware Protection for EC2. When another finding implicates an instance, GuardDuty takes an out-of-band snapshot of its EBS volumes and scans them for malware — agentless, with no impact on the running workload. There is also Malware Protection for S3, which scans newly uploaded objects.
Conclusion
GuardDuty is the detection backbone of the SCS-C02’s Threat Detection domain, and it rewards depth. Anchor your understanding on four things: the data sources it reads (and the fact that it reads its own independent copies), the finding format and severity model that drive your response, the protection plans that extend it to S3, EKS, malware, RDS, Lambda, and runtime, and the EventBridge pipeline that turns a passive finding into an active containment. Layer on the multi-account delegated-administrator pattern and the “detect vs aggregate vs investigate” service distinctions, and you will handle GuardDuty questions with confidence.
The fastest way to make this stick is to work through scenario questions that force the distinctions — the ones that hinge on GuardDuty vs. Detective, or on which protection plan a scenario needs. Sailor.sh’s AWS Security Specialty mock exam bundle is built around exactly those scenario-style questions, so you practice reading the signal words and reaching for GuardDuty (or its neighbors) the way the real exam demands.