Detect Threats with GuardDuty

Imagine the worst Friday night in your career: your AWS account is under attack, and you only find out when your bill doubles. You can't watch every CloudTrail log, every VPC flow, and every DNS query by hand—there's simply too much data. That's where AWS GuardDuty comes in: it's the security guard that never sleeps, continuously monitoring your AWS environment for suspicious activity and alerting you before a small anomaly turns into a full-blown breach. In this lesson, you'll learn the basics of GuardDuty and how to use it to detect threats in your cloud account.

The problem this lesson solves

Manual threat detection is impossible at cloud scale. Your environment generates millions of events—API calls, network connections, and data access patterns—every day. Sifting through that noise to find real threats is like searching for a needle in a haystack armed only with a flashlight. Meanwhile, attackers are automating their scans and exploits, chipping away at misconfigurations or leaked credentials. Without an automated detection layer, you'll miss the early warning signs of intrusion, lateral movement, or data exfiltration. AWS GuardDuty exists to give you a 'radar' that sweeps your entire account continuously, separating the benign from the malicious so you can respond fast.

Core concept / mental model

Think of GuardDuty as a security camera system for your AWS environment. It's not a firewall that blocks traffic and not a compliance scanner that checks for weak passwords. It's a threat detection service that analyzes streams of data from three main sources:

• AWS CloudTrail events (API activity)
• VPC Flow Logs (network traffic)
• DNS logs (domain resolution)

GuardDuty feeds these into its threat intelligence and machine learning engines. It compares your activity against known malicious IPs, domains, and behavioral baselines that it builds per account. When something deviates—say, an EC2 instance starts communicating with a known command-and-control server—GuardDuty raises a finding. A finding is a concrete, prioritized alert with context: what happened, which resource is affected, how severe it is, and what to do next.

This is not a 'set and forget' service—you still own the response. GuardDuty detects; you decide how to remediate. Whether that's automated (via EventBridge) or manual (via the console), the mental model is detect > prioritize > respond.

How it works step by step

The step-by-step flow of GuardDuty detecting threats is:

1. Enable GuardDuty in your AWS account (per region).
2. GuardDuty automatically starts ingesting: - CloudTrail management events (e.g., console logins, IAM changes) - VPC Flow Logs (network connections) - DNS query logs - (Optional) Amazon EKS audit logs, RDS login events, and S3 data events if you enable those:
3. The service applies threat intelligence (known bad IPs, domains) and machine learning (anomaly detection based on your activity patterns) to this stream.
4. When a match or anomaly is detected, GuardDuty creates a finding with severity: Low, Medium, or High.
5. Findings are aggregated on the GuardDuty console and optionally sent to Amazon EventBridge (formerly CloudWatch Events) to trigger automations, such as an SNS notification or a Lambda function that responds automatically.
6. You review the finding details, assess impact, and take remediation steps (e.g., isolate an instance, rotate keys).

This takes minutes from detection to notification—not hours that manual log review would need.

Hands-on walkthrough

Let's get our hands dirty. You'll enable GuardDuty, generate a test finding, and verify the alert pipeline.

Prerequisites

• AWS account with sufficient permissions (you'll need guardduty:CreateDetector, iam:PassRole, etc.)
• AWS CLI installed and configured
• Optionally, the aws-guardduty-tester tool or access to EC2 for simulating malicious activity

Step 1: Enable GuardDuty via CLI

# Create a detector (this enables GuardDuty in the current region)
aws guardduty create-detector --enable

# Output will include a detector ID - copy it for later use.

Pro Tip: Use --finding-publishing-frequency FIFTEEN_MINUTES to get alerts faster during testing, but default SIX_HOURS is fine for production to reduce noise.

Step 2: List detectors to confirm it's enabled

aws guardduty list-detectors
# Output:
# {
#   "DetectorIds": ["a1b2c3d4e5f6..."]
# }

Step 3: Generate a test finding

You can manually create a test finding in the GuardDuty console (look for the 'Generate sample findings' button in the Settings tab). This creates sample findings like UnauthorizedAccess:EC2/SSHBruteForce. Alternatively, if you want a real-ish finding, you can use the open-source aws-guardduty-tester tool, which launches an EC2 instance and simulates traffic to a known bad IP. But for learning purposes, sample findings are perfect.

Step 4: Verify the finding

Once the sample finding is generated, check it:

# Replace <region> with your region and <detector-id> with your detector ID
aws guardduty list-findings --detector-id <detector-id>

# Then get details for a specific finding ID
aws guardduty get-findings --detector-id <detector-id> --finding-ids <finding-id>

You'll see JSON with fields like Type (e.g., UnauthorizedAccess:EC2/SSHBruteForce), Severity, Resource (the affected EC2), and Description. This is your detection signal.

Step 5: Set up an alert notification (optional)

To get notified in real-time, create an SNS topic and subscribe your email, then configure EventBridge to send GuardDuty findings to that topic:

# Create an SNS topic and subscribe (adjust email)
aws sns create-topic --name GuardDutyAlerts
aws sns subscribe --topic-arn arn:aws:sns:us-east-1:123456789012:GuardDutyAlerts --protocol email --notification-endpoint you@example.com

# Confirm the email subscription, then create an EventBridge rule
# (You can do this via console or CLI - see AWS docs for the exact commands)

Now you'll get an email the moment GuardDuty detects something.

Compare options / when to choose what

GuardDuty isn't your only detection tool. Here's how it stacks up against alternatives:

When to choose GuardDuty: If you need a managed, baseline detection layer with minimal setup, GuardDuty is the default. It's often enabled first before anything else. When to pair with Security Hub: Security Hub gives you a single pane of glass across GuardDuty, Inspector, and other services. When to go custom: If you have niche detection needs (e.g., specific IAM patterns), you might add Lambda rules, but you should still use GuardDuty as the foundation. When to use a SIEM: Only when you have compliance requirements that demand centralized log management and correlation beyond AWS-native services.

Troubleshooting & edge cases

Edge cases to watch: - Multiple regions: GuardDuty is regional. Enable it in each region you use, or use AWS Organizations to enable across accounts. - Data sources: VPC Flow Logs are enabled by default but can be disabled; you may see fewer network findings if disabled.

What you learned & what's next

You've learned that GuardDuty is a continuous threat detection service that uses machine learning and threat intelligence to analyze CloudTrail, VPC Flow, and DNS logs—turning raw events into prioritized findings. You've enabled it, generated sample findings, and verified the alert pipeline, proving you can detect threats with GuardDuty basics. This is the foundation for the next lesson, where you'll learn how to create automated responses to GuardDuty findings using EventBridge and Lambda, turning detection into prevention. Keep your radar on—your cloud depends on it.