How to set up AWS GuardDuty for threat detection

Most teams don't find out their AWS environment is compromised from a dashboard — they find out from a bill, a customer, or an incident responder asking why an EC2 instance in us-east-1 is talking to a crypto-mining pool. AWS GuardDuty exists to close that gap: it's a managed threat detection service that continuously analyzes CloudTrail, VPC Flow Logs, DNS query logs, S3 data events, and EKS audit logs for signs of compromise, without you standing up any infrastructure.

This guide walks through how to set up AWS GuardDuty for threat detection end to end — enabling it account-wide, wiring findings into your alerting pipeline, and triaging what it surfaces — so that by the end you have a working detection layer, not just a green checkmark in the console. We'll also cover the multi-account and supply-chain-specific configuration that most quick-start guides skip.

Step 1: Confirm Prerequisites and Understand What GuardDuty Monitors

Before you touch the console or CLI, know what you're turning on. GuardDuty ingests several signal sources and correlates them against threat intelligence feeds (AWS-managed and, optionally, your own):

• CloudTrail management and data events — API-level anomalies like unusual IAM calls, disabled logging, or credential exfiltration attempts.
• VPC Flow Logs — network-level indicators such as communication with known command-and-control infrastructure.
• DNS logs — lookups to malicious or algorithmically generated domains.
• S3 data events — unusual access patterns, public exposure attempts, or requests from Tor exit nodes.
• EKS audit logs and runtime monitoring — container escape attempts and suspicious process activity.
• Malware Protection — agentless scanning of EBS volumes attached to flagged EC2 instances or containers.

You'll need an IAM principal with guardduty:* permissions (or a scoped policy limited to the actions below), and if you're managing multiple accounts, access to AWS Organizations. There's no infrastructure to provision — GuardDuty is fully managed — so most of the setup work is configuration, not deployment.

Step 2: Set Up AWS GuardDuty in Your Primary Region

GuardDuty is regional, so you need to enable it in every region you operate in — attackers count on teams forgetting the regions they don't actively use. Start with your primary region via the console (GuardDuty > Get Started > Enable GuardDuty) or, for repeatability, via the CLI:

aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --region us-east-1

Set --finding-publishing-frequency to FIFTEEN_MINUTES rather than the default six hours if you want near-real-time alerting — this matters once you wire findings into on-call tooling in Step 5. Confirm the detector is active:

aws guardduty list-detectors --region us-east-1
aws guardduty get-detector --detector-id <detector-id> --region us-east-1

Repeat this for every region in use, or better, script it across the full region list so nothing is missed:

for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES --region "$region"
done

Step 3: Enable GuardDuty Data Sources and Protection Plans

Enabling the detector alone gives you foundational threat detection from CloudTrail and network logs. To get full coverage, turn on the additional protection plans explicitly — they aren't all on by default and each has its own cost model:

aws guardduty update-detector \
  --detector-id <detector-id> \
  --features '[
    {"Name":"S3_DATA_EVENTS","Status":"ENABLED"},
    {"Name":"EKS_AUDIT_LOGS","Status":"ENABLED"},
    {"Name":"EBS_MALWARE_PROTECTION","Status":"ENABLED"},
    {"Name":"RDS_LOGIN_EVENTS","Status":"ENABLED"},
    {"Name":"LAMBDA_NETWORK_LOGS","Status":"ENABLED"}
  ]'

For teams focused on software supply chain risk specifically, prioritize S3_DATA_EVENTS (catches exfiltration from artifact and build-cache buckets), LAMBDA_NETWORK_LOGS (catches compromised CI/CD functions phoning home), and EKS_AUDIT_LOGS if your build agents or runners live in Kubernetes. This is the part of aws threat detection setup that most teams skip because it's not the default — and it's exactly where CI/CD compromise tends to show up first.

Step 4: Extend Coverage Across Your AWS Organization

If you run more than one AWS account — and most organizations with a real CI/CD pipeline do — enable GuardDuty centrally rather than account by account. Designate a delegated administrator account from your Organizations management account:

aws guardduty enable-organization-admin-account \
  --admin-account-id <security-account-id>

Then, from the delegated admin account, configure auto-enrollment so new accounts inherit protection automatically:

aws guardduty update-organization-configuration \
  --detector-id <detector-id> \
  --auto-enable-organization-members ALL \
  --features '[
    {"Name":"S3_DATA_EVENTS","AutoEnable":"ALL"},
    {"Name":"EKS_AUDIT_LOGS","AutoEnable":"ALL"},
    {"Name":"EBS_MALWARE_PROTECTION","AutoEnable":"ALL"}
  ]'

This is the piece that keeps your detection coverage from silently degrading as teams spin up new accounts for new products, sandboxes, or acquisitions — a common blind spot that never gets caught until an audit or an incident.

