AWS GuardDuty Threat Detection: A Production Setup Guide

GuardDuty is AWS’s managed threat detection service — it continuously monitors your AWS accounts and workloads for malicious activity and unauthorized behavior. Unlike traditional intrusion detection systems that require agents, rules, and infrastructure, GuardDuty runs without any software to deploy or infrastructure to manage.

But enabling GuardDuty is just the beginning. The difference between a useful security tool and a noisy alert generator comes down to how you configure, tune, and operationalize it. This guide covers production-grade GuardDuty deployment.

What GuardDuty Monitors

GuardDuty analyzes multiple data sources to detect threats:

Recommendation: Enable all data sources for production accounts. The incremental cost is minimal compared to the detection coverage.

Extended Threat Detection: AI-Powered Attack Sequences

GuardDuty’s biggest capability addition in recent years is Extended Threat Detection, launched in December 2024. Rather than generating individual findings for isolated events, Extended Threat Detection uses AI/ML to correlate multiple signals across time and services to identify complete attack sequences — the chain of events that constitute a real breach.

How it works:

Instead of alerting on “unusual API call” and “S3 access from new location” as separate findings, Extended Threat Detection identifies that both events belong to the same credential compromise incident and generates a single high-confidence attack sequence finding with the full context:

Attack Sequence: Credential Compromise → Data Exfiltration
  Step 1: 14:32 — API call from known malicious IP (Recon)
  Step 2: 14:35 — IAM privilege escalation attempt (Persistence)
  Step 3: 14:41 — Unusual S3 GetObject burst (Exfiltration)
  Confidence: HIGH | Affected Resources: 3 | Duration: 9 minutes

Extended Threat Detection is free — there is no additional charge beyond standard GuardDuty pricing for the AI/ML correlation layer.

New attack sequence finding types (December 2025): AWS expanded attack sequence findings to cover:

• EC2 attack sequences — Correlates instance compromise, lateral movement, and C2 communication across EC2 workloads
• ECS attack sequences — Container-specific attack chains including container escape, privilege escalation within clusters, and service account abuse

EKS Extended Threat Detection via eBPF (June 2025): GuardDuty Runtime Monitoring for EKS was upgraded to use eBPF-based kernel-level monitoring. This provides:

• System call-level visibility into container behavior without performance degradation
• Detection of container escapes at the kernel level (not just network-observable behavior)
• Runtime threat detection that captures threats invisible to network-based monitoring alone

Finding Types and Severity

GuardDuty generates findings categorized by resource type and threat purpose:

High Severity (Immediate Action Required)

• UnauthorizedAccess:IAMUser/MaliciousIPCaller — API calls from known malicious IP addresses. Indicates compromised credentials.
• CryptoCurrency:EC2/BitcoinTool.B — EC2 instance communicating with Bitcoin mining pools. Common indicator of compromised instances.
• Trojan:EC2/DNSDataExfiltration — EC2 instance performing DNS data exfiltration. Data is being smuggled out via DNS queries.
• Impact:EC2/PortSweep — EC2 instance scanning ports on other hosts. Indicates lateral movement after initial compromise.

Medium Severity (Investigate Promptly)

• Recon:EC2/PortProbeUnprotectedPort — External probing of unprotected ports. May indicate misconfigured security groups.
• UnauthorizedAccess:EC2/SSHBruteForce — SSH brute-force attacks against an instance. Common for internet-facing instances.
• Policy:IAMUser/RootCredentialUsage — Root account used for API calls. Root should never be used for routine operations.

Low Severity (Review During Regular Operations)

• Recon:EC2/Portscan — External port scans targeting your instances. Normal internet noise unless targeted.
• UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B — Successful console login from unusual location. May be legitimate travel.

Multi-Account Deployment

For organizations with multiple AWS accounts (which should be every production organization — see our multi-account strategy guide):

Delegated Administrator Model

Management Account
    └→ Designates Security Account as GuardDuty delegated admin
        └→ Security Account (delegated admin)
            ├→ Automatically enables GuardDuty in all member accounts
            ├→ Aggregates findings from all accounts
            ├→ Manages suppression rules centrally
            └→ Sends findings to centralized SIEM/dashboard

Steps:

1. Enable GuardDuty in the management account
2. Designate a security account as the delegated administrator
3. The delegated admin automatically discovers and enables GuardDuty across all organization accounts
4. New accounts added to the organization are automatically enrolled

This eliminates the need to enable GuardDuty individually in each account and provides centralized visibility.

Automated Response

GuardDuty findings should trigger automated responses for high-severity threats. Manual triage works for medium and low severity, but waiting for human intervention on a crypto mining instance or active data exfiltration is too slow.

EventBridge Integration

GuardDuty publishes all findings to EventBridge, enabling automated workflows:

