使用 AWS Organizations 與 Control Tower 的多帳戶治理

多帳號治理是一套設計、佈建並持續強制執行護欄（guardrails）的學科，目標是讓安全、合規、成本與營運標準在整個 AWS 帳號群中均一生效，無論哪個團隊下一次啟動工作負載都不例外。在 SAP-C02 中，多帳號治理並非孤立的主題——它貫穿 Domain 1（設計組織複雜性）、Domain 2（設計新方案）、Domain 3（持續改善）以及 Domain 4（加速工作負載遷移與現代化）。所有描述「公司有 40 個 AWS 帳號」或「新業務單位正在上線」的情境，本質上都是偽裝過的治理問題。

本指南假設你已具備 Associate 等級的 IAM 知識（identity-based vs resource-based policies、sts:AssumeRole、跨帳號角色、permissions boundaries），並聚焦在組織層級的控制平面：AWS Organizations、service control policies、AWS Control Tower、標籤/備份/AI 退出/Chatbot 政策、CloudFormation StackSets，以及委派管理員。目標是讓你在 SAP-C02 中快速排除錯誤答案，並在實際工作中架構出一套真正的 landing zone。

為什麼多帳號治理在 SAP-C02 如此重要

在 Professional 等級，AWS 期望你預設採用多帳號，並能為任何單一帳號的答案提出合理理由。AWS 白皮書「Organizing Your AWS Environment Using Multiple Accounts」列出了標準理由：爆炸半徑隔離、獨立安全邊界、獨立計費、各團隊獨立配額、合規範圍縮小、資料主權，以及依生命週期分離工作負載。SAP-C02 的考題經常以微妙的爆炸半徑或 SCP 繼承細節作為關鍵考點——一旦判斷失誤，就會選到技術上可行但治理上較差的答案。

考試也喜歡讓 AWS Organizations 對 AWS Control Tower 互相對立，或讓 SCP 對 IAM permissions boundaries 互相對立，或讓 StackSets 自管理模式對服務管理模式互相對立。最快的應對方式，就是把每項服務的職責背得滾瓜爛熟，包括每項服務具體上不能做什麼。

白話文解釋 Multi-Account Governance

多帳號治理充斥著大量術語。三個類比能讓這些概念變得具體好記。

類比一：連鎖便利商店

把整個架構想像成台灣遍地開花的連鎖便利商店系統。AWS Organizations 管理帳號是總部——它簽署主合約、統一結帳，並制定品牌規範。每個AWS 成員帳號是各地門市，有自己的收銀台、店員和日報表。Organizational Units (OU) 是各區督導管轄群——「北部區」、「南部區」、「測試廚房」——讓總部能針對不同區域發布規範。Service control policies (SCP) 是連鎖督導手冊——不管店長多有創意，「絕對不能販售清單 X、Y、Z 以外的商品」（允許清單），或「這幾項商品任何情況都不得上架」（拒絕清單）。重要的是，手冊本身不賣東西——店員仍需要自己的權限（成員帳號內的 IAM policies）才能實際營業。AWS Control Tower 是連鎖加盟輔導顧問，在幾個小時內幫新門市裝好標準冰箱、POS 系統、監視器和合規標誌，之後每週派督導回來稽查是否有偏差。Audit 帳號是區域稽核辦公室；Log Archive 帳號是安全保存所有交易明細七年的中央文件室。委派管理員是讓區域主管代表總部執行 Security Hub 和 GuardDuty，讓加盟商不必每天登入最高權限的總部帳號處理日常事務。

類比二：辦公大樓

AWS 組織就像一棟辦公大樓。管理帳號是大樓業主——持有產權、繳交公共費用（統一計費），並制定全棟規範。OU 是樓層（三樓 = Production、二樓 = Non-Prod、一樓 = Sandbox）。每個租戶辦公室是一個成員 AWS 帳號。SCP 是大廳公告欄貼出的管理規約——「晚上十點後不得高聲喧嘩、不得商業烹調、不得短租」——規約封頂了任何租戶能做的事，但一個只是靜靜讀書的租戶（沒有任何權限的 IAM 使用者）仍需要租約（identity-based IAM policy）才能實際做任何事。Control Tower guardrails 是煙霧偵測器與灑水系統——預防性 guardrails 直接滅火（封鎖 API 呼叫）、偵測性 guardrails 在發現煙霧時發出警報（產生 AWS Config 不合規發現）、主動性 guardrails 在裝潢施工前審查設計圖（CloudFormation Hooks 攔截不合規的 stack）。Drift 就是租戶把灑水頭鬆開的狀況；Control Tower 的 drift detection 是每月定期巡樓並標記異常。

類比三：航空公司出境流程

AWS Organizations + Control Tower 就像機場。管理帳號是航管中心。每個 AWS 帳號是航廈。OU 是登機區（「國際線」、「國內線」、「貨運區」），各有不同規定。SCP 是安檢規則——不管哪家航空（IAM principal）賣了你機票，安檢仍可拒絕禁止攜帶的物品進入。安檢本身不發登機證（SCP 不授予權限）；你的航空 IAM policy 才是登機證的來源。Tag policies 是行李標籤規格——每件行李必須依特定格式貼標，否則輸送帶系統就會標記為不合規。Backup policies 是遺失行李保險方案——總部定義一份保險計畫，每個航廈透過 AWS Backup 自動繼承。CloudFormation StackSets 是全機場統一標示系統——一套設計，集中部署到所有登機區並統一更新。

AWS Organizations 深度解析 — 結構、OU 設計模式與信任模型

AWS Organizations 是所有其他治理服務的基礎。在 SCP、Control Tower 或 StackSets 有意義之前，你需要建立正確的結構心智模型。

結構：管理帳號、root、OU 與成員帳號

一個組織只有一個管理帳號（舊稱 master account）。管理帳號擁有組織所有權、建立與邀請成員帳號、管理 OU、附加政策，且是唯一能在整個組織啟用服務的帳號。root 是最頂層的容器——附加到 root 的政策會影響每一個帳號。root 下方是Organizational Units (OU)，可在下方最多巢狀五層。成員帳號存在於 OU 內（或直接在 root 下方，但在任何 SAP-C02 情境中這都是危險訊號）。

