AWS GuardDuty: Setup, What to Enable, and What the Alerts Actually Mean

GuardDuty is AWS’s managed threat detection service. It analyzes VPC flow logs, DNS logs, CloudTrail events, and other data sources to detect malicious activity and unauthorized behavior in your AWS account.

It’s one of the highest-value security services in AWS — inexpensive relative to what it catches, managed by AWS so there’s nothing to maintain, and deeply integrated with the rest of the AWS security ecosystem. It’s also widely misunderstood: many teams enable it and then ignore the findings, or disable it because “it generates too many alerts.”

Here’s how to actually use it.

What GuardDuty analyzes

GuardDuty ingests and analyzes several data sources:

VPC Flow Logs — Network traffic metadata for your VPCs. GuardDuty uses this to detect port scanning, unusual outbound connections to known malicious IPs, cryptocurrency mining traffic, and data exfiltration patterns. GuardDuty uses its own copy of VPC Flow Logs — you don’t need to enable Flow Logs separately in your account.

DNS Logs — Domain name resolution requests. GuardDuty detects DNS-based command-and-control traffic, domain generation algorithm (DGA) malware activity, and queries to known malicious domains.

CloudTrail management events — AWS API calls. GuardDuty detects suspicious API activity: unusual IAM operations, instance launches in unexpected regions, attempts to disable CloudTrail or GuardDuty itself.

CloudTrail S3 data events (optional, additional cost) — S3 object-level API calls. Detects bucket enumeration, unusual download patterns, and access from unexpected principals.

EKS audit logs (optional) — Kubernetes API server audit logs. Detects container escape attempts, privileged container creation, and unusual RBAC activity.

RDS login events (optional) — Database authentication logs. Detects unusual login patterns and brute-force attempts.

Cost

GuardDuty pricing is based on the data processed:

For a typical mid-size AWS account (moderate traffic, active development), GuardDuty costs $50–200/month. For small accounts: $10–30/month. For high-traffic production: $300–500/month.

AWS provides a 30-day free trial for new GuardDuty activations. The trial includes all findings with estimated cost — use this to understand what your ongoing cost will be before committing.

Enabling GuardDuty

GuardDuty is per-region and per-account. A single-account setup:

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true  # S3 Protection — recommended for accounts with sensitive S3 data
    }
    kubernetes {
      audit_logs {
        enable = true  # EKS Protection — if you run EKS
      }
    }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes {
          enable = true  # Scan EBS on threat detection findings
        }
      }
    }
  }
}

Multi-account and multi-region: In an AWS Organizations setup, designate one account as the GuardDuty administrator. Enable auto-enrollment for member accounts. All findings aggregate in the administrator account.

# In the delegated administrator account
resource "aws_guardduty_organization_admin_account" "main" {
  admin_account_id = data.aws_caller_identity.admin.account_id
}

resource "aws_guardduty_organization_configuration" "main" {
  auto_enable_organization_members = "ALL"
  detector_id                      = aws_guardduty_detector.main.id
}

With auto_enable_organization_members = "ALL", every current and future member account automatically has GuardDuty enabled. No manual per-account setup required.

Understanding finding severity and types

GuardDuty findings are scored from 0.1 to 8.9 (Low: 0.1–3.9, Medium: 4.0–6.9, High: 7.0–8.9).

The finding types are categorized by threat family. The ones that matter most:

Credential theft and misuse

UnauthorizedAccess:IAMUser/MaliciousIPCaller An IAM user made an API call from a known malicious IP address. High severity. Indicates either compromised credentials or an attacker using known infrastructure. Immediate response required.

Recon:IAMUser/MaliciousIPCaller Reconnaissance (listing resources, describing configurations) from a malicious IP. Likely credential reconnaissance before exploitation.

UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B Successful console login from an unusual location — a country or IP range this user has never used. Medium-high severity. May indicate credential compromise or VPN usage — verify with the user.

Cryptocurrency mining

CryptoCurrency:EC2/BitcoinTool.B!DNS An EC2 instance is resolving domain names associated with cryptocurrency mining pools. This is almost always a compromised instance or an unauthorized workload. High severity.

Behavior:EC2/TrafficVolumeUnusual Unusual network traffic volume from an EC2 instance. Often correlated with mining activity or data exfiltration.

Instance compromise

Backdoor:EC2/C&CActivity.B!DNS An EC2 instance is communicating with a known command-and-control domain. The instance is almost certainly compromised. Isolate immediately.

Trojan:EC2/BlackholeTraffic An EC2 instance is trying to communicate with a known sinkhole domain — often associated with malware beaconing to a taken-down C2 infrastructure.

Data exfiltration

