多帳戶策略：Organizations 與 Control Tower

AWS Organizations 與 AWS Control Tower 是現代 AWS 多帳號策略的兩根支柱，在 SOA-C02 中它們明確歸屬於 Domain 4 Task Statement 4.1——「實作安全的多帳號策略（例如 AWS Control Tower、AWS Organizations）」。考試的切入角度是操作，不是架構設計。SAP-C02（專業級解決方案架構師考試）考的是治理設計——多層 SCP 交集運算、AI 服務退出選項、tag policies、AWS Resource Access Manager（RAM）分享策略、Account Factory for Terraform（AFT）、Customizations for Control Tower（CfCT）——而 SOA-C02 考的是日常運維：用 Account Factory 開一個新帳號、排查 SCP 擋住開發者合法 API 呼叫的原因、啟用 organization trail、跨組織彙整 Config 資料、讀懂 consolidated billing 報表。

本指南以 SysOps 工程師週二早上的視角走過 Organizations 與 Control Tower：開發者被 SCP 擋掉，你要找出是哪條政策在作怪；稽核員要求把所有帳號的 CloudTrail 放進同一個 S3 bucket；新的團隊明天就要一個 sandbox 帳號；Control Tower 儀表板顯示某個 OU 已「drifted」；財務團隊要看九月份按事業單位拆分的帳單。本文框架保持操作導向，將專業級治理架構設計留給 SAP-C02，並在每個步驟指出哪些題型屬於 SOA-C02 範疇、哪些屬於 SAA-C03 或 SAP-C02。

多帳號操作為何落在 SOA-C02 Domain 4

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 4.1 下列出六項技能，其中三項直接觸及多帳號領域：「驗證 service control policies（SCPs）與 permissions boundaries」、「審查 AWS Trusted Advisor 安全性檢查」，以及「實作安全的多帳號策略（例如 AWS Control Tower、AWS Organizations）」。Domain 4 佔 SOA-C02 考試的 16%——65 題中約有 8 到 11 題——多帳號主題通常貢獻其中 3 到 5 題。

操作層級的框架至關重要，因為 SAA-C03 對 AWS Organizations 的涵蓋幾乎只有一行帶過，而 SAP-C02 則有整串題目專門考組織架構設計（多層 SCP 交集、allow-list 與 deny-list 掛載位置、AI 服務退出、tag policies、backup policies、AWS RAM 跨帳號分享模式、AFT 開戶流水線、CfCT 自訂 guardrails）。SOA-C02 介於兩者之間：你必須對 Organizations 有足夠的了解，才能驗證 SCP 的實際效果；對 Control Tower 要有足夠的掌握，才能完成新帳號上線、監控 guardrail 合規狀態，並對 drift 做出反應——但你不需要從頭設計 200 個帳號的階層。考試始終偏向獎勵能讀懂現有 SCP 並預測操作效果的考生，而非能從零寫出一份 SCP 的考生。

白話文解釋 AWS Organizations and Control Tower

Organizations 與 Control Tower 的術語堆疊很快——root、OU、SCP、guardrail、landing zone、Account Factory、drift、delegated admin。三個類比能讓這些概念變得具體好記。

類比一：連鎖便利商店總部與各門市

AWS Organizations 是連鎖便利商店集團總部，旗下管理多家門市（member accounts）。Management account 就是總部——它簽下整個集團的租約、統一支付所有門市的水電帳單（consolidated billing）、制定全集團的營運手冊，並負責招募區域督導。Member accounts 是各地門市，日常出貨、上架、收銀都在這裡發生。Organizational Units 是大區分組——北區 OU、中區 OU、南區 OU——每個大區下轄一批門市。Root 是整個集團法人，是包含每個大區的最上層實體。Service Control Policies 是集團牆上貼的合規守則：「所有門市不得私自引進未核准的供應商」、「任何門市不得在核准區域外展店」。SCP 不賦予門店店長任何新的決定權——那是門市人事任命書（IAM 政策）的事——但它設定了絕對的上限。店長只有在集團守則（SCP）與自己的任命書（IAM 政策）同時允許的情況下，才能採取某個行動。Control Tower 是集團加盟開店藍圖——每次展店，藍圖規定了店面配置、消防設備、標準招牌，以及監控攝影機（landing zone 基準）。Account Factory 是標準開店上線套件。Guardrails 是加盟合約中的固定條款——preventive guardrails 是永遠不得開啟的實體門鎖（SCP 實作），detective guardrails 是記錄違規的監視器，事後調帶查看（Config rule 實作）。Drift 就是店長未經總部同意自行裝修——督導來巡店發現安全門被封死、招牌換了，或監視器被拆掉。

類比二：國家圖書館總館與各分館

AWS Organizations 是國家圖書館系統。總館（management account）制定全系統規則、簽訂出版商授權合約，並統一管理預算。各地分館（member accounts）服務在地讀者。OUs 將分館分群——大安區分群、信義區分群、松山區分群。全系統會員規則（SCP）規定「任何分館不得在未授權情況下向館外借出珍貴典籍」、「每家分館必須使用全系統統一目錄」。個別館員的職務說明（IAM policy）可能允許他向任何人辦理借閱證，但系統規則（SCP）設定上限：只能受理本市市民。兩者都同意，動作才能成立。系統標準採購目錄（Service Catalog）是任何分館可以自助選購的預核准書目清單。CloudTrail organization trail 是全系統借閱紀錄——每家分館的每筆交易都匯入中央存檔。Config aggregator 是全系統館藏盤點表——總館館長隨時可以查詢「目前所有分館的珍本書籍清單，以及哪幾本下落不明」。

類比三：製造業集團與多個廠區

AWS Organizations 是一個製造業集團，旗下有多個廠區（member accounts）。集團總部（management account）制定安全標準、統一管理 ERP，並匯總財務報表。每個廠區（member account）生產自己的產品。OUs 依產線分組——汽車零件 OU、電子零件 OU、包裝材料 OU。SCPs 是集團安全規範——「任何廠區不得在沒有停工鎖定程序的情況下操作機台」、「任何廠區不得儲存超過五千公升的危險化學品」。廠區安全長的日常授權（IAM policy）允許他批准各類操作，但集團規範（SCP）設定了頂線。Control Tower 的 Account Factory 是新廠區標準驗收清單——每次新廠開幕，驗收團隊安裝同款消防系統、同款 ERP 介接、同款稽核日誌。Preventive guardrails 是實體安全聯鎖裝置——不安裝安全護板就無法啟動機台。Detective guardrails 是例行巡檢記錄——稽核員走過每條產線，記錄偏差情形供下週改善會議討論。Drift 就是稽核員抵達時發現有人繞過聯鎖裝置或停止記錄設備維護日誌——廠區已不符合集團基準。Delegated administrator 是區域安全經理——集團已指定某一廠區代表集團執行安全業務，讓總部不必事事插手每家工廠。

