What Does GuardDuty Cost Once It Is On Everywhere?

Security turned GuardDuty on in every account and every Region eighteen months ago, following AWS's own recommendation, and nobody has looked at it since. Then it shows up as a real line item in a cost review, and the question in the room is simple: what is this actually billing for? There's no server, no obvious usage to point at — just a service that was supposed to be background protection, quietly adding up across an organization nobody re-audits account by account.

Why does GuardDuty cost anything at all?

GuardDuty's foundational protection and its optional protection plans are metered separately, and almost none of them are flat fees:

Every account gets a 30-day free trial the first time GuardDuty is enabled in a Region, and each protection plan you add later gets its own 30-day trial when you turn it on — except Malware Protection for S3, which runs on a small standing free tier instead, and on-demand malware scanning, which has no free trial at all.

Why does turning it on everywhere cost more than one flat number suggests?

Because "GuardDuty" isn't one meter — it's a stack of independent ones, and the stack multiplies by account, by Region, and by which protection plans are switched on. An organization with 40 member accounts across 6 Regions, each with EKS Protection and RDS Protection enabled, is running 240 separate foundational billing contexts before Runtime Monitoring or Malware Protection are even counted.

Two things about that multiplication surprise people the first time they check:

You don't pay twice for the data GuardDuty reads. GuardDuty doesn't require you to already have VPC Flow Logs enabled or a CloudTrail trail configured — it consumes an independent, duplicated stream of that data directly, and AWS documents no additional charge for GuardDuty accessing it. If you also run your own VPC Flow Logs to CloudWatch or S3 for other reasons, that's a separate bill from a separate service; turning GuardDuty on doesn't add a second charge on top of logs you already pay for, and turning it off doesn't remove logs you already have.

Enabling every Region costs far less than "Region count × price" implies. AWS recommends enabling GuardDuty account-wide, including Regions with no deployed resources, specifically to catch activity in Regions you don't normally watch. A Region with nothing running in it generates close to zero VPC Flow Log and DNS query volume, so its foundational bill is close to zero too — the exception is CloudTrail management events with security relevance (IAM, STS, and other global-service calls), which GuardDuty replicates into every enabled Region to build user and role profiles there. That replication is billed at the same $4-per-million-events rate, but the volume behind it is usually small next to a Region actually running workloads.

How do I find out what's actually driving the number?

GuardDuty's own usage API breaks the bill down before it ever reaches Cost Explorer. From the delegated administrator account, get spend per member account:

aws guardduty get-usage-statistics \
  --detector-id <your-detector-id> \
  --usage-statistic-type SUM_BY_ACCOUNT \
  --usage-criteria '{}'

Then break the same detector down by data source to see whether flow logs, DNS, or CloudTrail is driving the total:

aws guardduty get-usage-statistics \
  --detector-id <your-detector-id> \
  --usage-statistic-type SUM_BY_DATA_SOURCE \
  --usage-criteria '{}'

Run aws guardduty list-detectors first if you don't have the detector ID handy — one call per Region, since GuardDuty is a Regional service and each Region has its own detector. Whichever data source or feature comes back largest tells you which line in the rate table above to focus on first, rather than guessing from the account total.

How do I bring the bill down without losing coverage?

Turn off protection plans that don't match what an account actually runs. RDS Protection on an account with no RDS instances and EKS Protection on an account with no EKS clusters bill nothing meaningful, but a sandbox or CI account that spins up short-lived infrastructure across every service is a different story — audit protection-plan enablement per account rather than assuming the organization-wide default fits every account equally.

Scope Malware Protection for S3 to the buckets that need it. It bills per GB scanned and per object evaluated, and it can be configured against specific buckets rather than every bucket in an account — a bucket that already goes through a separate antivirus pipeline, or one that only ever holds already-scanned artifacts, doesn't need a second scan on top.

Exclude non-production compute from Runtime Monitoring where security doesn't require it. The vCPU-based charge scales with however much EC2, EKS, and Fargate capacity has the agent deployed, so a large fleet of short-lived dev or test instances can end up costing more in Runtime Monitoring than the production fleet it's meant to protect.

Review the organization's auto-enable configuration by OU, not as one blanket setting. GuardDuty's delegated administrator can auto-enable specific protection plans for new accounts by organizational unit — a sandbox OU and a production OU rarely need identical coverage, and setting that once at the OU level is cheaper than fixing it account by account after the fact.

What else should I check while I'm in here?

If you export GuardDuty findings to S3 — a common setup for longer retention or feeding a SIEM — AWS requires that bucket to be encrypted with a KMS key you control, and GuardDuty is granted kms:GenerateDataKey against it to write each export batch. The request volume is trivial next to what drives a real KMS bill, since exports run on a schedule (as often as every 15 minutes, not per finding), but it's one more key with one more cross-service grant to keep straight in an account that already leans on customer-managed keys elsewhere. See how much does KMS cost to run for what actually moves that meter.

More broadly, GuardDuty is one entry in a category of security and observability tooling that gets turned on once, per account, per Region, and essentially never revisited — the same shape that makes a forgotten Secrets Manager replica or an unused customer-managed key quietly accumulate for months before anyone notices. How much does AWS Secrets Manager cost walks through the same per-resource creep on a service most teams also budget for once and never check again.

Security tooling is rarely the first place people look when an AWS bill needs cutting, but it's not exempt from the pattern — everything else an AWS account quietly pays for works through where the rest of that money actually goes.

How do I catch this before it becomes a real number?

GuardDuty cost almost never spikes in a way that looks alarming — an account added to the organization, a protection plan turned on for one more Region, one more EKS cluster added to the fleet. Each change is a small, defensible security decision, and none of them individually looks like something to flag. The total is what nobody checks.

Connect your AWS account read-only, and Parsivex's daily anomaly checks compare every service's spend — GuardDuty included — against its own trailing baseline, so a genuine jump (a new protection plan enabled account-wide, a Region's traffic volume climbing faster than the rest of the fleet) gets flagged the next morning instead of surfacing three months later in a security budget review. For how those daily checks and severity thresholds work, see cost anomaly alerts, or read how scans work for what a connected account scan reads across the rest of your bill.