Considerations and limitations

A policy applies only to accounts in AWS Organizations. An organization policy can manage GuardDuty only in accounts that belong to your organization through AWS Organizations. It cannot manage accounts that are not part of your organization, such as accounts associated only by the legacy invitation method. Manage GuardDuty in those accounts separately, from the delegated GuardDuty administrator account account or in each account. For more information about the two association methods, see Managing multiple accounts in Amazon GuardDuty.

A policy can enable GuardDuty in the management account only if the service-linked role already exists there. A policy cannot enable GuardDuty in the organization's management account unless the GuardDuty service-linked role already exists in that account. If the role is absent, GuardDuty is not enabled in the management account even when the policy declares it enabled. Create the role in the management account, for example by enabling GuardDuty there, before you rely on a policy to manage it.

The delegated administrator is assigned per Region, and enabling accounts is separate from seeing them. The management account designates the GuardDuty delegated administrator in each Region. A delegated administrator assigned in one Region can create a policy that enables GuardDuty for member accounts, including in Regions where it is not the delegated administrator. However, the delegated administrator cannot see those member accounts' status or findings in a Region unless the management account has also designated it as the delegated administrator in that Region. To both manage and monitor member accounts in a Region, the management account must designate the delegated administrator in that Region. Because designation is per Region, the management account can designate different accounts as the delegated administrator in different Regions, and each delegated administrator manages and monitors member accounts only in the Regions where it is designated.

The delegated administrator needs the AWS Organizations delegation policy to manage policies. Designating a delegated administrator lets it view member accounts, but it cannot create, update, or attach GuardDuty organization policies unless the AWS Organizations delegation policy also grants it permission to manage the GUARDDUTY_POLICY policy type. If those operations are denied, verify that the delegation policy grants the delegated administrator permission to manage the policy type.

A managed protection plan is read-only in the console and API. When a policy manages a protection plan, covered accounts cannot change it through the GuardDuty console or API. To change a managed protection plan, update the policy. Protection plans that the policy does not manage remain editable through the console and API.

A policy manages enablement only, not detection customizations. A GuardDuty organization policy enables and disables GuardDuty and its protection plans. It does not manage detection customizations such as entity lists, IP address lists, or suppression rules. Configure these separately through the GuardDuty console or API after GuardDuty is enabled. For more information, see Customizing threat detection with entity lists and IP address lists and Suppression rules in GuardDuty.

An unmanaged Region is left unchanged, not disabled. A Region that a policy neither includes in the default configuration nor names in a Regional override is unmanaged. The policy does not enable or disable GuardDuty there, and the existing settings in that Region are left as they are.

GuardDuty processes global events in every enabled Region. GuardDuty replicates AWS CloudTrail global service events, from services such as IAM, AWS STS, Amazon S3, and Amazon CloudFront, and processes them in every Region where GuardDuty is enabled, including Regions where you have no resources or workloads. This improves threat detection, but it means that when a policy enables GuardDuty broadly, such as a default configuration that covers every Region, GuardDuty processes these global events across all of those Regions, which can incur additional GuardDuty costs. For more information, see How GuardDuty handles AWS CloudTrail global events and Pricing in GuardDuty.

Disabling a protection plan turns it off where it is currently enabled. A policy that disables GuardDuty or a protection plan turns it off in every covered account where it is enabled, and prevents those accounts from turning it back on through the console or API. Before you create or update a policy, identify the accounts and Regions the change affects, as described in Reviewing a policy's impact before you apply it.

Policy changes apply asynchronously. A policy change propagates across your organization and is reconciled over time, rather than taking effect instantly. Allow time for a change to apply before you conclude that it did not take effect.

Detaching a policy does not disable GuardDuty. When you detach a GuardDuty organization policy from an entity, other policies that the entity inherits from parent entities can still apply and continue to govern the target. If no effective policy remains after you detach, GuardDuty and its protection plans stay in their current state and are not disabled. In either case, future changes to your organization, such as new accounts joining or existing accounts moving into an OU, no longer enable GuardDuty automatically unless an inherited policy still covers them. Any further enablement must be done manually, by re-attaching a policy, or through an inherited policy.

Disabling the policy type stops all policy management and restores auto-enablement. Disabling GuardDuty in a policy, detaching a policy, and disabling the GUARDDUTY_POLICY policy type are three different actions with different effects. When you disable the GUARDDUTY_POLICY policy type on the organization root, GuardDuty organization policies no longer govern any account, and GuardDuty remains enabled in the accounts it previously covered. Disabling the policy type also restores the Regional GuardDuty auto-enablement settings that enabling the policy type had suppressed, so auto-enablement resumes according to those settings.