Amazon GuardDuty is a threat detection service that continuously monitors AWS accounts and workloads for malicious activity and unauthorized behavior. For the SAA-C03 exam, GuardDuty appears in roughly 5-10% of questions, typically integrated with other security services like AWS Security Hub, AWS Lambda, and Amazon Detective. This chapter covers GuardDuty's architecture, how it generates findings, its integration points, and the exact scenarios you need to know to answer exam questions correctly.
Jump to a section
Imagine a bank with multiple security layers. The bank has a main entrance (internet gateway), a vault (S3 buckets), employee badges (IAM roles), and security cameras (CloudTrail). GuardDuty is like a centralized security operations center that monitors all these feeds simultaneously. It receives video footage (VPC Flow Logs), access logs (CloudTrail), and vault access records (S3 data events). Instead of a human watching every camera, an AI analyzes patterns: it flags when someone enters after hours (unusual API calls), when a door is forced open (brute force SSH), or when an employee accesses files they never touch (data exfiltration). The system doesn't block anything itself – it just alerts the security team (CloudWatch Events) and provides a report (findings). If the bank has multiple branches (multiple AWS accounts), the security center can monitor all of them from one console (GuardDuty administrator account). The key is that the system learns normal behavior over 7-14 days (baseline period) and only raises alerts for anomalies that deviate from that baseline. It doesn't use static rules like 'no entry after 10 PM' – it adapts to the bank's actual operating hours and employee patterns.
What is Amazon GuardDuty?
Amazon GuardDuty is a managed threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to identify potential threats in your AWS environment. It is not a firewall, not an intrusion prevention system (IPS), and not a vulnerability scanner. It is a detection-only service that generates security findings when it observes suspicious activity. GuardDuty is regionally deployed but can be managed centrally across multiple accounts using AWS Organizations.
How GuardDuty Works Internally
GuardDuty analyzes three primary data sources: - AWS CloudTrail management events: Tracks API calls like CreateUser, DeleteBucket, or AuthorizeSecurityGroupIngress. - AWS CloudTrail S3 data events: Tracks object-level API operations on S3 buckets (GetObject, PutObject, etc.). - VPC Flow Logs: Captures IP traffic information for network interfaces in VPCs. - DNS logs: Analyzes DNS queries from EC2 instances and containers.
GuardDuty ingests these logs and applies a combination of: - Machine learning models: Baseline normal behavior over 7-14 days, then flag deviations. - Anomaly detection: Statistical outlier detection on traffic patterns. - Threat intelligence feeds: Known malicious IPs, domains, URL lists from AWS and third-party partners (CrowdStrike, Proofpoint, etc.).
When a finding is generated, it includes: - Severity: Low (1-3.9), Medium (4-6.9), High (7-8.9), Critical (9-10). - Type: A predefined finding type like 'Backdoor:EC2/C&CActivity.B' or 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration'. - Resource: The AWS resource involved (EC2 instance, IAM user, S3 bucket). - Action: The specific API action or network connection that triggered the finding. - Actor: The source of the activity (IP address, user, role).
Key Components and Defaults
GuardDuty Detector: A regional resource that enables GuardDuty in a specific AWS Region. You can have only one detector per region per account.
Master/Administrator Account: In a multi-account setup, you designate one account as the GuardDuty administrator (formerly called master). This account can view findings from all member accounts.
Member Accounts: Accounts that are invited or added via AWS Organizations to be monitored by the administrator account.
Finding Frequency: GuardDuty analyzes logs in near real-time. Findings typically appear within 5-15 minutes of the triggering event.
Data Retention: Findings are retained for 90 days. You can export findings to S3 for longer retention.
Trusted IP Lists: You can define up to 50 IP lists per account per region (max 1000 entries per list). These are IP addresses that are trusted and will not generate findings.
Threat Lists: You can define custom threat lists (up to 50 per account per region, max 10000 entries per list) of malicious IP addresses or domains that GuardDuty should always flag.
CloudWatch Events Integration: GuardDuty sends findings to CloudWatch Events, enabling automated responses via Lambda, SNS, or Step Functions.
AWS Organizations Integration: GuardDuty can be enabled for all accounts in an organization with a single click. When a new account joins, GuardDuty automatically enables it.
Configuration and Verification
Enabling GuardDuty:
aws guardduty create-detector --enable --region us-east-1Adding member accounts:
aws guardduty create-members --detector-id <detector-id> --account-details AccountId=123456789012,Email=user@example.com
aws guardduty invite-members --detector-id <detector-id> --account-ids 123456789012Listing findings:
aws guardduty list-findings --detector-id <detector-id>
aws guardduty get-findings --detector-id <detector-id> --finding-ids <finding-id>Updating threat lists:
aws guardduty create-threat-list --detector-id <detector-id> --name MyThreatList --location s3://my-bucket/threatlist.txt --format TXTInteraction with Related Technologies
AWS Security Hub: Aggregates GuardDuty findings along with findings from Inspector, Macie, and other services. Security Hub provides a single pane of glass and can run automated compliance checks.
Amazon Detective: Can ingest GuardDuty findings to help investigate the root cause using prebuilt data visualizations.
AWS Lambda: Commonly used to automate responses to GuardDuty findings, such as isolating an EC2 instance by modifying security groups.
AWS WAF & Shield: GuardDuty does not block traffic; WAF and Shield do. GuardDuty can trigger WAF updates via Lambda.
AWS IAM Access Analyzer: Complements GuardDuty by identifying resources shared with external entities, but GuardDuty focuses on active threats.
GuardDuty Finding Types (Key Examples)
Backdoor:EC2/C&CActivity.B!: EC2 instance communicating with a command-and-control server.
CryptoCurrency:EC2/BitcoinTool.B!: EC2 instance running Bitcoin mining software.
Recon:EC2/Portscan: EC2 instance performing outbound port scans.
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration: IAM credentials used from an external IP (indicates compromised keys).
Policy:IAMUser/RootCredentialUsage: Root user credentials used (should be rare).
Stealth:IAMUser/CloudTrailLoggingDisabled: CloudTrail logging was disabled (indicates attacker covering tracks).
Pricing Model
GuardDuty charges based on: - CloudTrail management events: $4.00 per million events (first 1 million free per month). - CloudTrail S3 data events: $0.80 per million events. - VPC Flow Logs: $0.50 per GB of logs analyzed. - DNS logs: $0.50 per GB of logs analyzed. - Crypto Mining detection: Additional $0.10 per GB of DNS data.
There is no upfront cost; you pay only for what you use. A 30-day free trial is available (limited to 1000 findings).
Limitations
GuardDuty does not support all AWS services (e.g., it does not analyze Application Load Balancer access logs directly).
It cannot detect threats that are not reflected in the three log sources (e.g., if VPC Flow Logs are disabled, network-based findings are reduced).
GuardDuty is region-specific; you must enable it in each region where you want coverage.
It does not block or remediate threats by itself; you must implement automated responses.
Best Practices
Enable GuardDuty in all regions, especially those where you run production workloads.
Use AWS Organizations to centrally enable GuardDuty for all accounts.
Integrate with Security Hub for cross-account, cross-region aggregation.
Automate response via Lambda for high-severity findings.
Export findings to S3 for long-term retention and compliance.
Regularly review findings and update custom threat lists.
Enable GuardDuty in a Region
You must create a GuardDuty detector in each region. This can be done via the AWS Management Console, CLI, or API. When you enable GuardDuty, it begins analyzing CloudTrail events, VPC Flow Logs, and DNS logs. The first 30 days are free (trial). After the trial, you pay based on usage. GuardDuty immediately starts building a baseline of normal activity. No additional configuration is needed for data sources – GuardDuty automatically accesses them if they are enabled. If VPC Flow Logs are not enabled, GuardDuty will still work but will not generate network-based findings for that VPC.
GuardDuty Analyzes Logs
GuardDuty continuously pulls logs from CloudTrail, VPC Flow Logs, and DNS logs. It uses machine learning models to establish a baseline of normal behavior over 7-14 days. For example, it learns which EC2 instances typically communicate with which external IPs, what time of day API calls are made, and which users access S3 buckets. It also compares IP addresses and domains against threat intelligence feeds. The analysis occurs in near real-time; findings typically appear within 5-15 minutes of the event. GuardDuty does not store the raw logs; it only retains findings for 90 days.
Finding Generation
When GuardDuty detects an anomaly or a match against a threat feed, it creates a finding. Each finding has a severity (Low, Medium, High, Critical), a type (e.g., 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration'), and details about the resource, action, and actor. The finding is stored in the GuardDuty service and can be retrieved via the console, CLI, or API. GuardDuty also publishes the finding to CloudWatch Events, which can trigger automated responses. Findings are immutable and cannot be deleted; they can only be archived.
Automated Response via CloudWatch Events
GuardDuty sends findings to the default CloudWatch Events bus. You can create event rules that match specific finding types or severities. For example, a rule can trigger a Lambda function that isolates an EC2 instance by changing its security group, or sends an SNS notification to the security team. The response is not built into GuardDuty; you must configure it separately. AWS provides sample Lambda blueprints for common responses. Note that GuardDuty itself does not block or remediate; it relies on downstream automation.
Multi-Account Management via AWS Organizations
To manage GuardDuty across multiple accounts, you designate one account as the administrator account (formerly master). This account can be an existing account or a delegated administrator via AWS Organizations. Member accounts can be added manually or automatically via Organizations. The administrator account can view findings from all member accounts, configure threat lists, and enable or disable GuardDuty in member accounts. Member accounts cannot disable GuardDuty if the administrator account has enforced it. This centralizes security monitoring without requiring cross-account IAM roles.
Scenario 1: Enterprise Multi-Account Environment
A large enterprise with 200 AWS accounts uses GuardDuty to monitor for compromised credentials. They enable GuardDuty via AWS Organizations in all regions. They configure the security team's account as the GuardDuty administrator. The team sets up a Lambda function that automatically rotates IAM keys when GuardDuty detects 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration' findings. They also export all findings to a central S3 bucket with 90-day retention, and then use Amazon Athena to query for trends. A common issue they faced was that VPC Flow Logs were not enabled in all VPCs, causing gaps in network anomaly detection. They resolved this by using AWS Config rules to enforce VPC Flow Logs. Performance-wise, GuardDuty scaled without issues; the cost was approximately $500 per month for 200 accounts with moderate activity.
Scenario 2: E-Commerce Platform with S3 Data Breach Risk
An e-commerce company uses S3 to store customer data. They enable GuardDuty with S3 data event analysis. GuardDuty detects an unusual pattern: a developer's IAM user starts reading thousands of customer records from an S3 bucket at 3 AM, which is outside normal behavior. GuardDuty generates a 'Stealth:S3/ServerAccessLoggingDisabled' finding because the attacker disabled access logging. The security team receives a CloudWatch Event that triggers a Lambda function that revokes the IAM user's permissions and sends an alert. They then use Amazon Detective to investigate the scope of the breach. The company learned the hard way that they had not enabled S3 data events in the first place, so GuardDuty could not detect object-level threats. They now use CloudTrail to log all S3 data events.
Scenario 3: Startups with Limited Security Staff
A startup with a single AWS account and limited security expertise enables GuardDuty with a 30-day free trial. They rely on GuardDuty's built-in threat intelligence to detect known malicious IPs. They integrate GuardDuty with Security Hub to get a consolidated view. They set up an SNS topic to email the CTO for any High or Critical findings. Initially, they received many false positives – for example, GuardDuty flagged their internal monitoring tools as 'Recon:EC2/Portscan'. They mitigated this by adding the monitoring server's IP to a trusted IP list. They also learned that GuardDuty takes up to 14 days to establish a baseline, so they had to be patient during the initial period. The startup now uses GuardDuty as their primary threat detection tool, and it costs them less than $20 per month.
SAA-C03 Exam Focus on GuardDuty
The SAA-C03 exam tests GuardDuty primarily under Domain 1: Secure Architectures, Objective 1.4 (Implement secure application architectures). You should know:
What GuardDuty does and does not do: It is a detection service, not a prevention or remediation service. It does not block traffic, patch vulnerabilities, or scan for known CVEs. It analyzes CloudTrail logs, VPC Flow Logs, and DNS logs.
2. Common wrong answers: - 'GuardDuty can block malicious IPs' – WRONG. GuardDuty only detects; use Network ACLs or security groups to block. - 'GuardDuty uses AWS WAF rules' – WRONG. GuardDuty is separate from WAF. - 'GuardDuty automatically remediates threats' – WRONG. You must build automation with Lambda. - 'GuardDuty is a global service' – WRONG. It is regional, but you can aggregate findings via Security Hub.
Specific numbers and terms:
Findings retained for 90 days.
Baseline period: 7-14 days.
Severity levels: Low (1-3.9), Medium (4-6.9), High (7-8.9), Critical (9-10).
Data sources: CloudTrail management events, CloudTrail S3 data events (must be enabled separately), VPC Flow Logs, DNS logs.
Multi-account: Administrator account (formerly master) and member accounts.
Integration: CloudWatch Events, Security Hub, Detective, Lambda, SNS.
Edge cases:
If VPC Flow Logs are not enabled, GuardDuty still works but network-related findings are limited.
GuardDuty cannot analyze encrypted DNS traffic (DNS over HTTPS).
GuardDuty does not support all AWS services; e.g., it does not analyze ALB access logs.
If you disable CloudTrail, GuardDuty loses one of its primary data sources.
How to eliminate wrong answers:
If the question asks for a service that detects threats, GuardDuty is correct.
If the question asks for a service that blocks or prevents, look for AWS WAF, Shield Advanced, Network Firewall, or security groups.
If the question mentions 'automated response', check if Lambda is part of the solution.
If the question involves 'known malicious IPs', GuardDuty uses threat intelligence feeds.
If the question involves 'unusual behavior', GuardDuty uses ML and anomaly detection.
Exam Question Patterns
Scenario: 'A company wants to detect compromised IAM credentials. Which service?' Answer: GuardDuty (analyzes CloudTrail for unusual API call patterns).
Scenario: 'A company wants to detect cryptocurrency mining on EC2.' Answer: GuardDuty (has specific finding type 'CryptoCurrency:EC2/BitcoinTool.B!').
Scenario: 'A company needs to aggregate GuardDuty findings across multiple accounts.' Answer: Security Hub (not GuardDuty itself, which is per-account).
Scenario: 'A company wants to automatically isolate a compromised EC2 instance.' Answer: GuardDuty + CloudWatch Events + Lambda.
GuardDuty is a regional threat detection service that analyzes CloudTrail (management and S3 data events), VPC Flow Logs, and DNS logs using ML and threat intelligence.
Findings are retained for 90 days. Severity levels: Low (1-3.9), Medium (4-6.9), High (7-8.9), Critical (9-10).
GuardDuty does not block or remediate threats; it only detects. Automate responses using CloudWatch Events and Lambda.
Multi-account management: use AWS Organizations to designate an administrator account that can view findings from all member accounts.
GuardDuty integrates with AWS Security Hub for cross-account and cross-region aggregation, and with Amazon Detective for investigation.
Common finding types: Backdoor:EC2/C&CActivity.B!, CryptoCurrency:EC2/BitcoinTool.B!, UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.
GuardDuty requires a 7-14 day baseline period to learn normal behavior; initial findings may include false positives.
You can add trusted IP lists and custom threat lists to refine detection.
GuardDuty is not a vulnerability scanner; use Amazon Inspector for that. It is not a firewall; use WAF or security groups for blocking.
Enable GuardDuty in all regions where you have workloads, and ensure CloudTrail and VPC Flow Logs are enabled for full coverage.
These come up on the exam all the time. Here's how to tell them apart.
Amazon GuardDuty
Threat detection service using ML and threat intelligence.
Analyzes CloudTrail, VPC Flow Logs, DNS logs.
Generates security findings (anomalies, threats).
Regional service, multi-account via administrator/member.
Does not aggregate findings from other services.
AWS Security Hub
Security posture management and aggregation service.
Aggregates findings from GuardDuty, Inspector, Macie, etc.
Provides a consolidated view and compliance checks (CIS benchmarks).
Regional but can aggregate across accounts via cross-region aggregation.
Does not perform its own threat detection; relies on other services.
Amazon GuardDuty
Detects threats and malicious activity in real-time.
Analyzes network and API logs.
Uses ML and threat intelligence.
No agents required; works at the account/network level.
Focuses on active threats like compromised credentials, C2 traffic.
Amazon Inspector
Vulnerability assessment service.
Scans EC2 instances and container images for known CVEs.
Uses a knowledge base of vulnerabilities (CVE database).
Requires an agent on EC2 instances (or uses SSM).
Focuses on software vulnerabilities and network reachability.
Mistake
GuardDuty blocks malicious traffic automatically.
Correct
GuardDuty is a detection-only service. It does not block or prevent any activity. You must use other services like AWS WAF, Network ACLs, or security groups to block traffic, and automate responses with Lambda.
Mistake
GuardDuty is a global service that covers all regions automatically.
Correct
GuardDuty is regional. You must enable it in each region separately. However, you can aggregate findings from multiple regions using AWS Security Hub.
Mistake
GuardDuty only monitors EC2 instances.
Correct
GuardDuty monitors IAM users, S3 buckets, EC2 instances, and other resources by analyzing CloudTrail, VPC Flow Logs, and DNS logs. It covers many resource types.
Mistake
GuardDuty requires you to enable VPC Flow Logs separately.
Correct
GuardDuty can analyze VPC Flow Logs if they are enabled, but it does not enable them for you. If VPC Flow Logs are not enabled, GuardDuty will still work but will not generate network-based findings for those VPCs.
Mistake
GuardDuty can replace antivirus software on EC2 instances.
Correct
GuardDuty monitors network and API activity, not the operating system or files inside EC2 instances. It cannot detect malware on the instance itself. Use Amazon Inspector for vulnerability scanning or third-party antivirus.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
GuardDuty analyzes CloudTrail logs for unusual API call patterns, such as an IAM user making API calls from an unexpected geographic location or at unusual times. It also detects when credentials are used from an external IP not associated with the user. The specific finding type is 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration'. GuardDuty uses machine learning to establish a baseline of normal behavior over 7-14 days, then flags deviations. For example, if a user who normally logs in from New York suddenly makes API calls from Nigeria, GuardDuty will generate a finding.
Yes, GuardDuty has a specific finding type 'CryptoCurrency:EC2/BitcoinTool.B!' that detects EC2 instances communicating with known cryptocurrency mining pools or running mining software. It analyzes DNS queries and network connections to known mining infrastructure. GuardDuty also uses machine learning to detect unusual CPU patterns that might indicate mining, but primarily relies on network traffic analysis. If you see this finding, you should immediately isolate the instance and investigate.
Yes, GuardDuty supports multi-account management via AWS Organizations. You designate one account as the GuardDuty administrator (formerly master). This administrator account can view findings from all member accounts, configure threat lists, and enable or disable GuardDuty in member accounts. Member accounts can be added manually or automatically when new accounts join the organization. However, each account still has its own detector, and findings are generated per account. The administrator account simply has a cross-account view.
GuardDuty retains findings for 90 days. After that, they are automatically deleted. If you need longer retention, you can export findings to an S3 bucket using CloudWatch Events and a Lambda function, or use AWS Security Hub, which can also store findings for up to 90 days (or longer if exported). There is no built-in way to extend retention within GuardDuty itself.
GuardDuty analyzes three primary data sources: AWS CloudTrail management events (API calls), AWS CloudTrail S3 data events (object-level operations on S3), VPC Flow Logs (network traffic metadata), and DNS logs (DNS queries from EC2 and containers). You must ensure these sources are enabled for GuardDuty to work fully. CloudTrail management events are enabled by default, but S3 data events and VPC Flow Logs must be explicitly enabled. DNS logs are automatically available for EC2 instances using the default DNS resolver.
GuardDuty pricing is based on the volume of logs analyzed. For CloudTrail management events, the first 1 million events per month are free, then $4.00 per million events. For CloudTrail S3 data events, it's $0.80 per million events. For VPC Flow Logs and DNS logs, it's $0.50 per GB of logs analyzed. There is also a crypto mining detection add-on at $0.10 per GB of DNS data. A 30-day free trial is available, limited to 1000 findings. There are no upfront costs.
GuardDuty does not directly integrate with AWS WAF, but you can build an automated response using CloudWatch Events and Lambda. For example, if GuardDuty detects a known malicious IP communicating with an EC2 instance, a Lambda function can update a WAF web ACL to block that IP. However, this is custom-built; there is no native integration. GuardDuty itself does not modify WAF rules.
You've just covered Amazon GuardDuty — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?