Amazon GuardDuty Detector
Does ZopNight manage Amazon GuardDuty Detector?
Amazon GuardDuty meters the telemetry it analyzes: CloudTrail management events, VPC Flow Logs, and DNS query logs, each billed by volume, plus whatever protection plans are enabled per detector. ZopNight discovers detectors on the 6-hour cycle and tracks their cost from Cost Explorer or CUR 2.0 to keep spend proportional to activity.
Rules that fire on Amazon GuardDuty Detector
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
Amazon GuardDuty provides threat detection over account activity, billed on the volume of CloudTrail events, VPC Flow Logs, and DNS logs analyzed. Cost scales with account activity and enabled protection plans, so spend visibility per detector matters.
Billing that shadows your activity
GuardDuty has no instance to size and no capacity to reserve; its meter is the volume of telemetry it inspects. CloudTrail management events bill per million events analyzed, VPC Flow Logs and DNS logs bill per GB, and each optional protection plan (S3 Protection, EKS Protection, Malware Protection, RDS Protection, Lambda Protection, Runtime Monitoring) adds its own volume-based meter. The consequence: GuardDuty spend rises automatically when the account gets busier, when new workloads generate more flow-log volume, or when someone enables a protection plan estate-wide.
Detector-level visibility in ZopNight
Detectors are discovered via a dedicated provider on the 6-hour cycle, and per-detector cost comes from Cost Explorer or CUR 2.0 with trend analysis over time. The value is catching divergence between spend and intent: a protection plan enabled during an incident and never revisited, a member account whose flow-log volume doubled after an architecture change, or a region where GuardDuty runs against nothing of consequence. Security tooling is rarely something to switch off, so ZopNight’s posture here is deliberately observation and trend, not scheduling.
Where GuardDuty bills more than expected
The recurring surprises: organization-wide auto-enable turning every new member account into a billed detector on day one, including sandboxes generating noisy telemetry; Malware Protection scans triggered repeatedly against large EBS volumes; and chatty east-west traffic inflating flow-log analysis volume even though the traffic itself is benign and internal. None of these are wrong, but each deserves to be a decision rather than a discovery on the invoice.
Checking detectors and usage
The GuardDuty console’s Usage page breaks estimated cost down by data source and protection plan per detector, which is the fastest way to see what drives the number. Cross-check against the organization’s delegated-administrator view to confirm which accounts and plans are enabled on purpose.