功能集有兩種：

• 全功能（現代預設）：啟用 SCP、標籤政策、備份政策、AI 退出政策、Chatbot 政策，以及與 AWS Control Tower、IAM Identity Center 的整合，以及委派管理員。
• 僅統一計費：傳統模式，只提供單一帳單。任何 SAP-C02 情境除非明確限制，否則一律假設使用「全功能」。

標準 OU 設計模式（AWS 白皮書）

AWS 白皮書「Organizing Your AWS Environment Using Multiple Accounts」定義了 Control Tower 所實作的參考 OU 模式。請熟記它——這是 SAP-C02「公司應如何規劃帳號架構？」類型問題中佔比最高的正確答案：

• Security OU：必須嚴格保護的非工作負載帳號。
  • Log Archive 帳號：存放來自每個帳號的 CloudTrail + Config 日誌的不可變 S3 儲存桶。
  • Security Tooling / Audit 帳號：Security Hub、GuardDuty 委派管理員、Config aggregator、Macie、Detective 的集中部署位置。
• Infrastructure OU：共用基礎工作負載。
  • Network 帳號：Transit Gateway、共用 VPC（透過 AWS RAM）、Route 53 私有託管區域、Firewall Manager。
  • Shared Services 帳號：目錄服務、CI/CD 工具、集中管理的 AMI/容器。
• Workloads OU：應用程式帳號。
  • 細分為 Prod 和 Non-Prod 子 OU，再按業務單位或工作負載建立帳號。
• Sandbox OU：個人實驗帳號，設有嚴格的預算控制與緊縮 SCP（例如拒絕正式生產等級的服務）。
• Suspended OU：已關閉/下線的帳號，以全拒絕 SCP 隔離。
• Policy Staging / Exceptions OU：選用容器，供需要臨時豁免的帳號使用；讓例外可見而非隱藏。
• Deployments OU：選用，存放部署工作負載 OU 的 pipeline/工具帳號。

管理帳號的使用衛生

管理帳號值得單獨說明，因為 SAP-C02 會反覆考到。

• 不要在管理帳號中執行工作負載。 它是終極爆炸半徑的源頭。
• SCP 不適用於管理帳號。 即使你在 root 附加全拒絕 SCP，管理帳號仍保有完整權限。許多考生在這裡中招。
• 為 root 使用者啟用 MFA 並妥善保管憑證，建立組織的當天就應完成。
• 使用委派管理員，讓日常安全營運（Security Hub、GuardDuty、Config、Macie、Audit Manager、IAM Access Analyzer、Firewall Manager、CloudFormation StackSets 服務管理模式）在成員帳號中進行，而非在管理帳號中。
• 從管理帳號啟用 AWS CloudTrail 組織追蹤，讓所有成員帳號的日誌一次性集中到 Log Archive 帳號，只需一個設定。

Service Control Policies — 繼承、評估與有效權限

SCP 是 SAP-C02 中 AWS Organizations 最頻繁被考的功能。考試同時測試高層次概念（SCP 能做什麼、不能做什麼）與低層次評估（deny 疊加或 NotAction 生效時會發生什麼）。

SCP 是什麼，以及它不是什麼

SCP 是附加在 root、OU 或個別成員帳號的 JSON 政策文件。它定義了受影響帳號中 IAM principals 的最大可用權限。三個關鍵特性：

1. SCP 從不授予權限。 它們只做過濾。一個動作需要同時有 SCP allow 和 IAM allow 才能成功。
2. SCP 不適用於 service-linked roles。 AWS 保留這些特殊權限以避免破壞 AWS 服務本身。
3. SCP 不適用於管理帳號。 詳見上方的陷阱說明。

SCP 繼承與評估

SCP 由上至下從 root 流過每個 OU 直到成員帳號。有效 SCP 是從 root 到該帳號路徑上所有 SCP 的交集——每一個 SCP 都必須允許該動作，任何一個 SCP 拒絕就足以封鎖。SCP 有兩種風格：

• 允許清單 SCP（在特定服務上設 "Effect": "Allow"，或將預設 FullAWSAccess 受管 SCP 替換為窄化的允許清單）。這種方式嚴格——只有列出的服務能通過。
• 拒絕清單 SCP（在特定動作上設 "Effect": "Deny"）。這種方式預設寬鬆，只封鎖你列舉的特定風險。

AWS 預設 SCP FullAWSAccess 自動附加到每個新 OU 和帳號——它允許一切，使預設態勢是拒絕清單世界。若要採用允許清單態勢，你必須移除 FullAWSAccess 並附加你自訂的窄化允許 SCP。

允許清單 vs 拒絕清單策略

多數真實世界的 AWS 組織在 root + OU 層級使用拒絕清單策略，只在 Sandbox 和 Suspended OU 上針對性地使用允許清單 SCP。SAP-C02 中提到「將 sandbox 限制為少數 AWS 服務」的題目，指向的就是允許清單 SCP。

Deny 疊加與優先順序

由於 deny 永遠勝出，你可以跨層級疊加多個 deny。常見模式：

• Root 層級 SCP：拒絕離開組織、拒絕停用 CloudTrail、拒絕停用 GuardDuty、拒絕刪除 Config recorders、拒絕停用 KMS CMK、拒絕以破壞 landing zone 的方式修改預設 VPC。這些是「絕對禁止」的護欄。
• Production OU SCP：拒絕 iam:CreateAccessKey 和 iam:UpdateAccessKey 以強制使用 IAM Identity Center、拒絕在昂貴的執行個體系列上執行 ec2:RunInstances、拒絕未加密的 S3 上傳。
• Sandbox OU SCP：拒絕正式生產區域、拒絕 route53:*、拒絕 organizations:*、只允許低成本服務。

NotAction 與條件鍵的陷阱

兩個反覆出現的 SAP-C02 SCP 陷阱：

• NotAction 搭配 "Effect": "Deny" 並非封鎖那些動作——而是拒絕除了那些動作以外的一切。 因此 "Deny" + "NotAction": ["s3:*", "ec2:*"] 會拒絕所有不是 S3 或 EC2 的 API 呼叫，悄悄地破壞 IAM、KMS、CloudWatch 等服務。正確的允許清單模式是 "Effect": "Allow" + "Action": [...]，而非 "Effect": "Deny" + "NotAction": [...]。
• aws:PrincipalOrgID vs aws:PrincipalOrgPaths。在 S3 儲存桶政策和 KMS 金鑰政策中使用 aws:PrincipalOrgID 來限制跨帳號存取只對組織內部開放。當需要限制到特定 OU 路徑時，使用 aws:PrincipalOrgPaths。
• aws:SourceOrgID 和 aws:SourceOrgPaths 出現在 AWS 服務主體中（跨服務 confused deputy 保護）——與上述 principal-org 條件鍵不同。

有效權限與 IAM policy simulator

計算跨 SCP + permissions boundaries + identity-based + resource-based + session policies 的有效權限，是一項真實的運維負擔。AWS 提供兩個工具：

• IAM Policy Simulator：針對特定動作與資源，模擬 principal 的有效權限（包含 SCP 評估）。在故障排除流程中使用。
• IAM Access Analyzer — 未使用存取與自訂政策檢查：可以驗證新的或更新的 IAM policy 是否比參考政策更寬鬆，並在設定為組織層級 analyzer 時標記整個組織中未使用的權限。

當 SAP-C02 情境說「帳號 X 中的開發者無法執行 Y，但 IAM 允許這個動作」，第一個診斷步驟是：檢查帳號 X 路徑上的 SCP，以及 IAM principal 上的 permissions boundaries。

AWS Control Tower — Landing Zone、Account Factory 與 Account Factory Customization (AFC)

AWS Control Tower 是 AWS Organizations 的固執觀點封裝，能建立符合最佳實踐的 landing zone 並維持其健康狀態。SAP-C02 要求你知道何時選擇 Control Tower，而非只在 AWS Organizations 上自行建立 landing zone。

Landing Zone 元件（Control Tower 佈建的內容）

當你在新的管理帳號中啟動 Control Tower，它會在約一小時內部署完整的 landing zone：

• 一個 AWS Organizations 結構，包含 Security OU（含 Log Archive 和 Audit 帳號）以及 Sandbox OU 作為初始 OU。啟動後可自行擴充 OU。
• 一個 Log Archive 帳號，內含集中式 S3 儲存桶，接收組織層級的 CloudTrail 日誌與 AWS Config 快照/設定項目。
• 一個 Audit 帳號，託管 Config aggregator 和合規通知的預設 SNS 主題。
• IAM Identity Center（前身為 AWS SSO），預先配置好對應各 OU 的權限集。
• 套用至每個 OU 的基線強制性 guardrails 集合。
• 用於加密日誌與 AWS Config 資料的 AWS KMS CMK（可選擇客戶自管）。
• 組織層級的 AWS Config 規則與 CloudTrail 追蹤。

Account Factory — 佈建管線

Account Factory 是 Control Tower 建立新成員帳號的佈建機制。它封裝了 AWS Service Catalog：管理員或委派使用者在 Service Catalog 中啟動「AWS Control Tower Account Factory」產品，提供帳號名稱、Email、目標 OU 與 IAM Identity Center 存取權，工廠就會：

1. 在目標 OU 下建立新的 AWS 帳號。
2. 套用 OU 的 guardrails，繼承 SCP 和 Config 規則。
3. 為指定的使用者/群組設定 IAM Identity Center 存取。
4. 若已設定則建立基線 VPC（你可以停用此項——SAP-C02 情境常要求刪除預設 VPC）。
5. 將帳號加入組織層級的 CloudTrail 和 Config 資料管線。

每當 SAP-C02 情境說「新業務單位要求一個必須符合現有 guardrails 的新 AWS 帳號」時，Account Factory 就是正確答案。

Account Factory Customization (AFC)

Account Factory Customization (AFC) 是 2023 年後推出的功能，讓你在 Account Factory 產品中附加一個 CloudFormation 範本（以及透過 AWS Customizations for Control Tower / AFT 模式支援的 Terraform），使每個新佈建的帳號也能同時執行你的基線工作負載基礎設施（例如：含私有端點的 VPC、基線 IAM 角色、GuardDuty 偵測器自訂調整、Amazon Inspector 啟用、Backup Vault）。

AFC 補充但不取代 AWS Control Tower Account Factory for Terraform (AFT)——後者是針對已大量投資 Terraform 的組織的 Terraform pipeline 替代方案。SAP-C02 傾向以 AFC 作為 AWS 原生答案，除非情境明確提到 Terraform。

Customizations for AWS Control Tower (CfCT)

CfCT 是較舊但仍有其用途的框架，透過 AWS CodePipeline 將 SCP、CloudFormation StackSets 和 Account Factory 自訂項目串接成管線。它在管理帳號中執行，適用於需要回應 Control Tower 生命週期事件（帳號建立、OU 註冊）來套用變更的場景。對於每個帳號的基線資源使用 AFC；對於需要 pipeline 審批的組織層級政策和 StackSet 變更，使用 CfCT。

Control Tower Controls（Guardrails）— 預防性、偵測性、主動性與分類

Controls（「guardrails」的現代名稱）是 Control Tower 套用至 OU 的強制性政策。SAP-C02 要求你能為情境選擇正確的控制類型。

控制類型

• 預防性控制：封鎖不合規的 API 呼叫。以 Control Tower 附加至 OU 的 SCP 實作。範例：「禁止刪除 log archive」。
• 偵測性控制：在資源建立之後標記不合規資源。以發出不合規發現的 AWS Config 規則實作。範例：「偵測所有帳號是否啟用 CloudTrail」。
• 主動性控制：在部署之前檢查計畫中的資源。以在 CREATE/UPDATE 期間評估範本的 AWS CloudFormation Hooks 實作。範例：「要求新的 Amazon RDS DB 執行個體啟用加密」。

控制類別（舊稱「強度」）

Control Tower 以業務類別為每個控制貼標：

• 強制性（Mandatory）：自動套用至每個 OU，無法移除。它們保護 landing zone 本身——刪除 log archive、停用 CloudTrail 等。
• 強力建議（Strongly recommended）：選用加入，但 AWS 建議多數組織啟用。範例：拒絕 Log Archive 的 S3 公開讀取、要求 root 使用 MFA。
• 選用（Elective）：針對特定合規需求的選用加入。範例：禁止未啟用版本控制的 Amazon S3 儲存桶、要求 Amazon EBS 預設加密。

除了 Control Tower 目錄之外，你還可以取得 Security Hub controls 和合規框架控制（NIST 800-53、PCI、CIS），可透過 Control Tower 統一控制目錄在 OU 層級啟用。

Drift 偵測與修復

Drift 是任何偏離 Control Tower 基線的狀態——有人手動移除了 SCP、有人刪除了 Log Archive 儲存桶政策、有人將帳號移出已註冊的 OU。Control Tower 持續評估 landing zone 的 drift，並在 Control Tower 主控台中呈現發現結果。

修復路徑：

• 自動重新註冊：對多數 drift 類型，點擊「Re-register OU」或「Update account」即可重新套用基線。
• Landing zone 更新：當 AWS 推出新版 Control Tower 時，更新 landing zone 使新的基線、guardrails 和政策傳播出去。
• 手動修復 + 重新註冊：若有人刪除了 Control Tower 所預期的資源，先還原再重新註冊。

SCP 設計模式 — 允許清單、拒絕清單與生產範例

本節精煉出你在 SAP-C02 中應認識的實戰 SCP 模式。

模式 A：組織層級「永遠拒絕」deny SCP（root 層級）

附加在 root 的小型、針對性拒絕清單，適用於每個非管理帳號：

• Deny organizations:LeaveOrganization — 防止成員帳號中的管理員自行脫離組織。
• Deny cloudtrail:StopLogging、cloudtrail:DeleteTrail、cloudtrail:UpdateTrail 在 org trail 上 — 保護稽核完整性。
• Deny config:DeleteConfigurationRecorder、config:StopConfigurationRecorder、config:DeleteDeliveryChannel — 保護合規態勢。
• Deny guardduty:DeleteDetector、guardduty:DisassociateFromMasterAccount — 保護威脅偵測。
• Deny 針對標籤篩選的關鍵金鑰執行 kms:ScheduleKeyDeletion。
• Deny 對 Control Tower 使用的預設 IAM 角色（AWSControlTowerExecution）執行 iam:*。

模式 B：區域限制 SCP

將工作負載限制在核准的區域。使用 aws:RequestedRegion 和 aws:PrincipalArn——但必須謹慎排除全球 AWS 服務（IAM、CloudFront、Route 53、WAF-classic global、STS、Support），這些服務的呼叫看起來像是 us-east-1 的呼叫。AWS 官方發布的標準範本：

"Effect": "Deny",
"NotAction": [
  "iam:*", "organizations:*", "route53:*",
  "cloudfront:*", "waf:*", "waf-regional:*",
  "sts:*", "support:*", "globalaccelerator:*",
  "budgets:*", "ce:*", "health:*", "tag:*"
],
"Resource": "*",
"Condition": { "StringNotEquals": { "aws:RequestedRegion": ["us-east-1","eu-west-1"] } }

這裡正確地使用了 Deny + NotAction——注意 NotAction 清單列舉了全球服務，讓它們不被拒絕，而條件則將其他所有服務限制在核准區域。若 NotAction 清單有誤，帳號就會損壞；這是最常見的 SCP 錯誤。

模式 C：拒絕 root 使用者 SCP

禁止在成員帳號中使用 root 使用者：

• "Effect": "Deny"、"Action": "*"，加上 "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } }。

搭配 Control Tower 強制性的 root MFA 控制，可使 root 使用者在實際上無法被使用。

模式 D：資料邊界 SCP

資料邊界是確保只有受信任的身份從受信任的網路存取受信任資源的架構邊界。SCP 實作身份側：

• 當 principal 不在組織內時（aws:PrincipalOrgID 條件），拒絕存取 S3/KMS/Secrets Manager——防止 confused-deputy 資料洩露。
• 當 aws:SourceVpc、aws:SourceVpce 或 aws:ViaAWSService 顯示為不受信任的網路時，拒絕存取。

這些配合 S3 儲存桶和 KMS 金鑰上使用相同條件鍵的 resource-based policies，形成完整的資料邊界。

標籤政策與 AI 服務退出政策

除了 SCP，AWS Organizations 還支援另外四種組織政策類型，每種政策強制執行不同維度的治理。

標籤政策

標籤政策在整個組織中強制執行標準化標籤。標籤政策可以：

• 要求特定的標籤鍵（例如 CostCenter、DataClassification、Owner）。
• 強制標籤的大小寫（例如 CostCenter 而非 costcenter）。
• 針對每個鍵強制允許的值（例如 Environment: {Prod | Staging | Dev | Sandbox}）。
• 指定執行適用的特定資源類型。

標籤政策本身不封鎖不合規的標籤——它們透過 AWS Config 和 Tag Editor 回報不合規。要強制執行，須設定 "@@assign" 和 "enforced_for" 運算子，這會讓不合規值的標籤建立在支援的資源類型上失敗。這個細節很微妙，也常被混淆：標籤政策預設是回報，而非封鎖。

搭配標籤政策使用：

• 在 RunInstances、CreateDBInstance 等動作上使用 aws:RequestTag 條件的 SCP——這才是實際封鎖不合規建立（針對不支援的資源類型）的手段。
• 用於建立後偵測的 AWS Config 規則（required-tags）。
• 在管理帳號中啟用成本分配標籤，使標籤成本出現在 Cost Explorer 和 AWS Cost and Usage Report 中。

AI 服務退出政策

AWS AI 服務（Rekognition、Comprehend、Textract、Lex、Polly、Transcribe、Translate、Connect Voice ID、Q Business、CodeWhisperer、Bedrock）預設可能會儲存並使用客戶內容來改善模型。附加在 root 或 OU 的 AI 服務退出政策，會停用範圍內所有帳號的儲存與模型改善參與。

這對以下情況至關重要：

• 資料主權與 GDPR 合規。
• 高度受管行業（醫療、金融）。
• 擁有不得用於訓練之專有內容的企業。

政策可以是全域性（所有服務設 "@@assign": { "optOut": true }）或針對特定服務。啟用此政策類型必須從管理帳號操作。在 SAP-C02 中，「防止 AI 服務使用組織內容進行模型改善」永遠對應到 AI 服務退出政策。

備份政策

組織備份政策宣告集中式 AWS Backup 計畫，這些計畫傳播到每個成員帳號，並以相同的排程、生命週期、跨帳號複製和跨區域複製規則建立 AWS Backup 計畫。搭配 AWS Backup 委派管理員，讓你在不觸碰每個帳號的情況下，實現一個組織一套備份態勢的治理。

關鍵功能：

• 跨帳號複製到集中式 Backup Vault（在獨立的 Backup 帳號中）。
• 跨區域複製以實現 DR。
• Vault Lock（WORM）用於合規等級的不可變性，包含 governance mode 與 compliance mode——compliance mode 連 root 都無法移除。
• 依標籤指定資源，使標籤政策成為備份範圍的依據。

Chatbot 政策

最新的政策類型。Chatbot 政策控制 AWS Chatbot 與 Slack/Microsoft Teams/Amazon Chime 在整個組織中的整合授權——具體而言，哪些頻道可以關聯到帳號，以及頻道 IAM 角色可以擔任哪些權限。附加 Chatbot 政策以限制只有核准的聊天工作區和頻道才能連結到成員帳號，防止流氓 ChatOps bot。

委派管理員 — 避免管理帳號陷阱

從管理帳號執行安全與治理服務是一種反模式。AWS Organizations 的委派管理員功能讓成員帳號代表組織承擔某個整合 AWS 服務的管理控制權。

支援委派管理的服務（高頻考點）

截至 2026 年，超過 30 個服務支援委派管理，包括：

• AWS Security Hub — 在專用的 Security/Audit 帳號中彙整組織層級的發現結果。
• Amazon GuardDuty — 在整個組織中啟用並調整偵測器。
• AWS Config — 跨帳號跨區域 Config 資料的 aggregator。
• AWS IAM Access Analyzer — 組織層級的外部存取分析器。
• Amazon Macie — 組織層級的 S3 資料分類。
• AWS Firewall Manager — 集中管理 AWS WAF、Network Firewall、Security Group、Shield 規則。
• AWS Audit Manager、AWS Backup、AWS CloudFormation StackSets（服務管理模式）、AWS License Manager、Amazon Detective、Amazon Inspector、AWS Trusted Advisor 組織層級檢視、AWS Compute Optimizer、AWS Systems Manager（Quick Setup）。

標準模式是：將 Security / Audit 帳號指定為 Security Hub、GuardDuty、Macie、Inspector、Detective、IAM Access Analyzer 和 Audit Manager 的委派管理員；將 Network 帳號指定為 Firewall Manager 的委派管理員；將 Shared Services / Deployments 帳號指定為 StackSets 服務管理模式的委派管理員。

委派管理員在 SAP-C02 中的重要性

任何說「降低管理帳號的爆炸半徑」或「安全團隊應在不持有管理帳號憑證的情況下管理 GuardDuty」的情境，答案就是委派管理員。答案永遠不是「給安全團隊管理帳號中的 IAM 角色」。

CloudFormation StackSets — 自管理 vs 服務管理權限

CloudFormation StackSets 在單一操作中將相同的 CloudFormation 範本部署到多個帳號和區域。在 SAP-C02 中，StackSets 是多帳號治理的基礎設施即程式碼骨幹。

兩種權限模型

• 自管理權限：需要你在管理員帳號預先建立 AWSCloudFormationStackSetAdministrationRole，並在每個目標帳號建立 AWSCloudFormationStackSetExecutionRole。你以 ID 指定帳號和區域。當組織未使用 AWS Organizations 或目標帳號在組織外時，自管理是正確的選擇。

• 服務管理權限：與 AWS Organizations 整合。AWS 自動建立必要的 service-linked roles，你以 OU 而非帳號 ID 指定目標。新加入 OU 的帳號透過自動部署自動取得 stack。對於組織層級的部署，服務管理幾乎永遠是 SAP-C02 的正確答案。

目標策略（服務管理模式）

• 特定 OU — 部署到 Workloads/Prod 和 Workloads/Non-Prod，但不部署到 Security OU。
• 組織 root — 部署到組織中的每個帳號。
• 自動部署 — 選定 OU 下的新帳號自動取得 stack。
• 移除時的刪除行為 — 當帳號從 OU 移除時，選擇刪除或保留 stack 執行個體。

並行性與失敗容忍度

StackSets 暴露在考試和生產環境中都重要的營運護欄：

• 最大並行帳號數 — 同時有多少帳號接受操作（越高越快但風險越高）。
• 失敗容忍度 — 在停止整個操作前允許多少次失敗。
• 區域順序 — 依序在各區域推出以測試爆炸半徑（例如先 us-west-2，再 us-east-1，再歐洲）。
• 每個帳號的參數和標籤覆寫 — stack 執行個體可攜帶每帳號的覆寫值。

常見多帳號 StackSet 使用情境

• 在每個帳號部署 AWS IAM 基線（break-glass 角色、密碼政策、Access Analyzer）。
• 在每個帳號部署 AWS Config aggregator 授權，讓 Audit 帳號能彙整資料。
• 部署 AWS GuardDuty 跨區域偵測器設定（委派管理員搭配 StackSets）。
• 在每個帳號和區域部署 VPC 基線（或刪除預設 VPC）。
• 部署 CloudWatch Logs 訂閱到集中日誌彙整器。

情境模式 — SAP-C02 中的多帳號治理

SAP-C02 幾乎不會直接問「什麼是 SCP」。它會給出一個四百字的情境，要求你將情況對應到正確的治理構件。以下是反覆出現的模式。

情境模式一：「新收購企業加入組織」

一家公司收購了另一家已有 15 個 AWS 帳號的公司。目標：不造成業務中斷地快速納入治理。

最佳模式：

1. 從管理帳號發送 AWS Organizations 邀請給 15 個帳號。
2. 初期將受邀帳號移入 Policy Staging OU，採用寬鬆的 SCP，避免工作負載在第一天就中斷。
3. 從 Audit 帳號（委派管理員）執行 AWS Config conformance packs 和 Security Hub，為其建立態勢基線。
4. 逐步將通過準備度檢查的帳號移入 Prod / Non-Prod OU，套用完整的 SCP 和 guardrail 集。
5. 在滿足先決條件時，透過「Enroll account」將帳號註冊到 Control Tower。
6. 使用服務管理權限的 CloudFormation StackSets 推送基線 IAM 角色和日誌設定。

錯誤答案模式：「關閉收購的帳號並重新建立」（破壞性太大）；「將 15 個帳號合併為一個」（破壞爆炸半徑隔離）。

情境模式二：「開發者想嘗試新的 AWS 服務」

Sandbox 帳號中的開發者想試用組織從未核准的新 AWS 服務。Sandbox OU 有允許清單 SCP。

最佳模式：

1. 評估該服務的安全與成本風險。
2. 更新 Sandbox OU 的允許清單 SCP，加入該服務（且只加入所需的特定 API）。
3. 若適用，透過 Control Tower landing zone 更新傳播。
4. 要求標籤（Experiment: true、Owner: email）並以 SCP 強制執行，使 sandbox 資源可被識別並納入預算追蹤。

錯誤答案模式：為開發者附加 IAM allow policy——這沒用，因為 SCP 在帳號層級封鎖了該動作。

情境模式三：「中央安全團隊無法管理 GuardDuty」

安全工程師抱怨需要登入管理帳號才能管理 40 個帳號的 GuardDuty 發現結果。

最佳模式：

1. 從管理帳號，將 Security/Audit 帳號註冊為 GuardDuty 委派管理員。
2. 透過 IAM Identity Center 權限集（例如 SecurityAuditor、SecurityAdmin）授予安全工程師存取 Security 帳號的權限。
3. 啟用新帳號自動啟用，讓每個新佈建的成員帳號自動取得 GuardDuty 偵測器。

錯誤答案模式：共用管理帳號憑證，或在管理帳號為每位工程師建立 IAM 使用者。兩者都會增加爆炸半徑。

情境模式四：「合規官員需要集中、防篡改的稽核日誌」

一家受管企業必須以不可變方式保留 CloudTrail 日誌七年。

最佳模式：

1. 從管理帳號啟用 AWS Organizations CloudTrail 組織追蹤。
2. 傳送到專用 Log Archive 帳號的 Log Archive S3 儲存桶（獨立帳號降低內部威脅風險）。
3. 套用 S3 儲存桶政策，要求 aws:PrincipalOrgID 並拒絕 s3:DeleteObject* + s3:PutBucketPolicy，除非是 break-glass 角色。
4. 在儲存桶上啟用 S3 Object Lock 合規模式，設定七年保留期。
5. 啟用 S3 複製到第二個區域以確保持久性。
6. 在 Audit 帳號中啟用 AWS Config 組織 aggregator 以獲取時間點資源狀態。
7. 附加 root 層級 SCP，拒絕 cloudtrail:StopLogging/DeleteTrail，使任何成員管理員無法篡改。

錯誤答案模式：每個帳號獨立追蹤，傳送到各自帳號的儲存桶——這讓防篡改保護無從實現。

情境模式五：「Non-Prod 費用失控」

Non-Prod 帳號在離峰時段於昂貴的 GPU 執行個體上燒掉預算。

最佳模式：

1. 在 Non-Prod OU 附加 SCP，拒絕在昂貴系列（p*、g*、inf*、dl*）上執行 ec2:RunInstances，除非是核准 pipeline 使用的特定 IAM 角色——使用 ec2:InstanceType 條件。
2. 強制執行標籤政策，要求 AutoStop: true + Owner: <email>。
3. 透過 CloudFormation StackSets 部署 EventBridge + Lambda，在非工作時段停止無標籤或標記為 AutoStop 的 EC2/RDS。
4. 在組織層級啟用 AWS Budgets，將 SNS 警示路由到 owner 標籤。
5. 在組織層級使用 AWS Cost Anomaly Detection。

情境模式六：「敏感 S3 儲存桶的資料邊界」

保護一組 S3 儲存桶，使只有組織內部且來自核准 VPC 的身份才能存取，即使儲存桶政策設定錯誤也不例外。

最佳模式：

1. 附加組織層級 SCP，以 aws:PrincipalOrgID 條件拒絕組織外部 principal 存取 S3。
2. 使用 aws:SourceVpce 或 aws:SourceVpc 條件的儲存桶政策，限制只能從 VPC 存取。
3. 透過 Control Tower detective control 和/或 SCP（拒絕關閉 aws:RequestedPublicAccessBlockConfiguration 的 s3:PutBucketPublicAccessBlock）在帳號層級啟用 S3 Block Public Access。
4. 在 S3 的 gateway/interface endpoint 政策中使用 VPC endpoint policies，引用 aws:PrincipalOrgID。

決策矩陣 — 哪種治理控制適用哪個目標

SAP-C02 獎勵快速識別能力。將此決策矩陣作為心智查詢表。

常見陷阱 — 多帳號治理

每次 SAP-C02 考試中，預期至少會看到以下兩種干擾項目。

陷阱一：認為 SCP 授予權限

SCP 從不授予權限。動作只有在成員帳號中存在 IAM allow 且沒有 SCP deny 時才能成功。若考試答案說「附加一個允許開發者呼叫 s3:PutObject 的 SCP」，這是誤導——SCP 只是打開外部邊界；開發者仍需要 IAM policy。

陷阱二：認為 SCP 限制管理帳號

SCP 不適用於管理帳號的 principals。正確的緩解做法是不在管理帳號中執行工作負載。

陷阱三：使用 Deny + NotAction 作為允許清單

Deny + NotAction 拒絕清單中未列出的所有服務，而清單通常遺漏全球服務，破壞了 IAM/KMS/CloudTrail。安全的允許清單是 Allow + Action。

陷阱四：混淆 Control Tower vs AWS Organizations

AWS Organizations 是 API；Control Tower 是固執觀點的封裝。你可以不用 Control Tower 執行 Organizations，但 Control Tower 不能在沒有 Organizations 的情況下執行。Control Tower 增加了 Account Factory、預建 guardrails 目錄、drift detection、Log Archive/Audit 帳號模式，以及這一切的主控台 UI——這些功能如果自行建置，需要自己實作。

陷阱五：忘記委派管理員

將安全操作保留在管理帳號的答案是治理反模式。考試偏好委派到 Security/Audit 帳號的答案。

陷阱六：在服務管理模式可用時使用自管理 StackSets

若帳號都在啟用全功能的組織中，服務管理模式才是正確答案。自管理模式適用於未使用 AWS Organizations 的組織，或跨組織的部署。

陷阱七：認為標籤政策預設就會封鎖

標籤政策預設回報不合規；它們不封鎖。要封鎖，你需要在政策中加上 enforced_for，加上支援的資源類型，或使用包含 aws:RequestTag/aws:TagKeys 條件的 SCP。

陷阱八：五層 OU 巢狀限制

AWS Organizations 允許在 root 下方最多五層 OU 巢狀。提議深度巢狀（十層以上）的答案是錯誤的。實際上，兩到三層就足夠了。

陷阱九：跨區域 Control Tower 主區域

你在啟動時選擇一個 Control Tower 主區域。之後無法更改；Log Archive 和 Audit 帳號錨定在那裡。SAP-C02 有時透過詢問移動 landing zone 來測試這一點——你可以新增區域作為「受治理區域」，但無法更改主區域。

陷阱十：IAM permissions boundary vs SCP

Permissions boundaries 是IAM 層級的上限，作用於單一帳號內的 IAM 使用者/角色。SCP 是組織層級的上限，跨帳號作用。兩者都限制最大權限，但在不同層級運作。它們是互補的，而非可互換的。

診斷入口 — 「為什麼這個 API 呼叫失敗了？」

當情境說「帳號 Y 中的使用者 X 無法執行動作 Z，但 IAM 明明允許」，依此順序逐層檢查：

1. root 到 Y 路徑上的 SCP — 鏈上任何 deny 都會封鎖。是否有明確 deny 或允許清單 SCP 中缺少 allow？管理帳號豁免，所以如果 Y 是管理帳號，跳過此步。
2. IAM principal 上的 permissions boundary — 若存在，它封頂了 identity-based policies 能授予的權限。
3. Y 中使用者/角色的 identity-based IAM policy — 必須對資源包含 Z 的 allow。
4. 目標資源上的 resource-based policy（S3 儲存桶政策、KMS 金鑰政策、SQS 佇列政策）——若存在，也必須允許。
5. Session policy（若角色帶有 session policy 被擔任）——縮小但不能擴大。
6. Access point policy / Lambda resource policy / endpoint policy — 額外的限制。
7. VPC endpoint policy — 若呼叫通過 VPC endpoint，其政策必須允許。
8. 條件鍵 — aws:PrincipalOrgID、aws:SourceVpc、aws:SourceVpce、aws:SecureTransport、aws:RequestedRegion、aws:MultiFactorAuthPresent 都可能悄悄地封鎖。
9. 服務特定政策 — KMS 金鑰 grants、Secrets Manager resource policies、Lake Formation 權限。
10. 服務控制平面問題 — 服務是否在該區域啟用？帳號是否在 Suspended OU 中？Control Tower drift 修復是否移除了什麼？

IAM Policy Simulator 加上失敗呼叫的 CloudTrail errorCode/errorMessage 在生產環境能給你最快的答案。在 SAP-C02 中，選擇「新增 IAM 權限」還是「更新 SCP」，取決於上游是否存在 deny。

AWS Organizations 與 Control Tower 成本模型

治理有其成本面向，SAP-C02 偶爾會考到。

• AWS Organizations 本身免費。 建立組織、OU、SCP、標籤政策、備份政策、AI 退出或 Chatbot 政策均不收費。
• AWS Control Tower 沒有直接服務費，但它會啟用 AWS Config、CloudTrail 和 KMS，這些服務均按各自的標準定價計費。在規模化後（50 個以上的帳號且有大量 Config 資源），Config 成本可能佔大宗。
• CloudFormation StackSets 免費；你只需支付佈建資源的費用。
• 委派管理員啟用的安全服務（Security Hub、GuardDuty、Macie、Inspector、Detective）各自單獨計費；它們不因治理而「捆綁」。
• AWS Backup 按備份儲存 GB 數 + 跨區域複製資料傳輸費用計費。
• IAM Identity Center 免費。

若情境詢問「如何降低多帳號治理的成本？」，典型答案包括：將 AWS Config recorder 範圍調整為只記錄低活躍帳號中的核心資源類型；使用 Config aggregator 而非每帳號的 Config 儀表板；將 Security Hub 標準範圍縮小到只有必要的框架。

FAQ — 多帳號治理最常見問題

Q1：何時選擇 AWS Control Tower，何時在 AWS Organizations 上自行建立 Landing Zone？

只要組織剛開始使用多帳號 AWS、希望獲得 AWS 支援且持續更新的基線，並且能接受 Control Tower 的固執觀點（Security OU + Log Archive + Audit + IAM Identity Center），就選 AWS Control Tower。Control Tower 為 90% 的企業省下數個月的工程時間，建立出足夠好的 landing zone。只有在 Control Tower 不支援所需區域、你已有大量 Terraform/AFT pipeline 投資，或組織有 Control Tower 無法註冊的非標準 OU 語意時，才選自行建立 AWS Organizations landing zone。即使是自行建立的情況，也應遵循 AWS 參考「Organizing Your AWS Environment Using Multiple Accounts」白皮書的架構——那正是 Control Tower 所實作的架構。

Q2：SCP、IAM 權限、permissions boundaries 與 resource policies 如何交互作用？

每個 API 呼叫都必須通過完整的評估鏈。組織路徑上的 SCP 為每個成員帳號設定外部上限。IAM principal 上的 permissions boundaries 在該帳號內設定第二層上限。Principal 上的 identity-based IAM policies 授予實際動作。目標上的 resource-based policies 可以額外允許跨帳號存取，並能加入自己的限制。Session policies 縮小擔任角色的 session 有效權限。任何層級的任何明確 deny 均勝出。最簡單的心智模型：SCP 和 boundaries 定義上限；IAM policies 在內部填充；resource policies 可以打開額外的門；deny 是絕對的。 IAM Policy Simulator 可以評估完整的鏈，但對於 SAP-C02 情境，你要能從題目的線索識別哪個層級在失敗。

Q3：服務管理模式與自管理模式的 CloudFormation StackSets 有何差異？

服務管理模式 StackSets 與 AWS Organizations 整合，以 OU 為目標，在成員帳號加入時自動部署（透過自動部署）。AWS 為你建立 service-linked 執行角色。自管理模式 StackSets 需要你在管理員帳號預先建立 AWSCloudFormationStackSetAdministrationRole，在每個目標帳號建立 AWSCloudFormationStackSetExecutionRole，並以 ID 指定帳號。對於 SAP-C02 的組織層級治理，使用服務管理模式。自管理模式仍有其用途：跨組織的部署、目標帳號不在組織中，或政策禁止 service-linked role 模型時。

Q4：如何防止成員帳號中的惡意管理員離開組織或篡改 guardrails？

套用 root 層級 SCP，無論 IAM policy 為何，拒絕高風險動作。標準拒絕清單：organizations:LeaveOrganization、cloudtrail:StopLogging、cloudtrail:DeleteTrail、config:DeleteConfigurationRecorder、config:StopConfigurationRecorder、guardduty:DeleteDetector、針對 AWSControlTowerExecution 角色的 iam:DeleteRole、針對標籤篩選關鍵金鑰的 kms:ScheduleKeyDeletion。搭配 Control Tower drift detection、監聽 drift 事件並通知 SecOps 的 EventBridge 規則，以及只能透過硬體 MFA 和核准工作流程存取的管理帳號 break-glass 角色。請記得：SCP 不限制管理帳號，因此管理帳號本身必須透過 IAM Identity Center 權限集 + MFA + 核准工作流程嚴格控制，而非依靠 SCP。

Q5：如何將相同的安全基線（日誌、IAM 角色、GuardDuty 調整）套用到每個帳號，包括新帳號？

使用三層方法。(1) Control Tower guardrails 用於 AWS 維護的強制性基線——log archive 保護、CloudTrail 啟用、Config 啟用。(2) 使用服務管理權限的 CloudFormation StackSets 搭配自動部署，目標設定為 OU，用於組織特定資源，如 break-glass 角色和 Config aggregator 授權。(3) Account Factory Customization (AFC) 用於新帳號零日就必須存在的資源——基線 VPC、端點設定、Inspector 啟用。對於現有帳號，一次性 StackSet 操作加上未來的自動部署涵蓋一切。透過委派管理員將 GuardDuty、Security Hub、Macie、Inspector、IAM Access Analyzer 和 Config aggregator 委派給 Audit 帳號，讓它們的組織層級設定自動傳播。

Q6：AWS Organizations 可以不使用 AWS Control Tower 嗎？

可以。AWS Organizations 是底層服務；Control Tower 建立在其上。許多成熟的 AWS 客戶在不使用 Control Tower 的情況下執行 Organizations，並用 CloudFormation StackSets、AWS CDK、Terraform（搭配 AFT）或較舊的 Customizations for AWS Control Tower（CfCT）自行建立 landing zone。你仍然可以使用 SCP、標籤政策、備份政策、AI 退出、Chatbot 政策和委派管理員——這些都是 Organizations 功能，不是 Control Tower 功能。Control Tower 增加了 Account Factory、預建 guardrails 目錄、drift detection、Log Archive/Audit 帳號模式，以及所有這些的主控台 UI。對於 SAP-C02，當情境詢問「達到最佳實踐多帳號基線的最快途徑」時，答案是 Control Tower；當詢問「有自訂 pipeline 的組織最靈活的多帳號設置」時，答案可以是單獨使用 AWS Organizations。

Q7：標籤政策實際上是如何強制執行標籤的？

標籤政策預設透過 AWS Config 和 Resource Groups Tagging API 回報不合規——它們不封鎖標籤建立。要強制執行，標籤政策必須在允許值上使用 "@@assign" 運算子，搭配 "@@enforce"（enforced_for 欄位）列出執行適用的特定資源類型。即便如此，只有部分 AWS 資源類型支援 enforced_for——在依賴此功能之前，請查閱 AWS Organizations 使用者指南中的最新清單。要對每種資源類型進行硬性強制執行，請將標籤政策與使用 aws:RequestTag 和 aws:TagKeys 條件的 SCP 搭配使用，以拒絕在沒有必要標籤的情況下建立資源。這種雙重保險模式是 SAP-C02「防止開發者在整個組織中建立無標籤資源」的標準答案。

Q8：Control Tower drift detection 涵蓋哪些範圍，又不涵蓋哪些？

Control Tower drift detection 監視 landing zone 本身的狀態：Control Tower 附加的 SCP、OU 成員資格、IAM Identity Center 權限集基線、Log Archive 和 Audit 帳號資源，以及強制性控制的啟用狀態。它不監視你的應用程式資源（那是 AWS Config 的工作），也不監視每個帳號中的每個儲存桶政策。當偵測到 drift 時，Control Tower 在主控台中將受影響的帳號或 OU 標記為 drifted，你透過重新註冊 OU、更新帳號或更新 landing zone 來解決它。若有人直接編輯 Control Tower 建立的 SCP，就會引發 drift；若有人在旁邊建立新的 SCP，那是客戶的 SCP，不會引發 drift。將 drift detection 搭配 EventBridge 到 SNS/Slack，以實現即時告警。

延伸閱讀

• AWS Organizations 使用者指南
• AWS Organizations — Service Control Policies
• AWS Organizations — SCP Evaluation Logic
• AWS Organizations — SCP Strategies
• AWS Control Tower 使用者指南
• AWS Control Tower — Account Factory
• AWS Control Tower — Account Factory Customization (AFC)
• AWS Control Tower — Controls (Guardrails) 參考
• AWS Control Tower — Drift
• AWS Organizations — Tag Policies
• AWS Organizations — Backup Policies
• AWS Organizations — AI Services Opt-Out Policies
• AWS Organizations — Chatbot Policies
• AWS CloudFormation StackSets
• Organizing Your AWS Environment Using Multiple Accounts（白皮書）
• AWS Services Integrating with AWS Organizations（委派管理員清單）
• AWS SAP-C02 Exam Guide（PDF）