GuardDuty Finding → EventBridge Rule (filter by severity/type) → Target:
    ├→ Lambda (automated remediation)
    ├→ SNS (team notification)
    ├→ Step Functions (complex workflow)
    ├→ Security Hub (aggregation)
    └→ SIEM (Splunk, Sumo Logic, etc.)

Common Automated Responses

Compromised EC2 instance (crypto mining, C2 communication):

1. Move the instance to a quarantine security group (block all inbound/outbound except forensics access)
2. Capture a memory dump and disk snapshot for forensic analysis
3. Notify the security team via Slack/PagerDuty
4. Do NOT terminate the instance — forensic evidence is needed

Compromised IAM credentials:

1. Disable the access key immediately
2. Revoke all active sessions for the IAM user
3. Notify the security team and the user
4. Begin credential rotation for any services the user accessed

S3 data exfiltration:

1. Add a deny-all bucket policy to stop ongoing exfiltration
2. Enable S3 access logging if not already enabled
3. Identify the IAM principal performing the exfiltration
4. Notify the security team with access log analysis

Step Functions for Complex Remediation

For multi-step remediation that requires judgment:

GuardDuty Finding → EventBridge → Step Functions:
    1. Enrich finding (lookup instance owner, check tags)
    2. Determine severity (high → auto-remediate, medium → notify)
    3. Execute remediation (quarantine, disable keys)
    4. Create incident ticket (Jira, ServiceNow)
    5. Wait for human review (callback task)
    6. Log remediation actions for audit

Step Functions workflow patterns are ideal for security automation because they provide retry logic, audit trails, and human-in-the-loop capabilities.

Tuning and Reducing False Positives

GuardDuty generates false positives — findings that describe legitimate activity. Without tuning, alert fatigue sets in and real threats get ignored.

Suppression Rules

Create suppression rules for known legitimate activity:

• Trusted IP lists — Add your office IPs, VPN endpoints, and CI/CD pipeline IPs to GuardDuty’s trusted IP list. API calls from these IPs will not generate findings.
• Suppression filters — Suppress specific finding types for specific resources. For example, suppress Recon:EC2/Portscan for a security scanning tool that intentionally performs port scans.

Common False Positive Patterns

Tuning Best Practices

• Do not suppress by severity — A high-severity finding is not always a false positive. Suppress by finding type + resource, not by severity level.
• Review suppressions quarterly — Suppression rules can mask real threats if left indefinitely. Review and justify every active suppression.
• Start permissive, then tighten — Enable all detection types first, observe findings for 2-4 weeks, then add suppression rules for confirmed false positives.

GuardDuty Cost

GuardDuty pricing is based on the volume of data analyzed:

Malware Protection for S3 (price reduced February 2025): AWS reduced the price of GuardDuty Malware Protection for S3 by approximately 85%, making it cost-effective to scan all objects uploaded to sensitive buckets. At the pricing effective since February 2025, scanning 1 billion S3 objects costs approximately $90 — previously this would have cost over $600. For security-conscious organizations, enabling S3 malware scanning on upload buckets is economically justified. (Verify current rates at the GuardDuty pricing page as pricing is updated periodically.)

Malware Protection for AWS Backup (November 2025): GuardDuty now integrates with AWS Backup to scan backup vaults for malware. Backups containing infected files are flagged before they are used for restoration — preventing the scenario where you restore from backup and re-infect your environment. This feature is particularly valuable for ransomware defense.

Typical cost: For a mid-size AWS environment (10-20 accounts, moderate API activity), GuardDuty costs $200-$800/month. For large enterprises, $2,000-$10,000/month.

Cost vs. value: A single undetected crypto mining instance can cost thousands of dollars in compute before someone notices. A data breach costs orders of magnitude more. GuardDuty’s cost is trivial relative to the threats it detects.

Integration with Security Hub

GuardDuty findings should flow into Security Hub for centralized security management:

• Security Hub aggregates findings from GuardDuty, Inspector, Macie, Firewall Manager, and third-party tools
• Findings are normalized to the AWS Security Finding Format (ASFF) for consistent processing
• Automated actions can be triggered from Security Hub based on findings from any source
• Compliance standards (CIS Benchmark, PCI DSS, NIST) are evaluated alongside threat findings

For a comprehensive cloud security architecture, GuardDuty is one component in a defense-in-depth strategy. For the full layered security approach — IAM, SCPs, Security Hub automated remediation, and data protection — see our guide on Securing AWS Workloads Beyond the Basics.

Getting Started

Enabling GuardDuty takes minutes. Operationalizing it — tuning findings, building automated responses, and integrating into your security operations workflow — takes weeks. But once operational, GuardDuty provides continuous threat detection with zero infrastructure management.

For GuardDuty deployment and security operations as part of our managed services, or for a broader security architecture review, talk to our team.

Contact us to implement threat detection for your AWS environment →