Skip to main content

Enabling GuardDuty

The GuardDuty setup wizard walks you through six steps to deploy Amazon GuardDuty centrally across your organization. After you submit, an asynchronous job enrolls member accounts, enables the protection plans you selected, and configures the administrator account.

Accessing the Wizard​

  • If no Security Hub capability is enabled yet, the Security Hub Overview page drops straight into the Enable Security Hub capability picker. Find the Threat detection / Amazon GuardDuty card and click Enable.
  • If Security Hub CSPM (or any other capability) is already live, the Overview page shows one tile per capability instead. The GuardDuty tile carries its own Enable button.
  • You can also go to Configuration > Capabilities, which shows the same capability cards under the heading Security capabilities, and click Enable on the GuardDuty card.
  • While GuardDuty is not configured, the Security Hub sidebar shows a greyed-out Enable GuardDuty row. Clicking it opens the same wizard.

Wizard Steps​

StepNameWhat you configure
1Admin accountThe AWS account that administers GuardDuty and aggregates findings
2RegionsThe home region and the additional linking regions
3FeaturesThe six protection plans to enable (all on by default)
4MembersThe member accounts to enroll
5EmailsThe root email address for each member account
6ReviewConfirm all settings before submitting

Back is available from step 2 onwards. Next is gated on three steps only — Admin account (an account must be picked), Regions (a home region must be picked and must be among the linking regions) and Emails (the lookup must have finished and every unresolved account must have an address). The Features and Members steps always let you continue, including with nothing selected.

Prerequisites​

  • At least one AWS account is available in Prism to serve as the admin account
  • You know the real AWS root email address for each member account you plan to enroll (see the Emails step below)

Step 1: Admin Account​

Select the AWS account that will administer GuardDuty. This account owns the aggregating detector in every linked region, invites the member accounts, and receives their findings.

FieldRequiredNotes
Admin accountYesA type-ahead picker listing Account name (account ID) for every linked account

The step also carries this warning in the UI:

The admin account is permanent for this deployment. To change it later you must disable GuardDuty entirely and set it up again.

warning

Re-running the wizard deletes the previous GuardDuty configuration record. Findings collected under the old configuration are no longer shown in Prism after you set GuardDuty up again.

note

The admin account is itself enrolled as a GuardDuty account — the Review step counts it in the member total. It is excluded from the Members picker only because it is always included, not because it is ineligible.

Step 2: Regions​

Select the home region and any additional linking regions where GuardDuty detectors will be deployed.

FieldRequiredDefaultNotes
Home regionYesus-east-1Single-select. Choosing a home region automatically adds it to the linking regions
Linking regionsYesus-east-1Multi-select with a checkbox per region and a header row that reads Select all (or Deselect all once everything is selected); the home region is locked and cannot be deselected

Next stays disabled until a home region is chosen and the linking-region list contains it.

Step 3: Features​

Select the GuardDuty protection plans to enable across every member account and linked region.

Protection planWhat it monitors
S3 Protection (data events)Amazon S3 data-plane API calls for data access anomalies
EKS Protection (audit logs)Amazon EKS control-plane audit logs for suspicious Kubernetes activity
Malware Protection (EBS)EBS volumes attached to running EC2 instances and container workloads
RDS Protection (login events)Amazon RDS and Aurora database login activity
Lambda Protection (network logs)AWS Lambda network activity for threats from compromised functions
Runtime MonitoringRuntime-level activity from EKS nodes and ECS tasks

All six protection plans are enabled by default.

note

The wizard does not stop you from clearing every checkbox. If you submit with no plan selected, Prism falls back to the full default set above rather than creating detectors with no protection plans.

info

You can change the enabled protection plans after setup from Settings > Features.

Step 4: Members​

Select the member accounts to enroll. The admin account is always included and does not appear in the selection list.

FieldRequiredNotes
Member accountsNoMulti-select with a checkbox per account and a Select all / Deselect all header row; each option reads Account name (account ID)

You can leave this empty to enable GuardDuty in the admin account only, and add members later.

note

You can add or remove member accounts after setup from the Enrollment page without rerunning the wizard.

Step 5: Emails​

GuardDuty uses invitation-based member association, which requires the real AWS root email address of each member account. Prism resolves root emails automatically where possible:

Each member account needs its AWS root email to be invited. Emails are fetched automatically where possible; enter any that could not be resolved.

While the lookup runs, the step shows Fetching root emails…. The lookup re-runs whenever you go back and change the member selection.

  • Auto-resolved accounts show the address in green followed by (auto). There is no field to edit — Prism re-resolves these server-side when you submit.
  • Unresolved accounts show an editable Root email field. Its helper text is the reason the lookup failed, or Auto-fetch failed — enter this account's AWS root email when no reason was returned.

Next stays disabled until every unresolved account has an address typed in. If you reach this step with no members selected, it reads No member accounts selected — go back to Members and pick at least one — you can still continue, which enables GuardDuty in the admin account alone.

To find a member account's root email address, sign in to that AWS account and go to Account Settings > Account > Email address in the AWS Console.

warning

Entering an incorrect or placeholder email address causes an EmailVerificationFailed error and GuardDuty cannot invite that member. Use the real root account email address, not an alias, distribution list, or IAM user email. Prism also rejects addresses shorter than 6 or longer than 64 characters before making any AWS call.

info

You do not have to split a large member selection yourself. Prism sends the lookup in batches of five accounts, one batch at a time, and the server resolves the accounts within a batch in parallel — small enough that no single request runs into the gateway timeout, however many accounts you picked. A large selection still takes proportionally longer, and Next stays disabled until the last batch has come back.

Step 6: Review​

The Review step is headed Review, above the line "Check the deployment below, then enable GuardDuty.", and summarizes your selections:

RowValue
Admin accountThe account ID you picked in step 1
Home regionThe home region
Linking regionsThe linking regions, comma-separated
Protection plans"N enabled" — a count, not a list
Member accounts"N (including admin)" — the members you picked plus the admin account

Click Enable GuardDuty to submit; the button reads Enabling… while the request is in flight. If the submission is rejected for any reason — a member still missing an email, an invalid address, or a server error — the wizard jumps back to the Emails step and shows the error there. Correct the problem and resubmit.

What Happens After Submission​

Once the request is accepted, the wizard replaces the step body with a progress screen headed Setting up GuardDuty…:

Enrolling member accounts, enabling protection plans, and configuring the delegated administrator. This can take a few minutes.

A progress bar below it polls the job every few seconds, and the panel underneath repeats the Admin account and Home region you chose. When the job finishes, the page swaps itself for the Threat Dashboard.

The job:

  1. Attaches Prism's persistent GuardDuty IAM policy (CKPrism-GuardDuty-Permissions) to the admin account's access role and verifies it is usable — if this fails, setup stops immediately
  2. Creates the administrator detector in the admin account for each linked region, with the protection plans you selected
  3. Attaches the same policy to every selected member account; an account whose grant fails is marked failed and skipped so the rest still enroll
  4. Creates a detector in each remaining member account and region
  5. From the admin account, creates and invites the members in each region, using each member's root email address
  6. Has each invited member accept the administrator invitation
info

"Delegated administrator" here describes the role the account plays in Prism's deployment — it owns the aggregating detector and issues the invitations. Prism uses GuardDuty's invitation model, so it does not register an AWS Organizations delegated administrator.

If some (account, region) enrollments fail, the overall status becomes partial_failure with the message "N of M (account, region) enrollments failed". The Threat Dashboard then shows a warning banner with a Review button that opens Enrollment, where you can retry the failed accounts.

If every (account, region) enrollment fails, the status becomes failed with the message "All member enrollments failed", and the wizard is shown again with a warning above the stepper reading "The previous setup attempt failed: reason. Submitting again will clear that state and retry."

info

A prior failed, partial_failure or disabled GuardDuty configuration is cleared automatically when you resubmit the wizard — its configuration record, member rows, refresh jobs and cached findings are deleted before the new one is created. You do not need to remove the old state by hand.