GuardDuty支持Organizations策略统一启用：区域例外会整块覆盖，迁移前先盘点旧自动配置

昨天 3阅读

2026年10月1日，AWS宣布GuardDuty支持AWS Organizations声明式策略。管理员可以在组织根、组织单元或单个账户范围统一定义威胁检测启用方式，并让新加入或移动到相应组织单元的账户继承配置。此次能力覆盖AWS商业区域及GovCloud（美国）区域。

把启用基线放进组织层级

过去，多账户、多区域环境需要分别维护GuardDuty的区域启用设置，配置容易逐步分散。新策略通过委派管理员集中管理基础检测及保护计划，并支持一个默认配置与按区域覆盖的例外。由策略管理的启用状态不能通过普通GuardDuty控制台或API直接覆盖。

这使组织可以把“哪些账户应具备哪些保护”写成可统一维护的定义。它管理的是服务启用与保护计划，不是自动替企业批准所有处置动作，也不表示每个区域都支持完全相同的检测功能。区域与具体功能的服务可用性仍然适用。

AI模型生成的概念插图：统一保护基线向多个账户传递，其中一个区域采用独立配置；不是实际组织结构或GuardDuty界面。

Organizations指南说明，区域配置块会完整替换该区域的default块，而非只修改其中出现的字段。因此，给某个区域增加一项例外时，需要把希望管理的功能完整写入该区域块。只写一项变化而假定其余默认项仍然叠加，可能产生与预期不同的有效策略。

default本身可以省略，但这样只有显式列出的区域受管理，其他区域处于不受该策略管理的状态，策略既不启用也不关闭它们。任何块中如果启用了额外保护功能，都必须同时启用基础威胁检测。把这些规则放进配置评审，能减少看起来语法正确、实际覆盖却不足的情况。

政策沿组织层级继承，多份政策最终合成为账户的有效政策，更接近账户的具体政策具有优先性。本文建议对代表账户查看最终结果，而不是只审阅根级文件；一个组织单元里的例外，可能正是某个账户与整体基线不同的原因。

GuardDuty指南有一条需要特别留意的提醒：启用GUARDDUTY_POLICY类型后，原区域自动启用设置立即不再生效，即使尚未挂接政策。委派管理员在控制台创建第一份政策时，会自动启用这个政策类型。所以，“我只是先建一个草稿，晚点再应用”不能被当成没有配置影响的保证。

使用前还需要组织中的GuardDuty可信访问、委派管理员及管理政策的授权。本文建议先导出现有各区域自动启用基线，确定新政策如何覆盖现有和新增账户，再安排首次创建与挂接的顺序。不要在未确认接替范围时关闭原有管理机制。

解除挂接也不等于撤销所有已启用的保护。官方说明，先前覆盖的账户会继续保持GuardDuty启用，但后续新账户加入或组织结构变化不会再因这份政策自动启用。因此，移除政策后的状态应作为一项单独验收内容，不能根据“政策已删除”推断服务已经停用。

可以先选一个测试组织单元，检查新账户加入、账户移入和移出，以及区域例外的最终表现；再核对保护范围和成本变化。此次公告没有把所有保护计划改成免费服务。集中配置降低了重复维护量，同时也让一次规则变更影响更多账户，评审和回退安排应跟着覆盖范围一起设计。

资料核对：2026年10月3日（北京时间）。本文未创建或挂接组织政策，操作建议为原创分析。