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.

Amazon GuardDuty Pricing: 9 Data Sources, Multi-Account Costs

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.

The Nine GuardDuty Data Sources

GuardDuty pricing breakdown — us-east-1, June 2026

Prices in us-east-1

Each data source is metered independently. The tiered rates drop with volume but compound across sources and accounts.

Dimension	Unit price	Example workload	Monthly cost
CloudTrail management events Free first 500M, $2/M next 2B, $1/M after	$4/M → $2/M → $1/M tiered	2B events / month	~$5,000
VPC Flow Logs Tiered at 500 GB and 2.5 TB	$1/GB → $0.50/GB → $0.25/GB	500 GB / month	$500
DNS Logs No separate per-GB charge	Bundled with VPC Flow tier	DNS query analysis	In the Flow Logs tier
S3 Protection Per-account-region S3 data events analyzed	$0.80/M → $0.40/M → $0.20/M S3 events	100M S3 events / month	~$80
EKS Audit Log Monitoring Analyzes Kubernetes audit log	$0.50/GB	200 GB EKS audit / month	$100
EKS Runtime Monitoring Per-node agent; expensive on large clusters	~$0.008 / vCPU-hour	200-node × 8 vCPU cluster	~$9,200
ECS Runtime Monitoring (Fargate) Per-task; auto-enabled with Runtime Monitoring	~$0.008 / vCPU-hour	500 Fargate tasks × 2 vCPU	~$2,900
EC2 Runtime Monitoring Agent-based; opt-in per instance	~$0.008 / vCPU-hour	50 instances × 8 vCPU	~$2,300
Lambda Protection Analyzes Lambda invocation network activity	Per invocation analyzed	50M invocations / month	Tiered low
RDS Protection Detects login anomalies and access patterns	Per RDS instance / month	20 RDS instances	Variable
Malware Protection for S3 Per upload; configurable per-bucket	$0.30 / GB scanned	1 TB uploaded / month	$300
Malware Protection for EC2 On-demand or auto-triggered EBS scans	$0.45 / GB scanned	500 GB on-demand scans	$225

CloudTrail management events

~$5,000

Free first 500M, $2/M next 2B, $1/M after

Unit price: $4/M → $2/M → $1/M tiered
Example workload: 2B events / month

VPC Flow Logs

$500

Tiered at 500 GB and 2.5 TB

Unit price: $1/GB → $0.50/GB → $0.25/GB
Example workload: 500 GB / month

DNS Logs

In the Flow Logs tier

No separate per-GB charge

Unit price: Bundled with VPC Flow tier
Example workload: DNS query analysis

S3 Protection

~$80

Per-account-region S3 data events analyzed

Unit price: $0.80/M → $0.40/M → $0.20/M S3 events
Example workload: 100M S3 events / month

EKS Audit Log Monitoring

$100

Analyzes Kubernetes audit log

Unit price: $0.50/GB
Example workload: 200 GB EKS audit / month

EKS Runtime Monitoring

~$9,200

Per-node agent; expensive on large clusters

Unit price: ~$0.008 / vCPU-hour
Example workload: 200-node × 8 vCPU cluster

ECS Runtime Monitoring (Fargate)

~$2,900

Per-task; auto-enabled with Runtime Monitoring

Unit price: ~$0.008 / vCPU-hour
Example workload: 500 Fargate tasks × 2 vCPU

EC2 Runtime Monitoring

~$2,300

Agent-based; opt-in per instance

Unit price: ~$0.008 / vCPU-hour
Example workload: 50 instances × 8 vCPU

Lambda Protection

Tiered low

Analyzes Lambda invocation network activity

Unit price: Per invocation analyzed
Example workload: 50M invocations / month

RDS Protection

Variable

Detects login anomalies and access patterns

Unit price: Per RDS instance / month
Example workload: 20 RDS instances

Malware Protection for S3

$300

Per upload; configurable per-bucket

Unit price: $0.30 / GB scanned
Example workload: 1 TB uploaded / month

Malware Protection for EC2

$225

On-demand or auto-triggered EBS scans

Unit price: $0.45 / GB scanned
Example workload: 500 GB on-demand scans

Tiered pricing means the first units of usage in each data source bill at the high tier. Volume helps; small accounts pay the high tier on everything.

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.

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:

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.
Public-facing workloads only. Enable Runtime Monitoring on internet-facing workloads where the attack surface is largest; skip on internal back-office services.
Spot-instance-friendly sizing. Right-size nodes to reduce vCPU footprint; Runtime Monitoring bills on actual vCPU running, not provisioned vCPU.

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

CloudTrail and VPC Flow on every account always; Runtime Monitoring on production only; S3 Protection on data-bearing buckets; RDS Protection on production databases.

Use when

CloudTrail management events: every account in every region — non-negotiable baseline security
VPC Flow Logs analysis: production and security-sensitive accounts — the core network threat detection layer
EKS/ECS/EC2 Runtime Monitoring: production clusters where runtime threat detection is a compliance or operational requirement
S3 Protection: buckets storing sensitive data, customer uploads, audit logs
Malware Protection for S3: buckets receiving user-uploaded content (uploads, attachments, etc.)
RDS Protection: production databases with sensitive workloads
Lambda Protection: serverless workloads handling sensitive data or processing untrusted input

Avoid when

Runtime Monitoring on dev / staging / CI / ephemeral clusters — pure cost without commensurate security value
VPC Flow Logs analysis on idle test VPCs generating noise from health checks
S3 Protection on every bucket — scope to data-bearing buckets only
Malware Protection for EC2 on demand without a defined trigger criterion — expensive on-demand scans
Multi-region GuardDuty in DR-standby regions where workloads are idle — security value is minimal at full cost

Default to enabling CloudTrail + VPC Flow + DNS on every account-region; scope the expensive data sources (Runtime Monitoring, Malware Protection) to production with documented justification.

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 <id> --usage-statistic-type SUM_BY_DATA_SOURCE --usage-criteria '{"AccountIds":["<account>"]}' 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 covers the design side.

Amazon GuardDuty Pricing: Nine Data Sources, One Compounding Bill

The Nine GuardDuty Data Sources