---
title: Amazon GuardDuty Pricing: Nine Data Sources, One Compounding Bill
description: GuardDuty bills across nine separate data sources — CloudTrail management events at $4/M tiered down, VPC Flow Logs at $1/GB tiered, EKS Runtime Monitoring per vCPU-hour, plus S3, DNS, Lambda, RDS, and Malware Protection. The 30-day free trial regularly hides the true production bill, and organization-wide auto-enable turns every new account into a billing line.
url: https://www.factualminds.com/blog/amazon-guardduty-pricing-data-sources-multi-account/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-06-13T00:00:00.000Z
author: palaniappan-p
category: Cost Optimization & FinOps
tags: aws-guardduty, guardduty-pricing, aws-pricing, cost-optimization, finops, security
---
# Amazon GuardDuty Pricing: Nine Data Sources, One Compounding Bill
> GuardDuty bills across nine separate data sources — CloudTrail management events at $4/M tiered down, VPC Flow Logs at $1/GB tiered, EKS Runtime Monitoring per vCPU-hour, plus S3, DNS, Lambda, RDS, and Malware Protection. The 30-day free trial regularly hides the true production bill, and organization-wide auto-enable turns every new account into a billing line.
import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingDimensionTable from '~/components/blog/PricingDimensionTable.astro';
import BillSurpriseCallout from '~/components/blog/BillSurpriseCallout.astro';
import PricingDecisionCard from '~/components/blog/PricingDecisionCard.astro';
Amazon GuardDuty looks like a single security service with a single subscription fee. It is actually a portfolio of nine independent threat-detection data sources, each metered separately and most billed at tiered per-unit rates that drop with volume but compound across data sources and across the accounts in your AWS Organization. The 30-day free trial — enabled per data source per account — routinely understates the true production bill by a wide margin.
This post is the bill story. For threat-detection architecture, finding triage, and the operational integration with Security Hub and incident response, see our [GuardDuty threat detection production guide](/blog/aws-guardduty-threat-detection-production-guide/).
## The Nine GuardDuty Data Sources
## The Free Trial Trap
GuardDuty's free trial is generous and counterintuitive: 30 days per data source per account, free of any data-volume cost. Enable everything on day one and validate the operational integration during the trial.
The trap: the bill projection in the GuardDuty console (which estimates the per-month cost based on the data volumes observed during the trial) is the only signal of what the production bill will look like. Teams that don't check it before the trial expires get the full bill at day 31 with no warning.
Before enabling GuardDuty on a new account or new data source, check the projected monthly cost via the GuardDuty
console's Usage page. This shows the actual data volumes observed and the projected bill at production rates. Use this
to make the data-source-by-data-source decision: enable, defer, or scope down. The trial is not a "free version of
GuardDuty"; it is a free preview that ends abruptly.
## Runtime Monitoring: The Per-vCPU-Hour Multiplier
EKS Runtime Monitoring (and the equivalent for ECS Fargate and EC2) is the most expensive data source on most container-heavy bills. The rate is ~$0.008/vCPU-hour, which sounds small until you compute it across a real cluster:
- 200-node EKS cluster, each node 8 vCPU = 1,600 vCPU
- 1,600 vCPU × 730 hours/month × $0.008 = $9,344/month
That is for a single production cluster. Multi-cluster, multi-region, multi-account deployments compound the line.
The mitigations:
1. **Production-only.** Skip Runtime Monitoring on dev, staging, and ephemeral CI clusters. The runtime threat detection value does not justify the per-vCPU rate in these environments.
2. **Public-facing workloads only.** Enable Runtime Monitoring on internet-facing workloads where the attack surface is largest; skip on internal back-office services.
3. **Spot-instance-friendly sizing.** Right-size nodes to reduce vCPU footprint; Runtime Monitoring bills on actual vCPU running, not provisioned vCPU.
Most teams enable Runtime Monitoring at the organization level for security parity, which auto-enables it on every
cluster including dev/staging. Scope at the cluster level instead — production clusters yes, others no — and use
Kubernetes labels to distinguish in your IaC. The security posture remains strong; the bill drops by half or more.
## CloudTrail Management Events: The Multi-Account Multiplier
CloudTrail management events are GuardDuty's most consistent line item — every API call analyzed regardless of source. The pricing is tiered:
- First 500M events: $4/M
- Next 2B events (500M–2.5B): $2/M
- Above 2.5B events: $1/M
At organization scale, the tier-down helps but the absolute bill remains substantial. An organization with 200 accounts, each generating 50M management events/month, hits 10B events — $11K/month from the CloudTrail data source alone in GuardDuty (separate from CloudTrail's own bill).
The mitigation: tier-down planning. The first tier ($4/M) on a per-account basis is where small accounts spend disproportionately. Consider consolidating low-traffic accounts via centralized observability or accepting that the per-account fixed-cost portion is the price of security parity.
## VPC Flow Logs: GB-Tiered, Network-Dependent
VPC Flow Logs analysis bills per GB at tiered rates ($1/GB, $0.50/GB, $0.25/GB). The cost driver is network traffic volume — busy multi-AZ deployments with heavy inter-service traffic generate substantial flow log volume.
The tier-down at 500 GB helps; the tier-down at 2.5 TB helps more. The waste pattern: enabling Flow Log analysis on every VPC including idle test/dev VPCs that generate hundreds of GB of meaningless traffic from health checks and idle service polling.
## When to Enable Each Data Source
## A 30-Day GuardDuty Bill Cleanup Plan
**Week 1 — Audit per-data-source cost.** Use the GuardDuty console's Usage page to break down the bill by data source per account-region. Identify the top 3 cost drivers across the organization.
**Week 2 — Scope Runtime Monitoring.** Identify EKS/ECS/EC2 Runtime Monitoring enabled on non-production clusters. Disable on dev/staging/CI. Document the security trade-off and confirm with the security team.
**Week 3 — Audit S3 Protection and Malware Protection scope.** List buckets currently in scope. Remove buckets that don't hold sensitive or user-uploaded content. For Malware Protection for EC2, audit on-demand scan triggers.
**Week 4 — Multi-account housekeeping.** Verify that newly-created accounts are being auto-enabled (security posture) and that the cost projection per new account is tracked in FinOps reporting. Plan capacity for projected account growth.
## What This Post Doesn't Cover
- **Detective Investigation pricing** (the deeper-dive investigation tool) — separate product with separate per-investigation billing; covered in our security operations content.
- **Security Hub aggregation cost** — Security Hub bills per security check; covered in a separate post.
- **Comparison with third-party CNAPP / CWPP tools** (Wiz, Orca, Lacework) — different pricing models, different operational profiles.
- **Pre-GA GuardDuty features** like Extended Threat Detection — pricing not yet stable; verify before enabling in production.
## If You Only Do One Thing This Week
Check the GuardDuty Usage page in your highest-spend account and identify which data sources contribute the most to that account's bill. Run `aws guardduty get-usage-statistics --detector-id --usage-statistic-type SUM_BY_DATA_SOURCE --usage-criteria '{"AccountIds":[""]}'` to get the per-data-source breakdown programmatically. The number-one cost driver in 80%+ of accounts is either EKS Runtime Monitoring (container-heavy workloads) or CloudTrail management events (API-velocity workloads); identifying which lets you scope the next optimization round.
For the operational architecture — multi-account detector configuration, finding triage, Security Hub integration — the [GuardDuty production guide](/blog/aws-guardduty-threat-detection-production-guide/) covers the design side.
## FAQ
### How does the GuardDuty 30-day free trial mislead teams?
The free trial enables every available data source — CloudTrail, VPC Flow, DNS, S3 Protection, EKS Audit Log, EKS Runtime Monitoring, ECS/EC2 Runtime Monitoring, Lambda Protection, RDS Protection, Malware Protection for S3 — at no charge for 30 days per data source per account. Teams use the trial period to validate that GuardDuty works, see no bill, and assume the production cost will be similar. When the trial ends, the bill arrives all at once and reflects every data source being live. The mitigation: use the cost estimator in the GuardDuty console (which shows a projected monthly cost based on actual data volumes during the trial) and disable data sources that are not delivering operational value before the trial expires.
### Which GuardDuty data source typically dominates the bill?
It depends on the workload shape. For container-heavy organizations, EKS Runtime Monitoring at ~$0.008 per vCPU-hour dominates: a 200-node EKS cluster (each 8 vCPU) costs roughly $9,200/month for Runtime Monitoring alone. For high-velocity API-driven workloads, CloudTrail management events ($4/M tiered down to $1/M above 2.5B) dominates — multi-account orgs with high API velocity easily exceed billions of management events per month. For data-heavy workloads, VPC Flow Logs at $1/GB tiered down to $0.25/GB above 2.5 TB can be the largest line. Audit the per-data-source breakdown in the GuardDuty cost console rather than assuming.
### How does organization-wide auto-enable change the bill structure?
When GuardDuty is configured via AWS Organizations with auto-enable for new accounts (the recommended security posture), every account created in the organization automatically gets GuardDuty enabled with the configured data sources. This is correct for security — no account should escape detection — but means the bill scales linearly with account count. An organization growing from 50 to 200 accounts over a year sees the GuardDuty bill grow 4× even without workload changes. Plan capacity for new accounts in your FinOps budget; the security value justifies the cost but the line is not flat.
### When should I enable Runtime Monitoring for EKS, ECS, or EC2?
Runtime Monitoring observes process activity inside compute (file system changes, network connections, process forks) and detects threats like reverse shells, cryptominers, and lateral movement. It is expensive — ~$0.008 per vCPU-hour for EKS/ECS/EC2. Enable it on production workloads where runtime threat detection is a compliance or security requirement. Skip it on dev and staging environments where the runtime detection value does not justify the per-vCPU-hour rate. Some teams enable Runtime Monitoring only on internet-facing or public-facing workloads where the attack surface is largest.
### How does Malware Protection for S3 differ from Macie?
Macie classifies S3 objects by content (PII, PHI, credit cards, etc.) and bills per object inspected. Malware Protection for S3 scans uploaded objects for malware signatures and bills per GB scanned ($0.30/GB). They serve different purposes: Macie answers "what sensitive data do I have?", Malware Protection answers "is this object infected?". Both can run on the same bucket, both bill independently. Most teams enable Malware Protection on buckets receiving user-uploaded content and Macie on buckets storing potentially-sensitive data; few buckets need both.
### Does GuardDuty cost more in multi-region deployments?
Yes — significantly. GuardDuty is enabled per-region per-account, and each region with active workloads bills its own data sources independently. A multi-region production deployment across 3 regions effectively triples the data-source costs for the workloads in each region. The mitigation: enable GuardDuty in every region as the security posture requires (it should be — attackers will target unmonitored regions), but consider which data sources need to be on in each region. Runtime Monitoring on a DR-standby region with idle workloads adds limited security value at full cost.
### How do I avoid paying for GuardDuty findings I never act on?
GuardDuty findings flow to the GuardDuty console, CloudWatch Events / EventBridge, and Security Hub. The cost is on the data analysis, not the findings themselves — but generating findings nobody acts on is wasted security operations capacity. Route findings to a SIEM with severity filtering, suppress noisy low-severity finding types via suppression rules (free), and configure auto-archive for finding types that consistently produce false positives in your environment. The "cheapest" finding is the one your security team can actually act on.
---
*Source: https://www.factualminds.com/blog/amazon-guardduty-pricing-data-sources-multi-account/*