Enabling GuardDuty Across an Organization

Turning GuardDuty on in one account is easy, but real environments have many accounts. Enabling and managing detection across all of them by hand is error-prone and leaves gaps. AWS solves this with the delegated administrator model tied to AWS Organizations.

AWS Organizations lets you group multiple accounts under one management account, arranged in Organizational Units (OUs). It is the foundation for multi-account governance. Many security services, including GuardDuty, integrate with Organizations to operate across every member account centrally.

Rather than running security from the powerful management account, you designate a separate delegated administrator account for GuardDuty, usually a dedicated security account. This account configures and views GuardDuty for the whole organization, following the best practice of not using the management account for daily operations.

The Organizations management account is extremely sensitive, so AWS recommends keeping it for billing and account management only. Delegating security administration to a separate account limits blast radius and applies separation of duties, a Well-Architected best practice the exam favors.

Once delegation is set, the administrator can enable GuardDuty in every existing member account and view their findings in one console. Members cannot disable the service if the administrator manages it, ensuring consistent coverage that individual teams cannot accidentally turn off.

A key feature is auto-enable: any new account added to the organization automatically gets GuardDuty turned on. This closes the common gap where a freshly created account sits unmonitored. The exam values this because it guarantees detection coverage as the organization grows.

The delegated administrator sees all findings from all accounts in a single pane. This central view is essential for an organization-wide security operations team to triage and respond without logging into dozens of accounts. It also feeds central Security Hub aggregation.

GuardDuty is regional, so enabling it organization-wide must be done per Region. A common mistake is enabling it in one Region and assuming global coverage. To cover all activity you enable it in every Region you use, including ones you do not expect resources in.

Setting this up requires enabling trusted access for GuardDuty in Organizations, then registering the delegated administrator. After that, the administrator manages membership and configuration centrally. This is a one-time setup that pays off as the organization scales.

Beyond the central console view, organizations often route every account's findings to a central security account through Security Hub aggregation or by exporting to a shared S3 bucket and EventBridge bus. This gives the security operations team one durable, account-spanning record. Designing this central flow is a recurring multi-account exam theme.

Before Organizations integration, accounts were linked by invitation: an administrator invited each member, who had to accept. This still works but does not scale or auto-enable new accounts. The Organizations method with a delegated administrator is preferred because it manages membership centrally and auto-enables newcomers, which the exam treats as the modern best practice.

Apply organization-wide detection.

Scale GuardDuty with AWS Organizations and a delegated administrator (a dedicated security account, not the management account). The administrator enables GuardDuty across member accounts, uses auto-enable for new accounts, and views all findings centrally. Remember GuardDuty is regional, so enable it per Region for full coverage.