AWS GuardDuty Setup: Complete Configuration Guide for Threat Detection

Amazon GuardDuty is the closest thing AWS has to a fully managed threat detection service. Enable it, point it at the right data sources, and it will detect credential compromise, network threats, and unauthorized resource provisioning without requiring you to write a single detection rule. The catch is that GuardDuty defaults are not production defaults — you have to make deliberate choices about which protection plans to enable, how to handle multi-account deployments, and what to do when findings arrive.

This guide walks through every GuardDuty configuration decision that matters in practice: initial setup, multi-account delegated administrator configuration, protection plan selection, finding export, and the integration points that make GuardDuty operationally useful rather than just technically enabled.

Enabling GuardDuty: Start Here

GuardDuty is regional. You must enable it in every AWS region where you run workloads — and in regions where you don't run workloads, because attackers provisioning resources in unused regions is a common pattern. Use the GuardDuty console's auto-enable feature or deploy via CloudFormation to ensure all-region coverage from the start.

For single-account environments, enabling GuardDuty through the console takes under five minutes. Navigate to the GuardDuty console, accept the 30-day free trial, and GuardDuty immediately begins analyzing CloudTrail management events, VPC Flow Logs, and DNS query logs. These three data sources are included in the base price and require no additional configuration. The trial gives you 30 days of threat detection data to evaluate costs before billing begins.

Do not skip regions to reduce cost. GuardDuty pricing is based on data volume analyzed, and unused regions generate minimal data — making coverage cheap. A compromised account that provisions a GPU mining rig in ap-southeast-2 because your organization never runs workloads there will generate GuardDuty findings only if GuardDuty is enabled in that region.

Multi-Account Deployment via Delegated Administrator

For organizations using AWS Organizations, the delegated administrator model is the only approach that makes multi-account threat detection operationally manageable. Designate a security account — separate from your management account — as the GuardDuty delegated administrator. This account receives all findings from every member account in the organization, with no per-account configuration required.

The setup requires two steps. First, from the AWS Organizations management account, register the security account as the GuardDuty delegated administrator using the EnableOrganizationAdminAccount API call or the console. Second, in the delegated administrator account, enable the auto-enable setting so that GuardDuty is automatically enabled in every new account added to the organization.

Member accounts see their own findings in their own GuardDuty console, but cannot modify the organization-level configuration. The delegated administrator sees all findings across all accounts. This centralization is essential for detecting attacks that move across account boundaries — a pattern that appears in both insider threat scenarios and sophisticated external attacks.

Protection Plans: What to Enable and What to Skip

Beyond the three included data sources, GuardDuty offers additional protection plans that analyze specialized AWS services. Each carries incremental cost, so the decision of which to enable should be deliberate.

S3 Protection analyzes CloudTrail data events for S3 operations. It detects anomalous object access patterns, access from unusual geographic locations, and access by identities that have no history of interacting with a bucket. For organizations storing sensitive data in S3 — most organizations — S3 Protection is worth enabling. The cost is based on the volume of S3 data events analyzed, which can be significant in high-throughput environments.

EKS Protection includes two components: audit log monitoring (analyzing Kubernetes API server audit logs for suspicious activity) and runtime monitoring (an agent-based approach that detects threats within running containers). Enable audit log monitoring for any EKS cluster in production. Runtime monitoring requires deploying the GuardDuty agent via EKS add-on and is valuable for environments with elevated container compromise risk.

RDS Protection monitors login activity on RDS databases and Aurora clusters. It detects brute force login attempts, unusual user behavior, and access from unexpected IPs. The overhead is minimal and the signal quality is good — enable this for any database containing sensitive data.

Lambda Protection analyzes network activity from Lambda functions to detect communications with known malicious endpoints and unusual network patterns. Useful for environments with many Lambda functions that make external network calls.

Malware Protection scans EBS volumes attached to EC2 instances when a relevant GuardDuty finding fires. It does not run continuous background scans — it triggers on demand when GuardDuty detects suspicious behavior. The cost is per GB scanned and is only incurred when a scan runs.

Finding Export and Integration

GuardDuty findings are stored in the service for 90 days. For longer retention and integration with your alerting stack, configure finding export. GuardDuty can publish findings to an S3 bucket in GZIP-compressed JSON format, and findings automatically appear in Amazon EventBridge as events.

EventBridge is the primary integration point for operational response. Create EventBridge rules that match GuardDuty findings by severity — HIGH and CRITICAL findings route to PagerDuty or SNS for immediate response; LOW and MEDIUM findings route to a Slack channel for review. Configure the rule to pass finding details including the affected resource, source IP, and finding type to the notification payload so responders have context without needing to open the GuardDuty console.

Security Hub automatically ingests GuardDuty findings when both services are enabled in the same account. This provides a single dashboard for security findings across GuardDuty, Config, Inspector, and other services — a significant operational advantage over managing each service's console separately.

Suppression Rules to Reduce Noise

GuardDuty generates false positives, particularly for organizations with unusual but legitimate operational patterns. Security scanning tools trigger reconnaissance findings. NAT gateways generate network findings. Automation roles generate unusual API call findings. Suppress these known patterns using GuardDuty suppression rules rather than ignoring all alerts.

Suppression rules filter findings from the current findings view without deleting them. Suppressed findings remain in your finding history and are exported to S3 if you have export enabled — preserving the audit trail while keeping your active findings queue clean. Write suppression rules narrowly: suppress a specific finding type from a specific resource, not all findings of a given type.

Related Reading

• AWS security monitoring tools compared — how GuardDuty fits into the full monitoring stack
• IAM security monitoring — detecting root logins, MFA gaps, and policy drift
• Multi-account monitoring — unified visibility across your AWS Organization
• GuardDuty finding types and response playbooks — what to do when findings fire

FAQ

Does GuardDuty slow down my AWS environment?

No. GuardDuty analyzes copies of log data — CloudTrail events, VPC Flow Logs, DNS query logs — without any agents on your instances or any in-line interception of API calls. There is no latency impact on your workloads. The only resources GuardDuty creates in your account are a service-linked role and some internal configuration resources.

How much does GuardDuty cost?

The base GuardDuty service (CloudTrail management events, VPC Flow Logs, DNS query logs) is priced per million events and per GB of Flow Log data analyzed, with a 30-day free trial. Protection plans add incremental cost based on their specific data sources. In practice, a small-to-medium AWS account typically costs $5–$50/month for GuardDuty with base protection. Use the GuardDuty cost estimation feature in the console to project costs before enabling additional protection plans.

Can I use GuardDuty in a single account without AWS Organizations?

Yes. GuardDuty works fully in single-account environments. The multi-account features (delegated administrator, auto-enable for new accounts) require AWS Organizations, but the core threat detection functionality is available to any account. If you later move to a multi-account organization structure, you can adopt the delegated administrator model at that point.

How do I handle GuardDuty findings in accounts I don't control?

If you are monitoring AWS accounts owned by clients or external teams, the delegated administrator model requires that you accept a member account invitation, which requires cooperation from the account owner. The Vigilare Terraform module automates this onboarding process, provisioning the cross-account trust and GuardDuty membership with a single deployment.

What is the difference between GuardDuty Malware Protection and Amazon Inspector?

GuardDuty Malware Protection scans EBS volumes for malware after a suspicious GuardDuty finding triggers the scan — it is reactive and event-driven. Amazon Inspector continuously evaluates running instances and container images for known software vulnerabilities (CVEs) and network exposure risks — it is proactive and persistent. They serve different purposes and should both be enabled in security-conscious environments.