Cargando...
Cargando...
Continuous, ML-powered threat detection across your AWS accounts — no agents, no infrastructure, no excuses.
Amazon GuardDuty is a fully managed, continuous threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to identify malicious activity and unauthorized behavior across your AWS accounts, workloads, and data. It analyzes billions of events across multiple AWS data sources — including AWS CloudTrail, VPC Flow Logs, DNS logs, Amazon S3 data events, Amazon EKS audit logs, AWS Lambda network activity, Amazon RDS login events, and Amazon EBS volumes — without requiring you to deploy or manage any infrastructure. GuardDuty produces prioritized, actionable security findings that integrate natively with AWS Security Hub, Amazon EventBridge, and AWS Organizations for centralized, multi-account threat management.
Detect compromised credentials, insider threats, reconnaissance attacks, malware, cryptomining, data exfiltration, and account takeover attempts across your entire AWS environment automatically and continuously.
Use When
Avoid When
Foundational Threat Detection (CloudTrail, VPC Flow Logs, DNS)
Always-on analysis of CloudTrail management events, VPC Flow Logs, and Route 53 DNS query logs. No need to separately enable these data sources in your account.
S3 Protection (CloudTrail S3 data events)
Monitors S3 data-plane API calls for suspicious activity like unusual access patterns, public bucket exposure, and data exfiltration attempts. Enabled by default for new detectors.
EKS Protection (Audit Logs + Runtime Monitoring)
Analyzes EKS Kubernetes audit logs for container escape, privilege escalation, and cryptomining. Runtime Monitoring adds eBPF-based agent for in-cluster process and network activity.
Malware Protection (EBS scanning)
On-demand and automated scanning of EBS volumes attached to EC2 instances and ECS tasks when GuardDuty detects suspicious activity. No agent required.
RDS Protection (Aurora login monitoring)
Analyzes Amazon Aurora login activity for anomalous access patterns, brute force attempts, and suspicious credential usage.
Lambda Protection (network activity monitoring)
Monitors Lambda function network activity to detect functions communicating with known malicious IPs, crypto mining pools, or command-and-control servers.
ECS Runtime Monitoring
Extends runtime threat detection to ECS workloads (both EC2 and Fargate launch types) using lightweight security agents.
EC2 Runtime Monitoring
Agent-based runtime monitoring for EC2 instances providing process-level visibility and threat detection.
Multi-Account Management via AWS Organizations
Designate a delegated administrator account to centrally manage GuardDuty across all organization accounts, auto-enable new accounts, and aggregate findings.
Finding Export to S3
Export findings to an S3 bucket (encrypted with KMS) for long-term retention beyond the 90-day limit and for SIEM integration.
EventBridge Integration
All findings are published to Amazon EventBridge, enabling automated remediation workflows via Lambda, SNS, SQS, or Step Functions.
Security Hub Integration
GuardDuty findings are automatically sent to AWS Security Hub in ASFF (Amazon Security Finding Format) for consolidated security posture management.
Trusted IP Lists
Upload lists of trusted IP ranges to suppress findings for known-safe sources like corporate VPN exits or partner networks.
Threat Intelligence Lists
Upload custom threat intel IP lists to generate findings when your resources communicate with known-bad IPs beyond AWS's built-in threat feeds.
Suppression Rules
Auto-archive findings matching specific criteria to reduce noise without losing the finding data.
Finding Severity Levels
Findings are classified as Low (1.0-3.9), Medium (4.0-6.9), or High (7.0-8.9) severity to help prioritize response.
Agentless (for foundational features)
Core threat detection requires zero agent deployment. Runtime Monitoring features require a lightweight GuardDuty security agent.
Amazon Detective Integration
One-click pivot from a GuardDuty finding to Amazon Detective for deep forensic investigation and entity behavior analysis.
Centralized Security Findings Aggregation
high freqGuardDuty automatically sends all findings to AWS Security Hub in ASFF format. Security Hub aggregates findings from GuardDuty, Macie, Inspector, IAM Access Analyzer, and third-party tools into a single pane of glass. Use Security Hub's consolidated findings to run compliance checks and trigger cross-service remediation workflows. This is the most common exam integration pattern.
Automated Threat Remediation
high freqGuardDuty findings trigger EventBridge rules, which invoke Lambda functions to automatically remediate threats — for example, isolating a compromised EC2 instance by modifying its Security Group, revoking IAM credentials, or blocking an IP in a NACL. This is the canonical serverless security automation pattern.
Multi-Account Centralized Threat Detection
high freqUse AWS Organizations to designate a delegated GuardDuty administrator account. This account can enable GuardDuty across all member accounts, auto-enable new accounts as they join the organization, and aggregate all findings centrally. Member accounts cannot disable GuardDuty when managed this way.
Detect → Investigate Workflow
high freqGuardDuty detects threats and surfaces findings. Amazon Detective provides the forensic investigation layer — visualizing entity relationships, behavior timelines, and blast radius of a security incident. The one-click pivot from a GuardDuty finding to Detective is the intended workflow. Remember: GuardDuty DETECTS, Detective INVESTIGATES.
Threat Detection + Data Classification
high freqGuardDuty detects unauthorized S3 access patterns and exfiltration attempts. Amazon Macie classifies the sensitivity of S3 data (PII, PHI, financial data). Together they answer: 'Is someone accessing sensitive data inappropriately?' GuardDuty catches the WHO/HOW, Macie identifies the WHAT.
API Activity Threat Analysis
high freqGuardDuty automatically consumes CloudTrail management events and (with S3 Protection enabled) S3 data events to detect compromised credentials, unusual API calls, and privilege escalation. You do NOT need to separately enable or configure CloudTrail for GuardDuty — it accesses independent streams of CloudTrail activity.
Long-Term Finding Archival
medium freqConfigure GuardDuty to export findings to an S3 bucket encrypted with a KMS customer-managed key. This extends finding retention beyond the 90-day in-service limit for compliance, audit, and SIEM ingestion purposes. The S3 bucket and KMS key must have appropriate resource policies to allow GuardDuty to write.
Compliance Posture + Threat Detection
medium freqAWS Config tracks resource configuration changes and compliance against rules. GuardDuty detects active threats and anomalous behavior. Together they provide both configuration compliance (Config) and runtime threat detection (GuardDuty) — complementary, not redundant.
Real-Time Security Alerting
medium freqRoute GuardDuty findings through EventBridge to SNS topics for immediate email, SMS, or PagerDuty/Slack notifications when high-severity findings are generated. Use EventBridge rule filtering to only alert on High severity findings to avoid alert fatigue.
Orchestrated Incident Response
medium freqFor complex remediation workflows requiring multiple steps, approvals, or conditional logic, route GuardDuty findings via EventBridge to Step Functions state machines. This enables sophisticated incident response automation including human-in-the-loop approval gates for destructive actions.
GuardDuty is a DETECTIVE control, NOT a preventive control. It detects and alerts — it does NOT block traffic, modify security groups, or prevent API calls on its own. Automated remediation requires EventBridge + Lambda or Step Functions.
GuardDuty does NOT require you to enable VPC Flow Logs or CloudTrail in your account — it analyzes independent streams of this data. However, if you have them enabled, they are unaffected. Never disable your own logs just because GuardDuty exists.
In a multi-account setup using AWS Organizations, the delegated administrator can enable GuardDuty for ALL member accounts and prevent members from disabling it. Member accounts CANNOT opt out when centrally managed. This is a key exam scenario for enforcing security controls at scale.
GuardDuty findings are retained for only 90 days. For compliance requirements needing longer retention, you MUST configure finding export to S3. This is a common exam question framed as 'how do you retain GuardDuty findings for 1 year?'
Know the GuardDuty → Detective → response chain: GuardDuty DETECTS the threat (finding), Detective INVESTIGATES the scope and blast radius (forensics), EventBridge + Lambda/Step Functions RESPONDS (remediation). These three services are complementary and frequently tested together.
GuardDuty is a DETECTIVE control ONLY — it detects and alerts but NEVER blocks, prevents, or remediates on its own. Automated response requires EventBridge + Lambda/Step Functions. If an exam question asks how to PREVENT an attack, GuardDuty is not the answer — WAF, Security Groups, or IAM policies are.
GuardDuty does NOT require CloudTrail or VPC Flow Logs to be enabled in your account — it accesses independent data streams. It is also REGIONAL, not global — you must enable it in every region. Use AWS Organizations delegated administrator to auto-enable across all accounts and regions.
Know the security service roles: GuardDuty DETECTS threats → Amazon Detective INVESTIGATES them → EventBridge + Lambda REMEDIATES them. Macie CLASSIFIES sensitive data. These are complementary, not interchangeable. Exam scenarios test whether you select the right service for detect vs. investigate vs. classify vs. prevent.
GuardDuty is REGIONAL. A detector in us-east-1 does NOT protect eu-west-1. You must enable GuardDuty in every region where you have workloads. Use the delegated administrator with Organizations to auto-enable across all regions and accounts.
Suppression rules and Trusted IP lists serve different purposes: Trusted IP lists prevent findings from being GENERATED for known-safe IPs. Suppression rules AUTO-ARCHIVE findings that match criteria AFTER they are generated. Both reduce noise but work differently — this distinction appears in exam questions.
GuardDuty Malware Protection scans EBS volumes WITHOUT requiring an agent on the EC2 instance. It creates a replica snapshot of the EBS volume and scans it in an isolated GuardDuty-managed environment. This is agentless malware detection.
New GuardDuty findings are exported to S3 within approximately 5 minutes. UPDATED findings (subsequent occurrences of the same finding type) are exported on a configurable schedule: 15 minutes, 1 hour, or 6 hours. Know this distinction for architecture questions requiring near-real-time finding export.
GuardDuty finding types follow a naming convention: ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact. For example: 'CryptoCurrency:EC2/BitcoinTool.B!DNS' means cryptomining activity detected on EC2 via DNS query analysis. Understanding this format helps decode findings quickly.
GuardDuty S3 Protection and EKS Protection are separate protection plans that may need to be explicitly enabled depending on when your account was created. New detectors have S3 Protection enabled by default, but always verify in exam scenarios that the specific protection plan is enabled for the resource type being protected.
For the SCS-C02 and SAP-C02 exams: When asked to detect compromised EC2 instances communicating with known C2 servers, cryptomining pools, or Tor exit nodes — the answer is GuardDuty (analyzes VPC Flow Logs + DNS). When asked to detect sensitive data in S3 — the answer is Macie. When asked to investigate HOW an attacker moved laterally — the answer is Detective.
GuardDuty Runtime Monitoring uses an eBPF-based security agent (for EKS/ECS/EC2) to provide process-level, file-system, and network visibility inside containers and instances. This is different from the agentless foundational detection. Runtime Monitoring findings have higher fidelity but require agent deployment.
Common Mistake
GuardDuty requires you to enable AWS CloudTrail and VPC Flow Logs in your account before it can work.
Correct
GuardDuty analyzes independent streams of CloudTrail and VPC Flow Log data that it accesses directly — you do NOT need to have these services enabled in your account. GuardDuty will still function even if you have never turned on CloudTrail or VPC Flow Logs. However, you should still enable them for your own operational and compliance needs.
This is a top exam trap. Many candidates think GuardDuty is a 'consumer' of your existing logs, but it's actually tapping into separate data streams. The exam often presents scenarios where CloudTrail is disabled and asks if GuardDuty still works — the answer is YES for foundational threat detection.
Common Mistake
GuardDuty can block malicious traffic or prevent unauthorized API calls from executing.
Correct
GuardDuty is purely a detective control. It generates findings (alerts) but takes NO automated action on its own. To block traffic or remediate threats, you must build automation using Amazon EventBridge triggering AWS Lambda, Step Functions, or Systems Manager Automation. GuardDuty finding + EventBridge + Lambda = automated remediation.
Candidates confuse GuardDuty with AWS WAF (which blocks HTTP requests) or Security Groups/NACLs (which block network traffic). GuardDuty watches and reports — it never acts. This distinction is tested heavily, especially in architecture scenarios asking 'which service PREVENTS vs. DETECTS.'
Common Mistake
Disabling GuardDuty findings for a specific IP using a suppression rule is the same as adding it to a Trusted IP list.
Correct
These two mechanisms work at different points in the finding lifecycle. A Trusted IP list prevents GuardDuty from GENERATING findings for traffic from those IPs — the finding is never created. A suppression rule GENERATES the finding but immediately auto-archives it so it doesn't appear in your active findings list. The finding still exists and still counts for billing purposes with suppression rules.
Exam questions ask which mechanism is appropriate when you want to 'ensure no findings are ever generated' (Trusted IP list) vs. 'reduce noise in the findings console while retaining the finding data' (suppression rule). Getting this wrong leads to incorrect architecture recommendations.
Common Mistake
In a multi-account GuardDuty setup, member accounts can disable GuardDuty for their own account if they need to.
Correct
When GuardDuty is enabled and managed by a delegated administrator through AWS Organizations, member accounts CANNOT disable GuardDuty for their account. The administrator controls the configuration. This is a key security governance feature — it prevents rogue insiders or compromised accounts from disabling threat detection to cover their tracks.
This appears in exam scenarios about enforcing security controls at scale. The question often asks 'how do you ensure GuardDuty cannot be disabled by individual account owners?' — the answer is AWS Organizations with a delegated GuardDuty administrator.
Common Mistake
Amazon GuardDuty and Amazon Detective are the same thing or serve the same purpose.
Correct
GuardDuty DETECTS threats and generates findings. Amazon Detective INVESTIGATES findings by providing graph-based forensic analysis of entity relationships, behavior timelines, and the scope of a security incident. They are complementary: you use GuardDuty to find threats, then Detective to understand them. Detective must be separately enabled and has its own pricing.
The names are confusingly similar and both are 'security investigation' services. The exam tests whether you know: GuardDuty = threat detection (generates findings), Detective = forensic investigation (analyzes findings). A common distractor is suggesting Detective can replace GuardDuty or vice versa — they cannot.
Common Mistake
GuardDuty findings older than 90 days are automatically archived to S3 or Glacier.
Correct
GuardDuty findings are DELETED after 90 days — they are NOT automatically archived anywhere. If you need findings beyond 90 days (for compliance, audit, or forensics), you MUST proactively configure finding export to an S3 bucket. This is a manual configuration step, not automatic.
This is a critical compliance trap. Organizations subject to regulations requiring 1-year or 7-year log retention will lose GuardDuty finding data if they don't configure S3 export. The exam frames this as: 'Your security team needs to review GuardDuty findings from 6 months ago — what should have been configured?'
Common Mistake
GuardDuty is a global service that automatically covers all AWS regions once enabled in one region.
Correct
GuardDuty is a REGIONAL service. Enabling it in us-east-1 provides NO coverage for eu-west-1, ap-southeast-1, or any other region. You must enable GuardDuty separately in each region. To ensure coverage across all regions and accounts at scale, use AWS Organizations with a delegated administrator configured to auto-enable GuardDuty in all regions.
This trap catches candidates who confuse GuardDuty with global services like IAM or Route 53. A common exam scenario: 'An attacker launched EC2 instances in ap-southeast-2 for cryptomining. GuardDuty was enabled in us-east-1. Why wasn't the activity detected?' — because GuardDuty was not enabled in ap-southeast-2.
Common Mistake
Believing Amazon Detective automatically throttles or proportionally scales data ingest when volume limits are reached, or that its member account limit is 1,000.
Correct
Amazon Detective (a related but distinct service) has its own limits that differ from GuardDuty. Detective has a 1,200 member account limit per behavior graph (not 1,000), a 9 TB data volume warning threshold, and a 15 TB hard stop that requires contacting AWS Support to re-enable — it does NOT auto-scale or proportionally throttle. GuardDuty itself does not have these data volume caps. Always check limits per-service and never assume they share limits.
Exam questions deliberately mix GuardDuty and Detective limits to confuse candidates. The 1,000 vs. 1,200 member account confusion and the 9 TB vs. 15 TB threshold confusion are documented top misconceptions. Remember: GuardDuty = 10,000 member accounts. Detective = 1,200 member accounts, 9 TB warning, 15 TB hard stop.
GuardDuty = GUARD (watches for threats) + DUTY (it's always on duty, 24/7, no days off). It GUARDS but cannot ACT — it needs Lambda as its 'enforcement arm'.
The Security Trio: GuardDuty DETECTS (is something bad happening?), Macie CLASSIFIES (is sensitive data exposed?), Detective INVESTIGATES (what happened and how far did it spread?). D-C-I: Detect → Classify → Investigate.
REGIONAL reminder: 'GuardDuty guards the REGION it's in, not the whole kingdom.' Enable it in EVERY region or use Organizations to auto-enable everywhere.
90-day finding retention: 'GuardDuty has a 90-day memory — after that, findings vanish like a goldfish. Export to S3 for a longer memory.'
Trusted IP vs. Suppression Rule: 'Trusted IP = Never born (finding never created). Suppression = Born but silenced (finding created but archived).'
CertAI Tutor · SAA-C03, SAP-C02, DOP-C02, SCS-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns