Settings
The Settings page lets you change the GuardDuty protection plans active across your organization, add or remove linked regions, check the IAM permissions Prism holds in each enrolled account, and disable GuardDuty entirely. Changes to features and regions trigger an asynchronous update job.
Accessing Settings
In the Security Hub sidebar, open the GuardDuty group and click Settings.
If GuardDuty has not been set up yet, the page shows an information banner — GuardDuty is not set up yet for this customer. Complete the setup wizard first to manage protection plans or disable the service. — with a Go to setup button that opens the setup wizard.
The page has four tabs, in this order: Features, Regions, Permissions and Danger zone.
Page-Level States
Three things can appear above the tabs, whichever tab you are on:
- An error panel, when a save is rejected. It carries the rejection message verbatim, and has no retry action — fix the input and save again.
- A progress bar, while another GuardDuty operation is running. It is labelled with that job's own progress label, falling back to "A GuardDuty operation is running — settings are locked until it finishes". Both Save buttons are disabled until it clears, and the page polls until it does — you do not have to reload.
- A red banner, when GuardDuty setup is in the
failedstate: "GuardDuty setup failed, so linking regions cannot be changed until it is re-run. Disabling is still available from the Danger zone." It carries a Re-run setup button that opens the setup wizard.
Features Tab
The Features tab, headed Protection plans, lists the six GuardDuty protection plans. Toggle the checkbox next to each plan to enable or disable it across every member account and region.
| Protection plan | What 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 Monitoring | Runtime-level activity from EKS nodes and ECS tasks |
Click Save features to apply the changes. The button is disabled until you actually change something, and stays disabled while a GuardDuty operation is running or while no plan is selected.
What Happens After
After you click Save features, the page navigates to the GuardDuty landing page (Threats in the sidebar). That page detects the in_progress status and shows a progress screen headed "Updating protection plans…", with the body "Enabling / disabling the requested GuardDuty features across every member account and region." It resumes to the Threat Dashboard automatically once the update finishes.
The update job runs in two passes, which is what the progress bar is measuring:
- The administrator's own detectors, one linked region at a time. This pass owns the first half of the bar.
- Every enrolled member's own detector, in parallel across accounts and regions. This pass owns the second half.
The member pass exists because members do not inherit the administrator's feature set under the invitation model — each member detector has to be updated in its own account. If the administrator pass fails in any region, the job stops there and the member pass never runs.
At least one protection plan must remain selected. Clearing them all disables Save features and shows a red alert in its place: "At least one protection plan is required. GuardDuty cannot be left with none — to stop it entirely, disable GuardDuty from the Danger zone." The server enforces the same rule independently, so an API call that clears every plan is rejected with "at least one feature must be enabled".
Either pass can fail the configuration into partial_failure, and the Threat Dashboard then shows a warning banner with a Review button. Which pass failed changes what was saved:
- Administrator pass — message "Some feature changes did not apply in AWS: region: error". Your previous feature list is kept, because the new one is only persisted after this pass succeeds everywhere.
- Member pass — message "Feature changes did not reach N member account(s): account: error". The new feature list is saved, because the administrator detectors did take it; the named member accounts are the ones still running the old set.
Regions Tab
The Regions tab, headed Linking regions, lets you add or remove the regions where GuardDuty detectors are deployed.
- Home region: shown as a read-only value, as "Home region:
<region>(read-only)". It cannot be removed. - Linking regions: a multi-select list of all available AWS regions with a checkbox per region and a Select all / Deselect all header row. The home region is locked in the picker and cannot be deselected, and the server refuses any request that would drop it.
The tab states the consequences directly: Adding a region enrolls every member account there; removing a region tears down its detectors and prunes its findings.
Update your region selection and click Save regions to apply the changes. Save regions is disabled until the selection actually changes, and while the configuration is in any state other than enabled or partial_failure — the server refuses a region change outside those two states with "cannot update regions while config status is …", so the button is dead rather than the request.
Clearing every region disables the button and shows a red alert in its place: "At least one linking region is required, and it must include the home region <region>."
What Adding or Removing a Region Does
| Operation | Effect |
|---|---|
| Adding a region | GuardDuty detectors are created in that region for the admin account and for every member account currently enabled in at least one region |
| Removing a region | GuardDuty detectors in that region are torn down, and the region's member rows and stored findings are deleted from Prism |
A member account whose earlier removal failed is not re-enrolled into newly added regions — only accounts in the enabled phase are carried forward.
What Happens After
After you click Save regions, the page navigates to the GuardDuty landing page, which shows a progress screen while the region enrollment or teardown runs. Region updates do not have a progress heading of their own, so the screen reads "Enabling GuardDuty across accounts and regions…" for both additions and removals.
Removing a region is destructive. Once its teardown completes cleanly, all GuardDuty findings for that region are deleted from Prism. This cannot be undone.
If the teardown fails, the region stays linked and its rows are marked failed with the AWS error attached, rather than being reported as removed — a detector that is still running is never claimed to be gone. Re-attempt it by saving the region change again from this tab. Do not use Retry on the Enrollment page for those rows: it enrolls, it does not tear down.
Permissions Tab
The Permissions tab, headed Account permissions, reports the IAM policy Prism keeps on each enrolled account's access role:
GuardDuty works by assuming a role in each enrolled account. Prism keeps a scoped IAM policy on that role listing only the actions this service needs. "Fix roles" re-applies it — use it if a policy was removed in AWS, or after an update that needs new permissions.
Opening the tab starts a scan automatically, showing Checking account permissions… with a progress bar. The results table has three columns — Account, Permissions and Details — and reports one of three states per account:
| State | Chip | Colour | Meaning |
|---|---|---|---|
current | Current | Green | The account's role carries the expected policy |
outdated | Needs update | Amber | The policy is present but does not match what this version of GuardDuty needs |
missing | Missing | Red | The policy is absent from the role |
Two buttons sit below the table:
- Fix roles re-applies the policy to every account that needs it. It is disabled when nothing needs fixing, and reads Applying… while it runs. The scan re-runs automatically afterwards so you see the outcome.
- Re-check runs the scan again on demand.
Next to the buttons, a summary reads All accounts are up to date. or N accounts need attention. (1 account needs attention. for a single account). If GuardDuty has no enrolled accounts yet, the tab reads No enrolled accounts to check yet — enroll an account to start tracking its role permissions.
While a re-check is running, the previous results stay on screen dimmed rather than disappearing, so the panel never collapses and snaps back.
A scan that fails is reported, not swallowed. The tab shows an error panel with a Retry action carrying the scan's own message, or "The permissions scan failed." if it recorded none — and any table still on screen underneath stays dimmed, because those rows are the previous scan's result and not the current state of your roles.
Danger Zone Tab
The Danger zone tab lets you disable GuardDuty for your entire organization. Its warning reads:
Disabling tears down all member enrollments and GuardDuty detectors in every region. The findings Prism has already fetched stay visible while GuardDuty is off, but re-running setup starts a fresh cache and clears them — the detectors they came from no longer exist.
To disable GuardDuty:
- Click Disable GuardDuty.
- The Confirm disable dialog opens, showing your customer ID in the prompt "Type the customer ID
<id>to confirm:". Enter it into the Customer ID field exactly as shown. - Click Disable to confirm. The button stays disabled until the typed value matches your customer ID exactly.
After confirmation, the page navigates to the GuardDuty landing page. It detects the in_progress teardown and shows a progress screen headed "Disabling GuardDuty…", with the body "Tearing down members and detectors across every linked region. This can take a few minutes." When teardown finishes, the status transitions to disabled and the setup wizard is shown.
When the teardown completes with no errors, every member row is marked disabled and Prism also removes its persistent GuardDuty IAM policy (CKPrism-GuardDuty-Permissions) from the access role of the admin account and every member account.
If any part of the teardown fails, the status becomes partial_failure instead of disabled, the policies are left in place so a retry can still run, and the failure reason is shown on the dashboard. The member rows are marked failed in that case, so they reappear on the Enrollment page with a Retry button — which enrolls rather than tears down. Run Disable GuardDuty again instead.
You can re-enable GuardDuty at any time by running the setup wizard again — but re-running it deletes the previous configuration record, and findings collected under that configuration are no longer shown. Disabling on its own preserves the finding history; setting GuardDuty up again does not carry it over.
Related Pages
- Threat Dashboard, The landing page after GuardDuty is enabled
- Enrollment, Add or remove member accounts
- Enabling GuardDuty, Run the setup wizard
- Security Hub Issues, Troubleshooting failed updates and disable operations