> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # GuardDuty Detector > AWS GuardDuty Detector. The per region resource that switches GuardDuty on for an account, holding which data sources are analyzed and how often findings publish. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Infrastructure-only adaptation](#infrastructure-only-adaptation) * [On Google Cloud](#on-google-cloud) * [On Azure](#on-azure) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | ✓ | | Private Kubernetes | - | ## 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 | Capability | GuardDuty Detector | Google Cloud | Azure | | ----------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | | Enablement unit · what one detector becomes | one detector per account and region, switched by its enable flag | one Security Command Center source under the organization; every detector in a stack folds into it | Defender for Cloud plans on the subscription; every detector in a stack folds into one enablement | | Protection scope · what the enablement covers | the data sources and features the detector enables | a custom finding source that records the posture; Event Threat Detection and the other services are enabled in Security Command Center at the Premium or Enterprise tier | the Servers and Storage plans at the Standard tier; other plans are enabled in the subscription | | Publishing cadence · when findings appear | every 15 minutes, hour or 6 hours, as configured | findings published as they are raised | security alerts published as they are raised | | Detector API at run time · reading or changing the detector | GetDetector, UpdateDetector and ListDetectors | applied as configuration at deploy; Security Command Center is managed through its own API afterwards | applied as configuration at deploy; plans are managed through Azure's own security APIs afterwards | | API coverage | full | minimal | partial | ## On Google Cloud | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------- | ---------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Filters, IP sets, threat-intel sets and publishing destinations | Companions | Out of scope | Full surface | These resources ride with the detector and are reported as not carried when the stack is translated. Recreate suppression as mute rules, and route findings through Pub/Sub or Google SecOps. | | Data sources and detector features | Detector | Out of scope | Most usage | The datasources block and aws\_guardduty\_detector\_feature resources choose which GuardDuty analyzers run. Security Command Center has no per-source setting the translation could write: the services and log inputs a threat needs are enabled in the 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. | | Detector API at run time (GetDetector, ListDetectors, UpdateDetector) | Detector | Out of scope | Full surface | No adapter answers GuardDuty API calls on Google Cloud. The detector is applied as configuration when your stack deploys, and Security Command Center is managed through its own API afterwards. | | Detector enablement (aws\_guardduty\_detector) | Detector | Partial | Common | A detector with enable = true becomes one Security Command Center source under your Google Cloud organization, named by the organization id supplied when the target environment is set up. The source is a custom finding source that records the detection posture; it does not switch on Event Threat Detection or any other detection service, which are enabled in Security Command Center's settings at the Premium or Enterprise tier. Every detector in a stack folds into that one source, and a stack whose detectors are all disabled creates nothing. | | Finding publishing frequency | Detector | Out of scope | Most usage | The 15-minute, 1-hour and 6-hour publishing settings have no counterpart; Security Command Center findings are published as they are raised. | #### 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 | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------- | ---------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Filters, IP sets, threat-intel sets and publishing destinations | Companions | Out of scope | Full surface | These resources ride with the detector and are reported as not carried when the stack is translated. Recreate suppression rules, allowlists and threat feeds in Defender, and route alerts through Microsoft Sentinel. | | Data sources and detector features | Detector | Partial | Most usage | The datasources block and aws\_guardduty\_detector\_feature resources choose which GuardDuty analyzers run. Defender is chosen per resource type instead, and the translation enables the Servers and Storage plans whichever sources the detector names. An enabled S3 data-event, EKS audit-log or malware-scanning source is reported with the Defender plan it needs; a feature with no Defender counterpart is not applied. | | Detector API at run time (GetDetector, ListDetectors, UpdateDetector) | Detector | Out of scope | Full surface | No adapter answers GuardDuty API calls on Azure. The detector is applied as configuration when your stack deploys, and the plans are managed through Azure's own security APIs afterwards. | | Detector enablement (aws\_guardduty\_detector) | Detector | Supported | Common | A detector with enable = true becomes Microsoft Defender for Cloud on the subscription: the Servers and Storage plans at the Standard tier. Every detector in a stack folds into that one enablement, and a stack whose detectors are all disabled enables nothing. | | Finding publishing frequency | Detector | Out of scope | Most usage | The 15-minute, 1-hour and 6-hour publishing settings have no Defender counterpart; security alerts are published as they are raised. | #### 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. [Service Catalog](/byoc/service-adapters/catalog).