---
title: Amazon GuardDuty Pricing: Nine Data Sources, One Compounding Bill
description: GuardDuty bills across nine separate data sources: CloudTrail management events at a flat $4/M, VPC Flow Logs at $1/GB tiered, EKS Runtime Monitoring per vCPU-month, 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.joinhorizon.co/blog/amazon-guardduty-pricing-data-sources-multi-account/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: kevin-w
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 a flat $4/M, VPC Flow Logs at $1/GB tiered, EKS Runtime Monitoring per vCPU-month, 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';
import PricingCalculatorCta from '~/components/blog/PricingCalculatorCta.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.
> **Amazon GuardDuty pricing** bills nine threat-detection data sources independently across accounts in an AWS Organization. In us-east-1 (October 2026), each enabled source has usage-based per-unit rates after the 30-day trial. Most surprises come from enabling Runtime Monitoring and EKS Audit Log analysis org-wide without scoping to production accounts.
| Data source | Billing unit | Trap |
| ------------------- | --------------- | --------------------- |
| CloudTrail analysis | Per 1M events | Org-wide enable |
| VPC Flow Logs | Per GB analyzed | All VPCs |
| EKS Audit Logs | Per 1M events | Every cluster |
| Runtime Monitoring | Per vCPU-month | Largest surprise line |
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](https://www.joinhorizon.co/blog/aws-guardduty-threat-detection-production-guide/).
## The GuardDuty data sources
_If you only audit one dimension first, review **Runtime Monitoring** scope. It is the most common post-trial bill shock._
## 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 a free preview that ends abruptly.
## Runtime Monitoring bills per vCPU
_Figure: Runtime Monitoring in the article. The detector watches the workload, and the charge follows vCPU. Rates stay in the article. A finding sequence is an earlier diagram. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/amazon-guardduty-pricing-data-sources-multi-account/runtime.drawio)._
EKS Runtime Monitoring (and the equivalent for ECS Fargate and EC2) is often the largest data source on container-heavy bills. The rate is $1.50 per vCPU-month for the first 500 vCPUs and $0.75 after that, which sounds small until you compute it across a real cluster:
- 200-node EKS cluster, each node 8 vCPU = 1,600 vCPU
- (500 vCPU × $1.50) + (1,100 vCPU × $0.75) = $750 + $825 = $1,575/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 across many accounts
CloudTrail management events are GuardDuty's most consistent line item: every API call analyzed regardless of source. The pricing is a flat $4 per million events, with no volume tiers. At organization scale the absolute bill grows linearly with API volume. An organization with 200 accounts, each generating 50M management events/month, hits 10B events, or ~$40K/month from the CloudTrail data source alone in GuardDuty (separate from CloudTrail's own bill).
Because the rate is flat, there is no volume discount to plan around. The bill follows API call volume across every account, so the cost of security parity is the sum of each account's management events.
## VPC Flow Logs: tiered per GB, driven by network traffic
_Figure: VPC Flow Logs in the article. GuardDuty's flow-log source grows with network traffic. It is a different meter from Runtime Monitoring. Rates stay in the article. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/amazon-guardduty-pricing-data-sources-multi-account/flow.drawio)._
VPC Flow Logs analysis bills per GB at tiered rates ($1/GB, $0.50/GB, $0.25/GB, and $0.15/GB above 10 TB). 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, and again above 10 TB. 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.
## More in this series
Part of the **AWS Service Pricing** series (June 2026).
- Previous: [Part 11](https://www.joinhorizon.co/blog/amazon-vpc-pricing-endpoints-peering-transit-gateway/)
- Next: [Part 13](https://www.joinhorizon.co/blog/aws-backup-pricing-vaults-cross-region-restores/)
- Browse all: [Cost Optimization & FinOps category](https://www.joinhorizon.co/category/cost-optimization-and-finops/)
- FinOps pillar: [FinOps shift-left: cost feedback in the pull request](https://www.joinhorizon.co/blog/aws-finops-shift-left-engineering-cost-ownership/)
## 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](https://www.joinhorizon.co/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 $1.50 per vCPU-month (first 500 vCPUs, then $0.75) is often the largest line: a 200-node EKS cluster (each 8 vCPU) costs roughly $1,575/month for Runtime Monitoring alone. For high-velocity API-driven workloads, CloudTrail management events ($4/M flat) 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, and $0.15/GB above 10 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 bills per vCPU: $1.50 per vCPU-month for the first 500 vCPUs, then $0.75, across 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 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 plus per object evaluated ($0.09/GB and $0.215 per 1,000 objects). 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, since 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 rather than the findings themselves, but generating findings nobody acts on wastes 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.
---
*Source: https://www.joinhorizon.co/blog/amazon-guardduty-pricing-data-sources-multi-account/*