Organizations 結構：Management Account、Member Accounts、OUs 與 Root

在理解 SCPs 與 Control Tower 之前，你需要對 Organizations 物件階層有精確的心智模型。

Management account

每個 AWS Organizations 組織都恰好有一個 management account，舊稱 master account。Management account：

• 透過 CreateOrganization 建立組織，並作為 consolidated billing 的根帳單付款人。
• 邀請或建立 member accounts。
• 在 root、OUs 或特定帳號上掛載 Service Control Policies、tag policies、backup policies 及 AI services opt-out policies。
• 啟用受信任的 AWS 服務整合（CloudTrail、Config、Security Hub、GuardDuty、IAM Access Analyzer、RAM、Service Catalog、Backup、License Manager、Systems Manager 等）。
• 指定 delegated administrators，讓特定服務的日常操作移出 management account。
• 永遠不受 SCPs 約束——即使 SCP 掛載於 root，management account 本身也不受組織 SCP 執行的限制。

最後一點是 SOA-C02 最常考的 SCP 陷阱，詳見下方「常見陷阱」一節。

Member accounts

組織內的其他所有帳號都是 member accounts。Member accounts：

• 繼承掛載於 root、路徑上各 OU、以及直接掛載於自身的 SCPs 與其他政策。
• 不自行繳費——所有費用透過 consolidated billing 向上傳至 management account。
• 可以離開組織（需經 management account 同意），再次成為獨立付款帳號。
• 無法呼叫組織管理層級的 API（organizations:* 在組織層級被拒絕，management account 明確委派的讀取類 API 除外）。

Organizational Units（OUs）

OU 是組織內存放帳號及其他 OU 的容器。OU 是結構化機制，讓同一條政策透過一次掛載就套用到整群帳號。SOA-C02 考生在情境題中常遇到的 OU 設計模式：

• 環境導向：Production、Staging、Development、Sandbox——每個環境套用不同的 SCPs。
• 工作負載導向：Workloads/Web、Workloads/Data、Workloads/AI——依工作負載類型套用不同的服務 guardrails。
• 合規導向：Regulated、NonRegulated、Quarantine——套用不同的地區限制與資料落地 SCPs。
• 生命週期導向（Control Tower）：Core、Custom、Sandbox、Suspended——Control Tower 建議的基準 OUs。

OU 最多可在 root 之下巢狀嵌套五層。SOA-C02 的情境題通常只有一到兩層深度，很少用到五層。

Root

Root 是最上層容器，在你建立組織時自動產生。每個組織恰好有一個 root。掛載於 root 的 SCP 套用至每個 OU 及其下方的每個帳號，management account 除外。

SCP 基礎：Allow-List vs Deny-List、NotAction 陷阱與執行邏輯

Service Control Policies 是組織層級治理的運作核心，SOA-C02 對它們的考察力度超過 Organizations 的任何其他概念。

SCP 是什麼，不是什麼

SCP 是權限上限，不是權限授予。它定義了 member account 內任何 IAM principal（使用者、角色、聯合身份）可以執行的最大 API 操作範圍。某個動作要成功，必須同時滿足：IAM 身份政策（或資源政策）允許它，以及 root 到該帳號路徑上每一條 SCP 都允許它。SCP 無法授予權限；若沒有 IAM 政策允許該動作，再多的 SCP 也無濟於事。

任何新組織的預設狀態是 root 上掛載了一條名為 FullAWSAccess 的 SCP。FullAWSAccess 允許 *:* 作用於 *。若不先掛載替代的許可 SCP 就直接卸除它，將導致所有 member accounts 的每個 API 呼叫全部被鎖死——這是有名的操作災難。

FullAWSAccess SCP 是每個新組織出廠附帶的「所有操作皆允許」基準。一旦你從 root 或 OU 卸除它而沒有事先掛載一條能涵蓋工作負載所需操作的替代 Allow SCP，該範圍下每個 member account 的每個 IAM principal 就會失去呼叫任何 AWS API 的能力——包括 SysOps 團隊用來恢復的 API。恢復路徑是使用 management account（不受 SCP 約束）重新掛載 FullAWSAccess 或同等的許可政策。SOA-C02 的正確做法：建立 deny-list SCPs，在保留 FullAWSAccess 的基礎上疊加明確的 deny 規則，並將任何卸除 FullAWSAccess 的操作視為需要事先演練回滾流程的高風險變更。Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html ::

Allow-list 與 deny-list 策略

SCP 有兩種撰寫策略，SOA-C02 對兩者都會考。

Deny-list 策略：保留 root 上的 FullAWSAccess，再新增明確 deny SCPs 來禁止特定操作。心智模型：「除了 X 以外，一切皆允許」。這是常見的操作風格：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApprovedRegions",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"] }
    }
  }]
}

Allow-list 策略：卸除 FullAWSAccess，改掛一條 Effect: Allow 明列許可操作的 SCP。心智模型：「除了 X 以外，一切皆禁止」。這個策略限制更嚴，維護成本也更高，因為每項新推出的 AWS 服務都必須手動加進 allow-list。SAP-C02 對 allow-list 情境的考察比 SOA-C02 多；在 SysOps 考試中，allow-list 模式通常以干擾選項的形式出現，正確答案往往是一條針對性的 deny。

執行邏輯

SCP 的執行規則精確如下：

1. 路徑上任何位置（root SCP、OU SCP、帳號層級 SCP）出現明確 Deny，該動作就被拒絕，無論其他政策如何允許。
2. 若無明確 Deny，則動作必須被路徑上每一條 SCP 明確允許。每個層級的 FullAWSAccess 與自訂 Allow SCP 都算數，取交集後才是許可範圍。
3. 結果再與 IAM 身份政策（以及適用時的資源政策）交叉比對。只有 IAM 也允許的動作才能成功。

交集規則讓多層 SCP 既強大又令人困惑——這是 SAP-C02 的核心治理設計主題。SOA-C02 保持簡單：大多數操作情境使用 deny-list，只在 root 或單一 OU 掛載一兩條明確 deny 規則。

NotAction 陷阱

使用 NotAction 搭配 Effect: Deny 的 SCP 看起來直觀，卻是經典陷阱。Deny + NotAction: [...] 的意思是「拒絕除列出操作以外的所有動作」。配合 Resource: *，這條 SCP 會拒絕 AWS 中所有 API 呼叫，只放行列表中的操作——包括那些被放行操作所依賴的所有支撐 API。SysOps 工程師若寫下這條規則，以為自己在做「只允許這些操作」，實際上卻建立了一條會讓所有日誌記錄、IAM、帳單與標籤操作靜默失敗的全拒政策。

考試正確的思維規則：

• 對於 deny-list SCPs，優先使用 Action（明列要拒絕的操作）。除非你明確要建立一份「殺手名單」，否則避免 NotAction 搭配 Deny。
• 對於 allow-list SCPs，使用 Effect: Allow 搭配 Action（明列要允許的操作）。除非你的意圖就是「允許所有操作，除了這些」，否則避免 NotAction 搭配 Allow。

SOA-C02 常見 SCP 操作模式

考試反覆出現少數幾種 SCP 模式，請熟記每種的結構。

限制地區

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1"] },
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    }
  }
}

記得加上例外清單（對 IAM、Organizations、CloudFront、Route 53、Support 等全球服務使用 StringNotEqualsIfExists），因為這些服務以 us-east-1 回報所在地區，套用單純的地區限制 SCP 會導致它們失效。

要求靜態加密