Step 5: Route Findings to EventBridge, SNS, and Your SIEM

GuardDuty findings that only live in the console don't get triaged — they get ignored. Every finding is automatically emitted to Amazon EventBridge, so route it somewhere a human or automation will actually see it:

aws events put-rule \
  --name guardduty-findings-to-sns \
  --event-pattern '{"source": ["aws.guardduty"]}'

aws events put-targets \
  --rule guardduty-findings-to-sns \
  --targets "Id"="1","Arn"="arn:aws:sns:us-east-1:123456789012:guardduty-alerts"

For teams with a SIEM (Splunk, Datadog, Sumo Logic, or a security data lake), forward high- and medium-severity findings via EventBridge to a Kinesis Firehose or Lambda function that normalizes and ships them onward. Filter on severity in the event pattern so low-severity noise doesn't flood on-call channels:

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

Step 6: Triage and Respond to GuardDuty Findings

Once findings are flowing, you need a repeatable guardduty findings triage process, or the alerts become background noise within a week. A workable baseline:

1. Classify by finding type prefix. UnauthorizedAccess:*, CredentialAccess:*, and Exfiltration:* findings warrant immediate review; Recon:* findings are often lower urgency unless paired with other activity.
2. Correlate against known change activity. Check whether the flagged resource, IAM principal, or IP corresponds to a recent deploy, a known scanner, or an approved pen test window.
3. Pull the affected resource's recent CloudTrail history to see what else that principal or instance did before and after the flagged event.
4. Archive or suppress confirmed false positives rather than deleting them, so you retain an audit trail:

aws guardduty update-findings-feedback \
  --detector-id <detector-id> \
  --finding-ids <finding-id> \
  --feedback USEFUL

5. Escalate confirmed threats into your incident response process, isolating the affected resource (revoke credentials, quarantine the instance's security group) before deeper investigation.

Assign clear ownership for this queue — GuardDuty is only as effective as the team that reviews its output.

Step 7: Tune Suppression Rules and Trusted Lists

Out of the box, GuardDuty will flag your own vulnerability scanners, known corporate VPNs, and expected automation as suspicious. Reduce noise with suppression rules and trusted IP lists rather than ignoring findings wholesale:

aws guardduty create-filter \
  --detector-id <detector-id> \
  --name suppress-known-scanner \
  --finding-criteria '{"Criterion":{"resource.instanceDetails.tags.value":{"Eq":["approved-scanner"]}}}' \
  --action ARCHIVE

Upload a trusted IP list (your NAT gateways, VPN endpoints, and scanner ranges) so GuardDuty stops generating findings for expected traffic:

aws guardduty create-ip-set \
  --detector-id <detector-id> \
  --name trusted-corporate-ips \
  --format TXT \
  --location s3://your-security-bucket/trusted-ips.txt \
  --activate

Revisit these lists quarterly — stale trusted-IP entries are themselves a common way real threats get suppressed by accident.

Verification and Troubleshooting

Before you consider the rollout done, verify it actively:

• Generate a sample finding to confirm the full pipeline — detector to EventBridge to SNS/SIEM — actually works: aws guardduty create-sample-findings --detector-id <detector-id> --finding-types Backdoor:EC2/C&CActivity.B!DNS.
• No findings appearing at all? Check that the detector status is ENABLED per region (get-detector), that CloudTrail is itself enabled in that region, and that your EventBridge rule's event pattern isn't over-filtered.
• Findings not reaching Slack/PagerDuty? Confirm the SNS topic policy allows EventBridge to publish, and that any Lambda transformer in the chain isn't silently erroring — check its CloudWatch Logs.
• Suspiciously few findings from a busy account? Confirm all relevant protection plans (S3, EKS, Malware Protection) are actually ENABLED and not just the base detector — this is the single most common half-finished setup.
• New accounts not inheriting settings? Re-check update-organization-configuration — auto-enable-organization-members must be set to ALL, and per-feature AutoEnable flags are independent of the top-level setting.

How Safeguard Helps

GuardDuty tells you when something in your AWS environment is behaving like a compromise — but for software supply chain teams, the harder question is usually how did that behavior get there in the first place. Safeguard sits upstream of the runtime signals GuardDuty analyzes, giving you visibility into the build pipelines, dependencies, and CI/CD identities that most often turn into the IAM anomalies and exfiltration attempts GuardDuty eventually flags.

In practice, that means Safeguard helps you correlate a GuardDuty finding on a Lambda function or build-agent instance back to the specific commit, package, or pipeline change that introduced the exposure — turning a triage queue of isolated findings into an investigation with a clear root cause. Combined with a properly tuned GuardDuty deployment, that closes the loop from detection to remediation across both your runtime and your software supply chain.