Exfiltration:S3/AnomalousBehavior Unusual S3 data access patterns — large downloads, access from unexpected principals, access at unusual times. Check whether the principal and data accessed are expected.

UnauthorizedAccess:S3/MaliciousIPCaller S3 data access from a known malicious IP. Immediate investigation required.

Account takeover

Stealth:IAMUser/CloudTrailLoggingDisabled Someone disabled CloudTrail. This is almost always an attacker trying to cover their tracks after gaining access. Highest priority finding — your audit logs are being tampered with.

Impact:IAMUser/AnomalousBehavior IAM operations that deviate from established patterns — creating admin users, attaching admin policies, creating access keys. Investigate immediately.

Routing findings to your security workflow

GuardDuty findings in the console that no one reads have no operational value. Route them to where your team works.

EventBridge → SNS → Slack (for all findings):

resource "aws_cloudwatch_event_rule" "guardduty_findings" {
  name        = "guardduty-findings"
  description = "Route GuardDuty findings to SNS"

  event_pattern = jsonencode({
    source      = ["aws.guardduty"]
    detail-type = ["GuardDuty Finding"]
  })
}

resource "aws_cloudwatch_event_target" "guardduty_sns" {
  rule      = aws_cloudwatch_event_rule.guardduty_findings.name
  target_id = "SendToSNS"
  arn       = aws_sns_topic.security_alerts.arn
}

High-severity findings → PagerDuty/OpsGenie (for immediate response):

Add a severity filter to the EventBridge rule:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }]
  }
}

Route high-severity findings to an on-call escalation path. Medium findings can go to Slack. Low findings can go to a daily digest.

AWS Security Hub integration:

Enable the GuardDuty → Security Hub integration. Security Hub aggregates findings from GuardDuty, Config, Inspector, Macie, and other services into a single findings dashboard with normalized severity scores. Useful for compliance evidence and centralized triage.

Suppression rules for noise reduction

Some GuardDuty findings are expected behavior in your environment. Suppression rules prevent them from appearing in your active findings:

Common suppression candidates:

• Recon:EC2/PortProbeUnprotectedPort — Internet-facing services legitimately receiving probe traffic
• UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B — Your team uses VPNs in countries GuardDuty doesn’t recognize as typical

Create suppression rules in the GuardDuty console under Findings → Suppression rules. Be specific: suppress by finding type AND resource ID or IP, not by finding type alone. Broad suppressions mask real threats.

Responding to findings

A simple response runbook for the highest-priority finding types:

Compromised EC2 instance (Backdoor:EC2/C&CActivity.B):

1. Isolate the instance — modify its security group to deny all inbound/outbound
2. Take an EBS snapshot for forensic analysis
3. Pull CloudTrail logs for the instance’s IAM role for the past 24 hours
4. Identify what the instance was doing (what role it has, what data it can access)
5. Terminate the instance after snapshotting
6. Rotate any credentials the instance’s role could have accessed

Compromised IAM credentials (UnauthorizedAccess:IAMUser/MaliciousIPCaller):

1. Immediately deactivate the access key(s) for the user
2. If console login: reset the password and revoke active sessions
3. Pull CloudTrail for all actions taken by the compromised principal for the past 7 days
4. Identify any resources created, policies modified, or data accessed
5. Rotate any secrets the compromised user could have read
6. Investigate how the credential was exposed (repo leak, phishing, etc.)

CloudTrail disabled (Stealth:IAMUser/CloudTrailLoggingDisabled):

1. Re-enable CloudTrail immediately
2. Pull VPC Flow Logs for the period CloudTrail was disabled
3. This finding indicates an attacker is covering tracks — assume the account is compromised
4. Escalate to full incident response

GuardDuty and compliance

SOC 2: GuardDuty contributes to CC6 (Logical and Physical Access Controls) and CC7 (System Operations). The combination of GuardDuty + automated alerting satisfies the continuous monitoring control requirement.

PCI DSS v4.0 Requirement 10.7: Requires detection and reporting of failures of critical security controls. GuardDuty findings on CloudTrail changes satisfy this for AWS environments.

HIPAA: GuardDuty contributes to the Technical Safeguards requirements around access controls and audit controls. The GuardDuty → Security Hub → Config integration can provide a consolidated compliance evidence trail.

What to do next

Enable GuardDuty today. The 30-day free trial gives you full visibility at no cost. At the end of the trial, you’ll have a cost estimate and 30 days of findings to evaluate whether the ongoing cost is justified.

It is justified. Every account I’ve enabled GuardDuty on has had findings worth investigating within 30 days.

If you’re setting up a security baseline for SOC 2, PCI, or HIPAA compliance, GuardDuty is one of the first services I recommend.

Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.