{
  "Effect": "Deny",
  "Action": ["s3:PutObject"],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

防止停用安全服務

標準模式：deny cloudtrail:StopLogging、cloudtrail:DeleteTrail、config:DeleteConfigurationRecorder、config:StopConfigurationRecorder、guardduty:DeleteDetector、securityhub:DisableSecurityHub。讓每個 member account 無法關閉稽核與安全工具。

限制 instance 規格或服務

在開發環境 OUs 中 deny 啟動昂貴的 instance 家族，或完全 deny 尚未審核通過的服務（例如 iotcore:*、sagemaker:*）。

工作負載帳號的 Allow-list

在嚴格的 allow-list 策略中，某個 OU 可能只收到一條允許 ec2:*、s3:*、lambda:*、cloudwatch:*、logs:*、iam:Get*、sts:* 的 SCP——所有其他操作因為沒有 Allow 而被隱式拒絕。

AWS Control Tower：Landing Zone 的自動化建置

AWS Organizations 提供原始的多帳號基本建構，AWS Control Tower 則在其上包裝了一套 AWS 管理的標準化基準，稱為 landing zone。Control Tower 是大多數多帳號環境用來避免重複造輪子的服務。

Control Tower 建置了什麼

在 management account 啟動 Control Tower 時，它會佈建：

• Landing zone 的 home region（Control Tower 本身運行、audit/log archive accounts 所在的地區）。
• 一個 Security OU，包含兩個新帳號：
  • Log Archive account——接收 organization CloudTrail trail 的目標 S3 bucket、AWS Config 傳遞通道，以及（選擇性地）其他日誌目的地。設計上這裡不執行任何正式工作負載。
  • Audit account（也稱為 security tooling account）——Security Hub、GuardDuty、IAM Access Analyzer 的 delegated admin 帳號，同時提供跨帳號 IAM role 供安全人員稽核 member accounts。
• 一個 Sandbox OU，作為 Account Factory 開戶的預設落點，直到你建立其他 OUs。
• 一條 organization CloudTrail trail，將所有地區的 management 事件從每個帳號傳遞到 Log Archive S3 bucket。
• 每個受管帳號中的 AWS Config recorder，以及 Audit account 中的 aggregator。
• 掛載於 OU 層級的一組 mandatory 與 strongly recommended guardrails。
• 一組 Control Tower 管理的 CloudFormation StackSets，用於在每個帳號與地區中維護上述資源。

SysOps 工程師與 Control Tower 的日常互動

Landing zone 建置完成後，SysOps 工程師通常會：

• 透過 Account Factory 開立新帳號。
• 註冊現有 OUs，讓其下的帳號成為受管帳號。
• 加入既有帳號，讓早於 landing zone 存在的帳號納入管理。
• 隨合規需求演進，在特定 OUs 上啟用更多 guardrails（strongly recommended 或 elective 類別）。
• 新增受管地區（Control Tower 必須被告知要管理哪些地區；範圍外的地區是非受管的）。
• 回應 drift——Control Tower 透過儀表板及 aws.controltower 上的 EventBridge 事件標記 drift。

Account Factory：帳號開立機制

Account Factory 是 Control Tower 的功能，能夠佈建預先套用 landing zone 基準的新 member accounts。SOA-C02 頻繁考察 Account Factory 的操作流程。

CreateAccount 時 Account Factory 做了什麼

1. 透過 Organizations 建立新的 AWS 帳號。
2. 將帳號放入選定的 OU（預設通常是 Sandbox OU）。
3. 套用 OU 的 SCP guardrails，讓帳號繼承政策上限。
4. 部署 Control Tower 基準 StackSet——Config recorder、detective guardrails 的 Config rules、organization CloudTrail member 設定，以及其他 landing zone 資源。
5. 為帳號設定唯一的 email 地址。
6. 掛載 AWSControlTowerExecution role，讓 Control Tower 能管理該帳號。
7. 根據 Account Factory 網路設定，選擇性地預建網路——含預設子網的 VPC。
8. 建立 SSO 使用者（或 AWS IAM Identity Center 使用者）並指派選定的 permission sets，讓人員能夠登入。

Account Factory 所需的輸入

透過 Control Tower 主控台、AWS Service Catalog 或 Account Factory API 開立帳號時，需要提供：

• 帳號名稱與 email（必須是唯一且可送達的 email 地址）。
• 目標 OU（必須是 Control Tower 管理下的已註冊 OU）。
• SSO 使用者資訊（email、名字、姓氏），作為初始登入身份。
• 選擇性的帳號層級標籤，流入 consolidated billing 的成本分攤路徑。

Blueprint 更新的陷阱

Account Factory 在背後使用 Service Catalog 產品。當你變更 Account Factory 網路設定或其他 blueprint 設定時，該變更只適用於之後新開立的帳號。在舊 blueprint 下開立的既有帳號不會自動更新。SysOps 工程師必須明確重跑 StackSet 或手動更新每個帳號的資源，才能讓變更套用到既有帳號。SAP-C02 會考 Account Factory for Terraform（AFT）與 Customizations for Control Tower（CfCT）來處理更完整的 blueprint 更新工作流程；SOA-C02 只要求你知道「blueprint 變更不自動套用」這條基本規則。

Guardrails：Preventive vs Detective、Mandatory vs Elective

Guardrails 是 Control Tower 以打包合規控制項形式提供的精選規則。每條 guardrail 有其類別與行為。

行為：preventive vs detective

• Preventive guardrails 以 SCPs 的形式掛載於受管 OU，在 API 層級封鎖不允許的操作。例如：「禁止變更 CloudTrail」、「禁止 log archive bucket 設定公開讀取」、「禁止刪除 organization trail」。
• Detective guardrails 以 AWS Config rules 的形式在每個受管帳號中持續評估，並在 Control Tower 儀表板上標記不合規的資源，但不會封鎖底層的 API 呼叫。例如：「偵測 root 使用者是否啟用 MFA」、「偵測 EBS volumes 是否加密」、「偵測 S3 buckets 是否開放公開讀取」。

類別：mandatory、strongly recommended、elective

• Mandatory guardrails：始終啟用，在 OU 被註冊時自動掛載。強制執行 landing zone 的基礎防護（禁止停用 CloudTrail、禁止 log archive 設定 S3 公開讀取等）。
• Strongly recommended guardrails：預設關閉，但建議啟用；隨著組織合規成熟度提升由管理員手動開啟。
• Elective guardrails：預設關閉，適用於更窄的或更具情境性的控制需求。

Preventive vs detective 對操作的實際影響

Preventive guardrail 會在操作者嘗試被禁止的動作時產生 AccessDenied 錯誤。操作者立即看到失敗，動作從未發生——但 SysOps 團隊必須回應被 SCP 擋住的合法開發者，並決定是調整 guardrail（罕見）還是讓開發者改變設計（更常見）。

Detective guardrail 在 Control Tower 儀表板上產生不合規發現，並發出 Config rule 事件。規則觸發時不合規狀態已然存在；修補工作事後透過 SSM Automation、Lambda 或人工介入進行。Detective guardrails 與 Config 自動修補流程搭配良好。

Organizations 服務整合：CloudTrail Org Trail、Config Aggregator、Security Hub、GuardDuty

一旦啟用**信任存取（trusted access）**整合 AWS 服務，Organizations 就不只是帳單包裝器了。SOA-C02 考察四種最常用的整合。

CloudTrail organization trail

Organization trail 是在 management account（或 delegated admin）中建立的單一 trail，自動套用至每個 member account，記錄所有地區的 management 事件，並傳遞到單一 S3 bucket（以及選擇性的 CloudWatch Logs group）。Member accounts 無法停用、修改或刪除 organization trail——即使有完整的帳號管理員權限——因為它受 Organizations 整合加上 preventive guardrail 的雙重保護。

兩個操作成果：

• 一個存放每個帳號所有 API 呼叫記錄的稽核 S3 bucket。
• 一個下游工具（Security Hub、Splunk、Athena 查詢）的單一資料來源，而非各帳號獨立的 trail 拼接。

Organization trail 不會阻止 member account 建立自己的額外 trail 以記錄應用程式特定的日誌。Org trail 是地板，不是天花板。

AWS Config aggregator

Config aggregator 從組織內每個帳號（或選定的帳號與地區子集合）收集 Config 設定項目快照與規則評估結果，匯整到單一帳號中。Aggregator 帳號通常是 Control Tower landing zone 的 Audit account。Aggregator 本身不記錄設定；它依賴每個 member account 已啟用並運行 Config recorder，然後彙整結果以供集中查詢（透過 Config 主控台、API 或 Athena）。

SOA-C02 頻繁問到「安全團隊需要一份跨 30 個帳號的所有 S3 buckets 清單」——答案是 Config aggregator，而非拼接各帳號主控台截圖。

Security Hub

Security Hub 彙整來自 GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、AWS Config 及眾多合作夥伴工具的安全發現。啟用 Organizations 整合後，Security Hub 委派給 Audit account 管理，自動加入每個 member account，並在單一儀表板中匯集發現以進行跨帳號的工作流程追蹤。

GuardDuty

GuardDuty for Organizations 遵循相同模式：啟用信任存取、將 Audit account 指定為 GuardDuty delegated admin，GuardDuty 便會自動在每個 member account（包含現有與未來的帳號）上啟用。所有發現都匯流到 delegated admin 的 GuardDuty 主控台。

一般性的 delegated administration

大多數安全與操作服務支援 delegated administration，讓日常操作不必在 management account 中進行。模式如下：在 Organizations 中啟用信任存取，再對選定的 member account 呼叫 RegisterDelegatedAdministrator。該帳號現在可以跨組織管理此服務，management account 則退出日常循環。SOA-C02 要求你知道 Security Hub、GuardDuty、IAM Access Analyzer、Config、Backup、RAM 與 Service Catalog 等服務都建議採用這個模式。

Consolidated Billing 機制

Consolidated billing 是 Organizations 的財務面：整個組織一張發票，並享有跨帳號的效益彙整。

哪些項目會彙整

• 量批定價（例如 S3 儲存空間階梯、資料傳輸階梯）跨所有帳號彙整計算。若帳號 A 使用量落在前 50TB 階梯、帳號 B 落在 450TB 階梯，consolidated billing 先計算全組織的總使用量，再將混合單價分配回各帳號。
• 在任何帳號購買的 Reserved Instances 與 Savings Plans 可以套用到組織內任何地方符合條件的用量（前提是 management account 層級啟用了 RI sharing）。
• AWS Free Tier 額度在組織層級共用——不是每個帳號各自乘一份。

哪些項目不會自動彙整

• Service quotas 是每帳號獨立的。擁有 50 個帳號的組織有 50 份獨立的 vCPU 配額，不是共用的一份。
• IAM 是每帳號獨立的。沒有全組織的 IAM principal；management account 的使用者在 member accounts 中不具備任何隱式存取權。
• 每個帳號的帳單資料在啟用成本分攤標籤後仍對 management account 可見，可用於分攤計費。

成本分攤標籤與 AWS 自動產生標籤

Management account 在 Billing 主控台啟用成本分攤標籤——包括使用者定義標籤（例如 CostCenter、Project、BusinessUnit）與 AWS 自動產生標籤（例如 aws:createdBy）。啟用的標籤會以欄位形式出現在 Cost Explorer 與 Cost and Usage Report（CUR）中，讓你能依團隊或事業單位進行分攤計費。標籤啟用後，大約需要 24 小時才會出現在成本資料中。

CUR 用於進階帳單分析

Cost and Usage Report 以 CSV 或 Parquet 格式將細粒度帳單資料傳遞到 S3。啟用 Organizations 後，management account 收到單一的全組織 CUR；每一列都帶有關聯帳號 ID 與任何有效的成本分攤標籤。標準分析模式是 CUR -> S3 -> Athena 查詢，用於「依帳號分析每月 NAT gateway 費用」或「依環境分析 Aurora 成本」。

Member Account 的上線與移除

新增與移除 member accounts 是 SysOps 工程師最常接觸的操作生命週期。

上線路徑

將帳號加入組織有三種方式：

1. Account Factory（Control Tower）——開立新帳號、將其放入已註冊的 OU、套用 landing zone 基準。操作上最乾淨；組織內任何新帳號的首選路徑。
2. CreateAccount API 或 Organizations 主控台的「Add account」——不透過 Control Tower 基準，直接透過 Organizations 建立純粹的新帳號。用於非 Control Tower 的組織。
3. InviteAccountToOrganization——邀請現有的獨立 AWS 帳號加入。被邀請帳號的擁有者必須接受邀請。接受後，帳號成為 member。

對於透過邀請加入的既有帳號，Control Tower 的 Enroll Account 功能可事後套用 landing zone 基準（有前提條件——部分既有的 CloudTrail 或 Config 設定必須在加入前先行協調）。

移除路徑

• 移除 member account：management account 呼叫 RemoveAccountFromOrganization。被移除的帳號成為獨立帳號，擁有自己的付款關係。帳號在移除前必須完成獨立帳號的必要條件（聯絡電話、帳單付款方式等）。
• 關閉帳號：透過 AWS 帳號關閉流程將帳號完全停用。關閉後有 90 天的恢復視窗，之後資源才會被永久刪除。
• 暫停帳號：與移除不同；AWS Support 可能因帳單或合規原因暫停帳號，但帳號在被移除前仍留在組織中。

日常操作的跨帳號角色

即使 Organizations 與 Control Tower 已建置完成，日常操作仍需切換進 member accounts。兩種在 SOA-C02 中反覆出現的模式：

• OrganizationAccountAccessRole——Account Factory 與 Organizations 的 CreateAccount API 會在新帳號中自動建立這個 role。它信任 management account 並授予 AdministratorAccess。SysOps 工程師從 management account sts:AssumeRole 進入此 role 進行緊急管理。這個 role 只會在透過 Organizations 建立的帳號上自動產生——受邀加入的帳號沒有這個 role，必須手動建立。
• AWSControlTowerExecution——由 Control Tower 在每個受管帳號中建立，信任 Control Tower 本身。不要編輯或移除它；這樣做會導致 drift。
• AWS IAM Identity Center（舊稱 AWS SSO）——現代且受考試青睞的跨帳號存取模式。在 IAM Identity Center 中定義的 permission sets 對應到每個 member account 中的 role；使用者在 SSO 入口一次登入後透過入口介面切換帳號，所有操作皆完整記錄於 CloudTrail。

情境模式：透過 Account Factory 上線新開發團隊

典型的 SOA-C02 情境：「一個新開發團隊需要一個具備公司標準 guardrails、日誌記錄與存取控制的隔離 AWS 環境——操作順序是什麼？」

1. SysOps 工程師登入 management 或 delegated admin 帳號。
2. 開啟 Control Tower 主控台 -> Account Factory -> Create account。
3. 提供帳號名稱（dev-team-acme）、唯一 email（[email protected]）、目標 OU（Sandbox 或已註冊的 Dev OU），以及團隊負責人的 SSO 使用者資訊。
4. 送出。Control Tower 在背後執行 Service Catalog 產品，透過 Organizations 建立新 AWS 帳號、放入 OU、套用 OU 的 SCPs、部署基準 StackSet（Config recorder、organization trail member、預設網路設定），並加入 SSO 使用者與選定的 permission set。
5. 新帳號就緒——通常在 15 到 30 分鐘內——團隊負責人收到 SSO 邀請 email。

情境模式：SCP 擋住開發者的合法操作——排查

另一個典型的 SOA-C02 情境：「一位開發者無法在 us-east-1 啟動 EC2 instance，並收到明確拒絕的錯誤——診斷原因。」

1. SysOps 工程師讀取 member account 中開發者的 CloudTrail 事件：errorCode 是 AccessDenied，errorMessage 提到「with an explicit deny in a service control policy」。
2. 工程師透過列出帳號及每個上層 OU 和 root 掛載的 SCPs 來找出觸發的那條：對每個層級執行 aws organizations list-policies-for-target。
3. 工程師讀取每條 SCP，在 Production OU 找到拒絕 us-east-1 的地區限制政策。
4. 解法取決於意圖：若政策正確且開發者不應使用 us-east-1，開發者必須在 ap-southeast-1 重新部署；若政策有誤，SysOps 工程師在完成變更管理審核後調整 SCP；若開發者的帳號被放入錯誤的 OU，工程師將帳號移至正確的 OU。

考試會問哪個步驟是第一步；操作正確答案是讀取 CloudTrail 錯誤訊息——它在你浪費時間查 IAM 之前就告訴你 SCP 是元凶。

常見陷阱：Control Tower Drift

Control Tower 預期每條 guardrail SCP、每個 OU 註冊、每個基準 StackSet 實例都維持它所設定的狀態。一旦在 Control Tower 之外有所變更——直接在 Organizations 主控台編輯 SCP、透過 Organizations API 手動移動帳號、卸除 guardrail SCP、刪除基準資源——Control Tower 就會在儀表板上標記 drift，並在 aws.controltower 上發出 EventBridge 事件。

常見的 drift 原因：

• SysOps 工程師直接在 Organizations 主控台編輯 guardrail SCP 以新增例外。
• 帳號透過 Organizations API 而非 Control Tower 在 OUs 之間移動。
• Control Tower 管理的 CloudFormation StackSet 實例失敗或被手動刪除。
• Log Archive S3 bucket 政策被修改。

Drift 修補取決於原因：從 Control Tower 主控台重新執行 landing zone 更新可以修復大多數受管資源的 drift；OU drift 透過 Control Tower 將帳號移回來修復；SCP drift 透過還原手動編輯來修復。嚴重的 drift 有時需要升級 landing zone 版本，或在極少數情況下重新執行 Control Tower 設定。

多帳號環境下的 Trusted Advisor 安全性檢查

AWS Trusted Advisor 在帳號層級執行一組精選的檢查，並在五個類別中回報發現：成本最佳化、效能、安全性、容錯能力與服務限制。SOA-C02 Domain 4 明確考察安全性類別的檢查。

SOA-C02 重點的安全性檢查

• Root account MFA：若 root 使用者未啟用 MFA 則發出警報。
• IAM 使用情況：若沒有任何 IAM 使用者（只用 root 操作是一個發現）則發出警報。
• 暴露的存取金鑰：掃描公開來源，尋找與帳號關聯的洩漏 AWS 存取金鑰。
• S3 bucket 公開讀取存取：列出具有公開 ACL 或 bucket 政策的 bucket。
• Security groups — 特定連接埠不受限：列出對危險連接埠（22、3389、1433 等）開放 0.0.0.0/0 的 SGs。
• CloudTrail 日誌記錄：若帳號未啟用 CloudTrail 則發出警報。

多帳號的 Trusted Advisor

Trusted Advisor 本身以帳號為單位運作。在 AWS Support Business 或 Enterprise 方案下，management account 可透過 Trusted Advisor Priority 功能與 Support API 取得組織層級的 Trusted Advisor 資料。沒有 Business 或 Enterprise 支援方案，免費的 Trusted Advisor 檢查僅限於一小部分（通常是五項安全性和三項服務限制檢查）。許多 SOA-C02 題目的關鍵在於考生是否知道完整的 Trusted Advisor 需要 Business 或 Enterprise 支援方案。

將 Trusted Advisor 串入操作工作流程

SysOps 團隊通常將 Trusted Advisor 的刷新排程與 Trusted Advisor EventBridge 事件串接至：

• 每日安全發現摘要的 SNS topic。
• 針對新開啟的高嚴重性發現自動開立工單的 Lambda function。
• 顯示全組織開啟中安全發現數量的 CloudWatch dashboard 自訂 widget。

AWS Service Catalog 的多帳號自助服務

AWS Service Catalog 讓 SysOps 團隊預先核准一組以 CloudFormation 模板封裝的產品（一個 VPC、一個強化的 S3 bucket、一個預裝好 agent 的 EC2），發布為 portfolio，讓任何 member account 的開發者自助取用。Service Catalog 是 Control Tower Account Factory 背後受支援的擴充層：Account Factory 的產品本身就是 management account 中的 Service Catalog 產品。

SOA-C02 為何在乎這個

考試測驗的是讓團隊走上有護欄的自助服務軌道的操作模式，而非直接交給他們管理員金鑰：SysOps 工程師發布一份包含核准產品的 Service Catalog portfolio，透過 Service Catalog 的組織分享（或 AWS RAM）在整個組織共享，開發者不需要自己寫 CloudFormation 就能透過 Service Catalog 啟動產品。這樣的組合正是考試指引中「安全的多帳號策略」所指向的內容。

SOA vs SAA：兩張 Associate 考試對多帳號的差異

SAA-C03 與 SOA-C02 對 AWS Organizations 的處理方式截然不同。重點整理：SAA-C03 幾乎不考。

SAA 考生把 Organizations 視為高層次的成本效益；SOA 考生每週都在運維 Organizations。

SOA vs SAP：專業級治理在哪裡

SAP-C02（解決方案架構師專業考試）擁有多帳號治理設計這個學科。SOA-C02 刻意停在操作邊界。兩者的差異非常明確且與考試直接相關。

如果一道 SOA-C02 題目感覺需要多層 SCP 算術、AI 退出選項、tag policies 或 RAM 跨組織共享，你正在閱讀一道混進你學習材料的 SAP 風格干擾題——實際的 SOA-C02 題目幾乎總是更直接的操作排查或上線情境。保持操作框架。

常見陷阱整理——多帳號操作

每次 SOA-C02 考試都會遇到以下陷阱中的兩三個。

陷阱 1：SCPs 適用於 management account

它們不適用。Management account 豁免於 SCP 執行，無論 SCP 掛在哪裡。不要在 management account 執行工作負載；在那裡改用 IAM、MFA 與 CloudTrail 監控。

陷阱 2：NotAction 搭配 Deny 是一個 allow-list

它是 allow-list 的反義。它拒絕除列出操作以外的所有操作。Allow-list 應使用 Action 搭配 Allow。

陷阱 3：Account Factory blueprint 變更套用到既有帳號

它們不套用。Blueprint 變更只適用於新開立的帳號。既有帳號必須透過 StackSets 或手動修補來更新。

陷阱 4：直接編輯 Control Tower 管理的 SCPs 是安全的

它不安全。直接編輯會導致 drift，並可能在下次 landing zone 更新時被覆蓋。請使用與受管 guardrails 並存的自訂 SCPs。

陷阱 5：SCPs 授予權限

它們不授予。SCPs 只設定權限上限。一個動作要同時需要 SCP 允許和 IAM 允許。

陷阱 6：受邀帳號會自動獲得 OrganizationAccountAccessRole

它不會。這個 role 只在透過 CreateAccount（以及 Account Factory）建立的帳號上自動建立。受邀帳號必須手動建立這個 role。

陷阱 7：Detective guardrails 會封鎖操作

它們不會。Detective guardrails 只在事後標記不合規的資源。需要封鎖時請使用 preventive guardrails。

陷阱 8：免費層 Trusted Advisor 包含所有安全性檢查

它不包含。免費層只顯示有限的子集；完整的檢查需要 AWS Support Business 或 Enterprise 方案。

陷阱 9：成本分攤標籤具有追溯效力

它們沒有。標籤啟用只對未來資料有效，且大約需要 24 小時才會傳播。請在第一天就啟用。

陷阱 10：Organization trail 會阻止每帳號 trail 的建立

它不會。Member accounts 仍可建立自己的 trail 以記錄應用程式特定的日誌。Org trail 是地板，不是天花板。

決策矩陣——每個 SysOps 目標對應的多帳號構件

考試時用這張表快速查詢。

FAQ — SysOps 的 AWS Organizations 與 Control Tower

Q1：我在 root 掛上的 SCP 為什麼不影響 management account？

這是設計行為——無論 SCP 掛在哪裡，management account 都豁免於 SCP 執行。AWS 的理由是：management account 是建立並運作組織本身的實體，若它被自己的 SCPs 鎖住就會造成無法恢復的故障（沒有人能移除鎖住自己的政策）。操作意涵有兩個：永遠不要在 management account 執行真實工作負載，且永遠不要依賴 SCPs 作為 management account 的安全控制。正確做法是：把 management account 當成只有少量緊急存取 IAM 使用者的薄層治理節點，強制 MFA、啟用 IAM Access Analyzer 監控，並透過 CloudTrail 記錄。工作負載只放在 SCPs 確實有效的 member accounts 中。

Q2：Effect: Deny 搭配 NotAction: ["s3:*"] 的 SCP 實際上做了什麼？

它拒絕每個 AWS 服務中除 S3 操作以外的所有 API 呼叫。這幾乎從來不是作者的意圖。「拒絕除 S3 以外的所有東西」聽起來像是 allow-list（「只允許 S3」），但在 SCP 語義中它是一份封殺清單，阻斷工作負載所依賴的所有支撐操作——IAM、CloudTrail、CloudWatch、標籤、角色假冒、帳單、監控。工作負載短暫看似正常，然後以隱晦的方式開始失效。考試正確規則：對於 deny-list，使用 Effect: Deny 搭配明確的 Action 清單（拒絕這些特定的操作）；對於 allow-list，使用 Effect: Allow 搭配明確的 Action 清單（允許這些特定的操作）。只有在你真的確認所有副作用 API 後，才使用 NotAction。

Q3：開發者在 us-east-1 呼叫 ec2:RunInstances 時收到 AccessDenied——我怎麼追蹤原因？

讀取開發者帳號中的 CloudTrail 事件，查看 errorMessage。AWS 包含了特定的文字模式：「with an explicit deny in a service control policy」表示 SCP 封鎖了呼叫，「with an explicit deny in an identity-based policy」表示 IAM 政策封鎖了，「implicit deny」表示沒有政策授予該操作。對於 SCP 封鎖，列出路徑上每條 SCP：帳號層級、上層 OU、祖父 OU……直到 root。對每個層級執行 aws organizations list-policies-for-target --target-id <id>。讀取每條 SCP 找出問題陳述——最常見的是地區限制或服務拒絕。決定要 (a) 讓開發者改部署地區、(b) 將帳號移至不同 OU，還是 (c) 在完成變更管理審核後調整 SCP。第一步永遠是讀 CloudTrail 錯誤訊息；在讀取錯誤訊息之前就直接排查 IAM 只是在浪費時間。

Q4：我們更改了 Account Factory 網路設定，30 個既有帳號沒有更新——這是預期行為嗎？

是的。Account Factory 的變更只套用到變更後才開立的帳號。30 個既有帳號保留了它們開立時的網路設定。若要傳播變更，可以 (a) 透過 Account Factory 產品重新佈建每個帳號（操作負擔重且可能不可接受）、(b) 對既有帳號部署獨立的 CloudFormation StackSet 以更新網路資源，或 (c) 對於專業級組織，使用 Customizations for Control Tower（CfCT）或 Account Factory for Terraform（AFT）來管理帳號基準的生命週期。SOA-C02 要求你知道這個限制，並認識到 StackSets 是 SOA 層級的傳播機制；CfCT 和 AFT 是 SAP-C02 的領域。

Q5：Preventive 與 detective guardrails 在事件回應上有什麼差異？

Preventive guardrail 是在 API 層封鎖不允許操作的 SCP。操作者立即看到 AccessDenied，動作從未發生，SysOps 團隊的任務是 (a) 接受開發者必須採用不同方法，或 (b) 調整 guardrail（罕見）。Detective guardrail 是持續評估資源狀態的 AWS Config rule。規則觸發時不合規狀態已然存在；SysOps 團隊的任務是透過 SSM Automation、Lambda 或人工介入事後修補。當操作本身會造成損害時使用 preventive（停用 CloudTrail、在禁止地區部署、刪除 KMS key）；當狀態可稽核且修補可以延後時使用 detective（未加密的 EBS volume、公開的 S3 bucket）。Detective guardrails 與 Config 自動修補 pipeline 搭配良好。

Q6：為什麼 Control Tower 一直說我們「drifted」，即使重新套用設定後也是？

Drift 表示 Control Tower 管理的資源不再符合 landing zone 定義。你可能遺漏的常見原因：guardrail SCP 直接在 Organizations 主控台被編輯；帳號透過 Organizations API 而非 Control Tower 主控台在 OUs 之間移動；Control Tower 管理的 CloudFormation StackSet 實例在某些帳號中失敗；或 Log Archive S3 bucket 政策被修改。協調 drift 需要修正原始偏差：還原 SCP 編輯、透過 Control Tower 將帳號移回、重新部署失敗的 StackSet 實例，或恢復 bucket 政策。然後從 Control Tower 主控台重新執行 landing zone 更新。若 drift 嚴重且 landing zone 版本過舊，AWS 建議進行 landing zone 版本更新，這個過程本身會重建受管資源。

Q7：Organization trail 與每帳號 trail 的實際差異是什麼？

Organization trail 在 management account（或 delegated admin）中建立一次，自動套用到每個 member account（現有與未來的），記錄所有地區的 management 事件。Member accounts 無法停用、修改或刪除它——即使有完整的帳號管理員權限——因為 org trail 受 Organizations 整合加上 preventive guardrail 雙重保護。結果是一個包含每個帳號所有 API 事件的 S3 bucket 和 CloudWatch Logs group。每帳號 trail 在各自帳號中獨立建立並由該帳號擁有者管理；對於應用程式特定的日誌記錄或非 management 事件的捕捉仍然有用。兩種 trail 可以並存；organization trail 是稽核記錄的地板，每帳號 trail 疊加在上層。SOA-C02 測試 org trail 模式是「稽核員需要一個地方存放所有帳號所有 API 呼叫」問題的正確答案。

Q8：我如何指定 delegated administrator，這為什麼重要？

Delegated administration 將整合服務的日常操作移出 management account。模式如下：在 Organizations 中為服務啟用信任存取（例如 aws organizations enable-aws-service-access --service-principal config.amazonaws.com），再對選定的 member account 呼叫 RegisterDelegatedAdministrator。註冊後，delegated admin 帳號可以執行該服務的全組織操作：查看所有 member 的發現、設定全組織規則、管理 member account 加入。重要原因：AWS 的指引以及 SOA-C02 的考試答案是讓 management account 保持精簡——日常操作沒有人員、不執行工作負載。將 Security Hub、GuardDuty、IAM Access Analyzer、Config、Backup 與 Service Catalog 的管理委派給專用安全工具帳號（通常是 Control Tower landing zone 中的 Audit account）正是遵循這個原則。Management account 成為薄層治理節點，日常工作在受損影響較小的地方進行。

Q9：Member account 可以自行離開組織嗎？

預設情況下不行。移除由 management account 透過 RemoveAccountFromOrganization 發起（或在 management account 明確授予必要權限的情況下由 member account 自行發起，但這很罕見）。即使發起移除，member account 也必須先滿足獨立帳號的必要條件：主要聯絡電話號碼、帳單付款方式、同意獨立的 Customer Agreement 條款。沒有這些，移除就會失敗。在 Control Tower 環境中，帳號在允許移除且不破壞 landing zone 之前，還必須先透過 Control Tower 取消加入。「將帳號移出組織」的操作答案通常是協調 member account 擁有者與 management account、完成獨立帳號必要條件、從 Control Tower 取消加入，然後執行 RemoveAccountFromOrganization。

Q10：跨組織分享 AWS Reserved Instance 與 Savings Plan 效益的正確方式是什麼？

Consolidated billing 會自動將 RI 和 Savings Plan 效益彙整到組織內每個帳號，但前提是 management account 層級已啟用 RI sharing（預設為開啟；如果需要限制 RI sharing，management account 或 member account 可以在帳號層級退出）。啟用 RI sharing 後，在帳號 A 購買的 RI 可以套用到帳號 A 的 RI 數量未用盡時帳號 B 的符合條件用量。Savings Plans 的運作方式相同——在任何地方購買的 SP 可套用到任何地方符合條件的用量。操作意涵是財務團隊通常在 management account 或專用節省帳號中購買 RIs 和 SPs，這樣效益就自然地流向組織其他帳號，無需手動重新分配。SOA-C02 考察的是你知道這個彙整機制的存在，以及退出是以帳號為單位。

考試信號：如何辨識多帳號題型

SOA-C02 的多帳號題目遵循可預測的模式。

• 「AccessDenied with explicit deny in a service control policy」——答案是透過列出帳號及上層 OUs 的政策找出觸發的 SCP，然後決定調整 SCP、移動帳號，或改變開發者的方法。
• 「所有帳號必須有統一的基準」——答案是 Control Tower 搭配 Account Factory，加上 OU 上適當的 guardrails。
• 「稽核員需要所有帳號的所有 API 呼叫存放在同一個 bucket」——答案是在 management 或 delegated admin 帳號中的 organization CloudTrail trail。
• 「安全團隊需要跨組織資源的單一盤點」——答案是 Config aggregator，通常在 Audit account 中。
• 「限制部署至核准的地區」——答案是 SCP 搭配 aws:RequestedRegion deny condition，加上全球服務的例外。
• 「新團隊需要快速取得 sandbox 帳號」——答案是 Account Factory 開戶至 Sandbox OU。
• 「依事業單位分攤成本」——答案是在 Billing 主控台啟用成本分攤標籤，加上 Cost Explorer 或 CUR。
• 「Control Tower 儀表板顯示 drift」——答案是找出在 Control Tower 之外被變更的項目，然後還原它或在旁邊加掛自訂 SCP/StackSet。
• 「Management account 不應執行工作負載」——答案是 delegated administration 加上專用安全工具帳號，工作負載只在 member accounts 中運行。
• 「帳號層級的服務配額被用盡」——答案是申請 service quota 增加，而非 consolidated billing 彙整；配額不會共用。

延伸閱讀與相關操作模式

• What is AWS Organizations
• AWS Organizations Terminology and Concepts
• Service Control Policies (SCPs)
• SCP Evaluation Logic
• AWS Organizations Quotas
• AWS Service Integrations with Organizations
• What is AWS Control Tower
• Getting Started with AWS Control Tower
• AWS Control Tower Account Factory
• About Guardrails in AWS Control Tower
• Detect and Remediate Drift in Control Tower
• Creating a CloudTrail Trail for an Organization
• Multi-Account Multi-Region AWS Config Aggregation
• Security Hub with AWS Organizations
• Managing GuardDuty Accounts with AWS Organizations
• Consolidated Billing for AWS Organizations
• AWS Trusted Advisor
• AWS Service Catalog Administrator Guide
• AWS SOA-C02 Exam Guide v2.3 (PDF)

多帳號基礎就緒後，接下來的操作層次包含：IAM Policies、MFA、SCPs 與存取疑難排解（補充 org 層級 SCPs 的帳號內權限診斷）、CloudTrail 與 AWS Config 稽核與合規（流入 organization trail 與 aggregator 的偵測與修補 pipeline）、CloudFormation Stacks 與 StackSets（跨組織傳播基準更新的 IaC 機制），以及成本可視化、預算與資源調整（建立在 consolidated billing 之上的分攤計費與預算動作流程）。

• IAM Policies, MFA, SCPs, and Access Troubleshooting — SOA-C02 Study Notes
• CloudTrail and AWS Config for Audit and Compliance — SOA-C02 Study Notes
• CloudFormation Stacks, StackSets, and Troubleshooting — SOA-C02 Study Notes
• Cost Visibility, Budgets, and Resource Rightsizing — SOA-C02 Study Notes