Amazon GuardDuty: What It Is and When to Use It

Definition

Amazon GuardDuty is a managed threat-detection service that continuously analyzes AWS data sources — AWS CloudTrail management and S3 data events, Amazon VPC Flow Logs, and DNS query logs from Amazon's VPC DNS resolver — along with workload-specific signals from EKS audit logs, RDS login events, Lambda invocations, and EBS volumes. It uses machine learning, anomaly detection, and curated threat-intelligence feeds to surface findings (prioritized security alerts) that indicate compromised credentials, reconnaissance, cryptocurrency mining, data exfiltration, malware on instances, and other threats.

Crucially, GuardDuty does this without requiring you to install agents on EC2 instances, deploy additional infrastructure, or manage log pipelines. You enable it at the account (and optionally Organization) level, and findings start arriving in minutes.

How It Works

GuardDuty is a fully managed detection engine with three building blocks:

1. Foundational data sources (included in base pricing) — AWS CloudTrail management events, VPC Flow Logs, and Route 53 (VPC resolver) DNS query logs. GuardDuty consumes these directly from AWS — you don't have to enable logging on your side, and GuardDuty doesn't charge you for the underlying log service usage.
2. Detection logic — a combination of managed threat-intelligence feeds (AWS, CrowdStrike, Proofpoint, and more), anomaly detection baselines per account/resource, and ML models for behaviors like credential exfiltration, unusual API calls, port scanning, and reconnaissance.
3. Protection plans (optional add-ons, billed separately):
   • EKS Protection — analyzes Kubernetes audit logs for API-level threats (admin token misuse, privileged pod creation, etc.).
   • EKS Runtime Monitoring — runtime signals from an AWS-managed agent on EKS worker nodes (process, network, and file activity).
   • S3 Protection — S3 data events to detect suspicious object-level access patterns.
   • Malware Protection for EC2 — agentless scanning of EBS volumes attached to an EC2 instance when a finding indicates potential compromise.
   • Malware Protection for S3 — on-upload scanning of objects written to configured buckets.
   • RDS Protection — login/audit events from Amazon Aurora and RDS to catch suspicious DB sign-ins.
   • Lambda Protection — network activity analysis for Lambda functions inside VPCs.

Findings are classified by severity (Low, Medium, High) and a 1–10 score, and include the affected resource, the detection type (e.g., UnauthorizedAccess:EC2/SSHBruteForce, CryptoCurrency:EC2/BitcoinTool.B!DNS), context (IP, geolocation, targeted user), and remediation guidance. They flow to Amazon EventBridge in near-real time — typically within 5 minutes — and are also published to AWS Security Hub when enabled.

Key Features and Limits

• Data sources consumed automatically — CloudTrail, VPC Flow Logs, DNS logs; GuardDuty does not require you to enable or pay for these logs separately.
• Finding types — 100+ managed finding types covering reconnaissance, instance compromise, account compromise, bucket compromise, EKS threats, malware, and more.
• Multi-account — integrates with AWS Organizations so a delegated administrator account enables and manages GuardDuty across every account, with automatic enrollment of new accounts.
• EventBridge integration — each finding is a well-structured event enabling automated response (Lambda remediation, SNS alerts, ticket creation).
• Security Hub integration — findings appear alongside Config, Inspector, Macie, and third-party findings for unified prioritization.
• Custom threat lists — you can supply IP-based trusted lists (up to 6, 2,000 entries each) and threat lists (up to 6, 250,000 entries each) per detector.
• Suppression rules — filter out known-benign findings (for example, pentest traffic) to keep the console focused.
• 30-day free trial per Region per account covers all data sources and most protection plans, so you can size costs before committing.
• Regional service — findings are Region-scoped; enable GuardDuty in every Region where you have workloads (or use Organizations to auto-enable).
• Runtime agent — EKS and ECS runtime monitoring use an AWS-managed eBPF-based agent; EC2 runtime monitoring was added in 2024.

Common Use Cases

