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.

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:

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.

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 →