Coverage by target cloud
How the targets compare
Each row compares a capability of GuardDuty Detector with its adaptation on each target. A dash means this row is not stated for that target.Infrastructure-only adaptation
On Google Cloud
The detector on Google Cloud
On AWS a detector is a per-region resource:enable switches GuardDuty on for the account, the datasources block and aws_guardduty_detector_feature resources choose which telemetry it analyzes, and finding_publishing_frequency sets how often findings reach EventBridge. Security Command Center is organized around the organization. A source is a handle under which findings are grouped, and the detection services that produce findings, Event Threat Detection, Container Threat Detection and Virtual Machine Threat Detection among them, are enabled in the organization’s Security Command Center settings under the Premium or Enterprise tier, each with a source of its own.
Your translated stack reads every detector it declares as one decision, on or off, and when any is enabled it emits one google_scc_source under the organization whose numeric id was supplied when the target environment was set up. That source is a custom finding source: it records the detection posture the stack expects and accepts findings written to it through the Security Command Center API. It does not enable a detection service, and the findings Event Threat Detection raises appear under that service’s own source. Enabling Event Threat Detection and the log inputs it reads is a setting in your organization, made once. No GuardDuty detector exists on Google Cloud, and no adapter answers guardduty: calls.
Limitations
- The source enables no detection. Event Threat Detection and the other detection services are enabled in Security Command Center’s settings, at the Premium or Enterprise tier; the Standard tier does posture management only. A stack deployed into an organization with those services off creates the source and detects nothing. - Data-source toggles have no counterpart. The detector’s sources and features choose GuardDuty analyzers; Security Command Center’s services are enabled per organization. An enabled S3 data-event, EKS audit-log or malware-scanning source is reported with the service it needs when the stack is translated. - Publishing frequency has no counterpart. Findings are published as they are raised; the 15-minute, 1-hour and 6-hour settings are not applied. - The detector’s companions are not recreated. Finding filters, trusted IP sets, threat-intel sets and the S3 publishing destination are reported as not carried. Suppression is a mute rule, allowlists and feeds are settings of the detection services, and findings are exported through Pub/Sub or Google SecOps. - The GuardDuty API is not served. GetDetector, UpdateDetector and ListDetectors have no answer on Google Cloud; Security Command Center is managed through its own API.
Other considerations
- Scope. A detector is regional and per account; the source and the detection services are organization-wide. Several detectors in one stack fold into one source, and the source follows the stack’s lifecycle. - Who operates what. Google operates Security Command Center and its detection services; the source is part of your translated stack, enabling the services is a setting in your organization, and Tensor9 is not in the detection path. - Cost. GuardDuty bills per volume of analyzed logs and events. Security Command Center’s Premium and Enterprise tiers are subscriptions at the organization or project level, so their cost does not follow this stack’s deployment.
On Azure
The detector on Azure
On AWS a detector is a per-region resource:enable switches GuardDuty on for the account, the datasources block and aws_guardduty_detector_feature resources choose which telemetry it analyzes, and finding_publishing_frequency sets how often findings reach EventBridge. Defender for Cloud is organized differently. Protection is a plan per resource type on the subscription, and a plan is either on at the Standard tier or off.
Your translated stack reads every detector it declares as one decision, on or off, and when any is enabled it emits two azurerm_security_center_subscription_pricing resources at the Standard tier: VirtualMachines for the Servers plan and StorageAccounts for the Storage plan. Microsoft’s detection engine then analyzes Azure’s own telemetry for the subscription. The two resources are part of your stack and follow its lifecycle; no GuardDuty detector exists on Azure, and no adapter answers guardduty: calls.
Limitations
- Two plans are enabled, whatever the detector selected. The Servers and Storage plans cover virtual machines and storage accounts. Containers, databases, key vaults and other resource types need their own Defender plans, enabled in the subscription; an enabled S3 data-event, EKS audit-log or malware-scanning source is reported with the plan it needs when the stack is translated. - Publishing frequency has no counterpart. Defender publishes a security alert when it is raised; the 15-minute, 1-hour and 6-hour settings are not applied. - The detector’s companions are not recreated. Finding filters, trusted IP sets, threat-intel sets and the S3 publishing destination are reported as not carried. Suppression rules, allowlists and threat feeds are Defender settings, and alerts are routed through Microsoft Sentinel. - The GuardDuty API is not served. GetDetector, UpdateDetector and ListDetectors have no answer on Azure. An application that manages its detector at run time manages Defender plans through Azure’s own security APIs instead.
Other considerations
- Scope. A detector is regional and per account; a Defender plan is subscription-wide. Several detectors in one stack fold into one enablement, and the plan resources follow the stack’s lifecycle. - Who operates what. Microsoft operates Defender for Cloud and its detection engine; the plan enablement is part of your translated stack, and Tensor9 is not in the detection path. - Cost. GuardDuty bills per volume of analyzed logs and events; Defender for Servers and Defender for Storage bill per protected resource at the Standard tier, from the moment the plans are enabled.