1. Credential compromise detection — surfaces CredentialAccess:IAMUser/* and UnauthorizedAccess:IAMUser/* findings when access keys are used from anomalous IPs or Tor exit nodes.
2. Cryptocurrency mining detection — CryptoCurrency:EC2/BitcoinTool.B!DNS and related finding types catch DNS queries or network patterns indicative of mining on EC2/EKS.
3. Malware on EC2 — triggered by suspicious network activity, GuardDuty initiates agentless EBS snapshot scans via the Malware Protection for EC2 plan.
4. S3 data exfiltration — S3 Protection catches unusual object enumeration or bulk-copy patterns and anomalous bucket permissions changes.
5. Kubernetes threat detection — EKS Protection flags suspicious exec into pods, privileged pod creation, service account token abuse, and risky API calls.
6. Automated remediation via EventBridge — disable a suspected IAM user, isolate an EC2 instance by removing it from its security group, snapshot and quarantine volumes, or page on-call.

Pricing Model

GuardDuty has separate per-Region, per-account pricing for each data source and protection plan. Base charges:

• CloudTrail event analysis — per 1 million events, with tiered per-million pricing.
• VPC Flow Logs and DNS logs — per GB analyzed.
• EKS audit log monitoring — per 1 million audit events.
• Runtime Monitoring (EKS/ECS/EC2) — per vCPU-hour.
• S3 Protection — per 1 million S3 data events.
• Malware Protection for EC2 — per GB scanned on EBS snapshots.
• Malware Protection for S3 — per GB scanned + per 1,000 objects.
• RDS Protection — per 1 million RDS login events.
• Lambda Protection — per 1 million Lambda invocations inside VPCs.

A 30-day free trial per Region gives full-feature access (including most protection plans) so you can gauge costs. The AWS Free Tier does not include GuardDuty beyond the initial trial. Cost-optimization tips: enable only the protection plans relevant to your workloads (skip EKS if you don't use EKS); use Organizations delegated admin to consolidate management; use suppression rules to dampen noisy but expected findings.

Pros and Cons

Pros

• Agentless for all foundational detections; runtime monitoring adds agents only where needed.
• Broad coverage — accounts, workloads, storage, databases, Kubernetes — without stitching together multiple tools.
• EventBridge + Security Hub integration enables response automation out of the box.
• Organizations-wide enablement with delegated administrator makes multi-account rollout trivial.

Cons

• Pricing is multi-dimensional (per-source and per-plan), so large environments require careful forecasting.
• False-positive findings happen, especially around legitimate pentesting, security scanning, or unusual deploys — tuning via suppression rules and trusted IP lists is ongoing.
• GuardDuty detects; it does not respond on its own — you still need Lambda/SSM-Automation playbooks for remediation.
• Coverage is as good as the data sources you enable; if you skip a protection plan, you also skip its detections.

Comparison with Alternatives

| Feature | Amazon GuardDuty | Amazon Inspector | Amazon Macie | | --- | --- | --- | --- | | Primary purpose | Threat detection (runtime & behavioral) | Vulnerability assessment (CVE, config) | Sensitive data discovery in S3 | | Data sources | CloudTrail, VPC Flow, DNS, EKS, S3, RDS, Lambda, EBS | EC2 OS packages, ECR images, Lambda code | S3 objects | | Output | Findings (threats) | Findings (vulnerabilities) | Findings (PII/PHI/secrets in S3) | | Agentless? | Foundational yes; runtime agent for EKS/ECS/EC2 | SSM-agent based for EC2 | Yes |

Exam Relevance

GuardDuty is a frequent topic on:

• Solutions Architect Associate (SAA-C03) — choosing GuardDuty for continuous threat detection vs Inspector for vulnerabilities.
• Security Specialty (SCS-C02) — data sources, protection plans, Organizations delegated admin, EventBridge-driven automated response, suppression rules, trusted IP/threat lists.
• SysOps Administrator (SOA-C02) — enabling GuardDuty, interpreting findings severity, pushing findings to Security Hub.
• Cloud Practitioner (CLF-C02) — high-level awareness of GuardDuty as AWS's managed threat-detection service.

Classic exam trap: confusing GuardDuty (behavioral threat detection from logs and runtime signals) with Amazon Inspector (vulnerability and configuration scans of EC2/ECR/Lambda) and Amazon Macie (sensitive-data discovery in S3). If a question mentions cryptomining, compromised credentials, port scanning, or anomalous API calls, the answer is GuardDuty. If it mentions CVEs or unpatched OS packages, the answer is Inspector. If it mentions PII/PHI in S3 buckets, the answer is Macie.

Frequently Asked Questions

Q: What data sources does Amazon GuardDuty analyze?

A: GuardDuty's foundational data sources are AWS CloudTrail management events, Amazon VPC Flow Logs, and DNS query logs from the VPC DNS resolver — all consumed automatically without requiring you to enable or pay for the underlying log services. Optional protection plans add EKS audit logs, EKS/ECS/EC2 runtime signals (via an AWS-managed agent), S3 data events, EBS volume scans (Malware Protection for EC2), S3 object scans (Malware Protection for S3), RDS login events, and Lambda network activity.

Q: How do I respond to GuardDuty findings automatically?

A: GuardDuty publishes every finding to Amazon EventBridge as a structured event within about 5 minutes. You define EventBridge rules that pattern-match findings (by type, severity, resource, etc.) and route them to targets — an AWS Lambda function for custom remediation (e.g., quarantining an EC2 instance by changing its security group, disabling an IAM user's access keys), an SNS topic for paging, an SSM Automation document, or a third-party SIEM/ticketing system. Enabling AWS Security Hub additionally aggregates findings alongside Inspector, Config, and partners for unified workflows.

Q: How is GuardDuty different from Amazon Inspector and Amazon Macie?

A: All three are AWS security services but they answer different questions. GuardDuty detects active threats and suspicious behavior from logs and runtime signals — cryptomining, compromised credentials, port scanning, malware. Amazon Inspector performs vulnerability assessment on EC2 OS packages, ECR container images, and Lambda functions, finding known CVEs and insecure configurations. Amazon Macie performs sensitive data discovery in Amazon S3, flagging PII, PHI, credentials, and other sensitive content. They are complementary: GuardDuty answers "is anything happening that looks malicious," Inspector answers "am I vulnerable," and Macie answers "where is my sensitive data."

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon GuardDuty documentation before making production decisions.