多帳戶環境的成本優化與可視性

成本可視性與多帳號計費，是 AWS 解決方案架構師 Professional 級別最能展現真正功力的考點。SAP-C02 Domain 4（持續改善現有解決方案，29% 比重）與 Domain 2（設計新解決方案，29% 比重）反覆考查：在同一個 AWS 組織下，當帳號數量達到數十甚至數百個時，如何讓每一分支出都可見、可歸因、可管控——同時又不破壞各帳號的自治性。因此，多帳號成本可視性設計並非單一服務，而是一套分層架構：以集中計費為基礎，透過標籤政策與成本配置標籤實現費用歸因，以 Cost Categories 進行群組化，再以 AWS Cost and Usage Report 加上 Amazon Athena 支援客製分析，以 AWS Billing Conductor 產生 proforma 計費回沖報表，以 AWS Cost Anomaly Detection 進行 ML 異常警報，最後以組織層級 AWS Budgets 完成執行管控。本指南以 SAP-C02 Professional 深度逐層拆解，包含真實情境（例如母公司需要向二十家子公司計費回沖 IT 費用）、白話類比、常見陷阱與 FAQ。

什麼是多帳號 AWS 組織的成本可視性？

多帳號成本可視性，是指在同一個地方、持續地對你所擁有的每一個 AWS 帳號回答五個問題：誰在花錢、花在哪個服務、為了哪個專案、對應哪個預算，以及這筆花費是否正常。在單一 AWS 帳號中，這件事非常簡單——AWS Cost Explorer 加上幾個標籤就能搞定。但在擁有三十到三百個成員帳號的多帳號 AWS 組織中，同樣的問題就演變成一個分散式系統難題：你需要集中的帳單資料、標準化的標籤、一致的群組、共用的承諾、委派的分析能力，以及在每個成員帳號中都能生效的管控機制——且不需要賦予中央 FinOps 團隊每個帳號的管理員權限。

SAP-C02 考試測驗的，就是你能否端對端地設計這套架構。多帳號成本可視性在 SAP-C02 上考的不是「哪個工具存在」（那是 CLF-C02 的範圍），而是「給定這種組織形態，哪種工具、政策與帳號角色的組合，才能讓成本可視性與計費回沖在規模化下正常運作」。

為何多帳號成本可視性在 SAP-C02 如此重要

來自近期 SAP-C02 考生的社群資料顯示，多帳號成本可視性情境反覆出現於 Domain 4（優化現有工作負載）與 Domain 2（設計新多帳號 Landing Zone）。最高頻的陷阱包括：在錯誤的帳號啟用成本配置標籤、忘記 Reserved Instance 與 Savings Plans 共用預設為開啟以及如何選擇性停用、將 AWS Billing Conductor 與 AWS Cost Categories 混淆用於計費回沖，以及誤以為標籤政策本身能強制執行標籤——它只驗證合規性，並不阻止資源建立。

白話文解釋多帳號成本可視性

多帳號成本可視性聽起來很複雜，因為它把七個服務串在一起。三個類比能讓整個架構豁然開朗。

類比一：連鎖手機方案的家庭共享帳戶

AWS Organizations 集中計費就像台灣電信業者提供的家庭共享行動方案。每位家庭成員（成員帳號）有自己的門號，自行使用流量，但每月帳單統一寄給同一位家庭代表——付款人。電信業者提供的量大折扣適用於整份方案：如果爸爸購買了三年期的預付吃到飽方案（Reserved Instance 或 Savings Plans），媽媽的流量也能使用這份方案，因為整個家庭共享配額。如果爸爸想停止和一直超用流量的青少年子女（某個特定成員帳號）共享，可以在電信業者的後台（付款人的帳單偏好設定）把那條門號的共享關掉。成本配置標籤就是家人在每支手機上貼的標籤（「學校」、「工作」、「遊戲」），這樣帳單來的時候就能依用途拆算費用。AWS Cost Categories 是比這些標籤更高層的家庭預算分類：「孩子」、「大人」、「共同水電」。AWS Billing Conductor 則是當爸爸決定把手機方案轉售給表親並加收一點手續費、然後印出客製化帳單時所發生的事——電信業者仍然向爸爸收原價，但表親看到的是一份加了手續費、帶有品牌設計的帳單。

類比二：辦公大樓的電表系統

想像一棟二十層的辦公大樓。集中計費是地下室接收真實電費帳單的總電表。每層租戶樓層都有一個子電表——那就是各自有用電記錄的成員帳號。成本配置標籤是每層樓每台設備上的標籤（「會議室」、「伺服器間」、「茶水間」）。標籤政策是印在租約裡的大樓管理規範：「每層樓每台設備都必須貼上核准清單中的成本中心標籤。」規範說明了什麼是合規的，但大樓管理處仍需派稽查員去執行——在 AWS 中，這個執行力道來自 Service Control Policies 搭配 IAM condition keys，而非標籤政策本身。AWS Cost Categories 是大樓管理處在每月報表中把各樓層分組為業務單位的方式（「1–5 樓 = 零售部門」）。AWS Cost and Usage Report 是每台設備每小時的原始用電記錄，用 USB 隨身碟寄給會計師。AWS Billing Conductor 是大樓業主依每位租戶議定的費率重新開單——電力公司仍向業主收取批發價。AWS Cost Anomaly Detection 是智慧電表供應商的 ML 系統，在某個安靜的週日 12 樓突然用電三倍時通知業主。

類比三：掛號郵件系統

集中計費是國家郵政局把所有郵件（每一張 AWS 發票明細）路由到同一個信箱——付款人帳號。每個成員帳號是一位掛號寄件人。標籤政策是郵遞區號格式規則——你的地址必須符合驗證格式，而標籤政策會回報哪些寄件人不合規，但如果不搭配 SCP 在門口守門，並不會阻止你投遞一個沒貼標籤的包裹。成本配置標籤是貼在每個包裹上、告訴分揀機器應將費用路由到哪裡的標籤。AWS Cost Categories 是把多個郵遞區號分組在一起的更高層級郵政區域。AWS Cost and Usage Report 是今天處理的每件包裹的清單，以 CSV 格式寄送到你的倉庫（Amazon S3）。AWS Billing Conductor 是一家被授權的快遞轉售商，在開單給最終客戶之前重新定價每件包裹的運費，而郵政局仍以批發價向快遞公司收費。

牢記這三個心智模型——家庭手機方案、辦公大樓電表、掛號郵件系統——每道 SAP-C02 多帳號成本可視性題目都會變成設計練習，而不是記憶練習。

多帳號成本可視性參考架構

每一套嚴肅的多帳號成本可視性設計都在 AWS Organizations 上疊加七層能力。把它想成一個堆疊。

Layer 0 — 啟用所有功能的 AWS Organizations

沒有這個，其他一切都不會運作。你必須在 AWS Organizations 中啟用所有功能（而非只有集中計費），才能解鎖標籤政策、Service Control Policies (SCPs)、委派管理，以及承諾共用控制。每個多帳號成本可視性模式都以此為基線。

Layer 1 — 集中計費與承諾共用

付款（管理）帳號在此成為開票的單一真實來源，量大折扣累計生效，Reserved Instance 與 Savings Plans 承諾跨成員帳號生效。

Layer 2 — 標籤政策與成本配置標籤啟用

標籤政策存在於 AWS Organizations 中並定義標籤綱要。將每個使用者定義標籤啟用為成本配置維度的動作，必須在付款人帳號的帳單偏好設定中進行。多帳號成本可視性依賴這兩者的組合。

Layer 3 — Cost Categories

以規則為基礎的群組化，能在標籤不一致與組織重整中存活。集中定義，在 Cost Explorer、Budgets 與 Cost and Usage Report 中可見。

Layer 4 — AWS Cost and Usage Report + S3 + Athena

原始每小時明細交付到 Amazon S3，以 Amazon Athena 分區查詢，透過 Amazon QuickSight 或任何 BI 工具呈現——用於內建主控台無法產生的多帳號成本可視性儀表板。

Layer 5 — AWS Billing Conductor

Proforma 計費群組、客製定價規則、客製明細項目，以及當組織需要對下游單位或外部客戶重新定價時使用的計費回沖式發票。

Layer 6 — AWS Cost Anomaly Detection 與組織層級 Budgets

持續性 ML 異常監控，加上組織層級的門檻型 AWS Budgets，從可視性到警報到治理形成閉環。

AWS Organizations 集中計費 — 基礎架構

AWS Organizations 集中計費將每個成員帳號的使用量合併成一張發票，由付款人（管理）帳號支付。成員帳號保留其自治性：它們擁有自己的資源、IAM、VPCs、日誌。改變的是，它們的計費明細流向付款人。

集中計費的三大財務超能力

1. 每個組織只有一張發票 — 一份 PDF、一筆 ACH、一套稅務文件。付款人帳號可看到依成員帳號分組的明細項目。
2. 分層量大折扣累計計算 — 使用量分層定價（Amazon S3 儲存分層、Amazon EC2 資料傳輸分層、AWS Lambda 分層）基於整個組織的合計使用量計算。分布在五十個成員帳號的 100 TB 用量，按 100 TB 分層定價，而不是五十個小分層。
3. RI 與 Savings Plans 共用 — 在任何帳號（包括付款人）購買的 Reserved Instance 或 Compute Savings Plan，若有未使用的部分，預設可覆蓋組織中任何其他帳號的相符用量。

集中計費免費

AWS Organizations 或集中計費不收取額外費用。你只需支付底層資源的使用費。

你必須掌握的承諾共用機制

• Zonal Reserved Instances（綁定特定可用區的 EC2 RI）優先套用到購買帳號，若共用開啟則套用到組織中任何相符用量。
• Regional Reserved Instances 在同一區域跨可用區生效，開啟共用後也跨帳號生效。
• Compute Savings Plans 最靈活：組織中任何帳號的相符 EC2、Fargate 與 Lambda 用量都可消耗。
• EC2 Instance Savings Plans 限定特定區域與執行個體系列，但仍可跨組織共用。
• 共用不等於購買授權 — 你可以停用共用而不改變誰擁有該承諾。

集中計費限制

• 預設上限為 10 個成員帳號，可透過 AWS Support 申請提升至數千個。
• 每個組織只有一個付款人；付款人本身不能成為另一個組織的成員。
• 點數、免費方案與支援計畫定價在付款人帳號層級生效——每個成員繼承付款人的支援計畫等級。

標籤政策與成本配置標籤 — 誰花了什麼

標籤是費用歸因的基本單元，但在多帳號環境中，你必須區分三個不同的職責：定義標籤綱要（標籤政策）、對資源套用標籤（SCP 加 IAM 加自動化），以及將標籤啟用為成本維度（付款人帳單偏好設定）。

步驟一 — 在標籤政策中定義標籤綱要

標籤政策是一種 AWS Organizations 政策類型，可驗證組織中各資源允許使用哪些標籤鍵與值。標籤政策可能規定：標籤鍵 CostCenter 必須存在，大小寫必須嚴格為 CostCenter（而非 costcenter），且其值必須來自核准清單 {CC-100, CC-200, CC-300, ...}。標籤政策可附加到根、OU 或特定帳號。

步驟二 — 了解標籤政策實際上能做什麼（與不能做什麼）

標籤政策驗證合規性——它按資源回報標籤是否符合綱要——但本身不會阻止不合規的標籤被建立。要執行強制，需要在標籤政策中針對支援的資源類型啟用「防止不合規操作」旗標（僅部分服務支援），或結合標籤政策與 SCP 及 IAM condition keys（如 aws:RequestTag/CostCenter 和 aws:TagKeys）來拒絕沒有必要標籤的資源建立請求。

步驟三 — 在付款人帳號啟用成本配置標籤

啟用標籤作為成本配置維度的動作，只發生在付款人（管理）帳號的帳單偏好設定中。即使成員帳號建立了資源並套用了標籤，也無法啟用成本配置標籤——這是組織層級的決策。有兩種類型：

• 使用者定義標籤 — 你自行建立的所有標籤（CostCenter、Project、Environment）。逐一啟用。每個付款人最多可有 500 個啟用中的使用者定義成本配置標籤。
• AWS 生成標籤 — aws:createdBy、aws:cloudformation:stack-name 等。當使用者標記不一致時，對預設歸因很有用。在相同位置啟用。

啟用後，標籤維度會在約 24 小時內出現在 AWS Cost Explorer、AWS Budgets、AWS Cost Categories 與 AWS Cost and Usage Report 中。啟用前的歷史資料不會回填——標籤只從啟用時點起開始歸因費用。

大規模推行標籤治理的正確做法

1. 將標籤綱要以標籤政策的形式附加到組織根。
2. 對每個支援的資源類型啟用標籤政策的「防止不合規操作」旗標。
3. 在每個 OU 附加 SCP，拒絕在 aws:RequestTag/CostCenter 缺失或不在核准清單中時執行 RunInstances、CreateBucket、CreateFunction 等動作。
4. 在 CI/CD 流水線中對相同綱要執行 cfn-lint / tflint / Checkov 規則，在部署前攔截。
5. 在付款人帳號的帳單偏好設定中啟用標籤。
6. 以 AWS Config 規則（required-tags）與標籤政策合規報告監控合規情況。

AWS Cost Categories — 標籤之上的群組化

AWS Cost Categories 是集中定義的規則型群組，可作為 AWS Cost Explorer、AWS Budgets 與 AWS Cost and Usage Report 中的一級維度。每個類別有名稱（例如 BusinessUnit）以及一組規則，每條規則對應一個值（例如 Retail、Wholesale、Corporate）。

為何 Cost Categories 優於單獨使用標籤

標籤在規模化時會因三個原因失敗：漂移（拼錯、舊資源缺標籤）、粒度是資源層級而非帳號或服務層級，以及無法組合（你無法輕易把「這個帳號加上那個服務加上這個區域」合併成一個桶）。Cost Categories 解決了這三個問題。

Cost Categories 規則維度

Cost Categories 規則可根據以下條件比對：

• 關聯帳號 ID（或清單）
• 服務（例如 Amazon EC2、AWS Lambda）
• 區域
• 使用類型
• 費用類型（使用、稅費、點數、定期費用）
• 標籤鍵/值
• 另一個 Cost Categories 值（巢狀）

繼承值

一種特殊規則類型可讓 Cost Category 繼承現有標籤的值——如果你已有成熟的 CostCenter 標籤，類別可以直接繼承每個值，無需為每個成本中心手寫一條規則。這是將標籤驅動歸因作為穩定報告維度暴露出來的最簡潔方式。

費用拆分

Cost Categories 支援針對共用成本（例如 Reserved Instance 攤銷、共用的 Amazon ECR）的費用拆分——你定義一個拆分規則（按比例、平均或固定），跨成員值產生計費回沖報表，無需手動計算。

AWS Cost Allocation Reports 與 Cost and Usage Report (CUR)

AWS Cost and Usage Report (CUR) 是 AWS 帳單的原始資料表。組織中每個資源每小時的每一筆明細，都會以壓縮 CSV 或（更佳）Apache Parquet 格式落到你指定的 Amazon S3 儲存桶。CUR 與 Cost Explorer 讀取的是相同資料；你只是選擇繞過受管儀表板，自行執行分析堆疊。

CUR 交付機制

• 由 AWS 帳單系統交付到你在付款人帳號（或委派帳單帳號）中擁有的 S3 儲存桶。
• 至少每天一次；預設內容顆粒度為每小時。
• 選項：以 GZIP 或 Parquet 格式壓縮、覆寫或版本化、是否包含資源 ID、依帳單週期分割。
• 啟用報告上的「Athena 整合」可與 AWS Glue Data Catalog 整合——AWS 會自動建立 Glue 表格、依帳單週期分區，並自動更新綱要。

CUR + Athena 多帳號成本可視性架構

多帳號成本可視性分析的標準堆疊如下：

1. 付款人帳號設定啟用 Athena 整合的 CUR，格式 Parquet、每小時顆粒度、包含資源 ID。
2. CUR 寫入付款人帳號區域的 S3；AWS Glue 爬蟲（自動管理）保持分區最新。
3. 集中分析帳號（通常是委派帳單管理員帳號）透過跨帳號 S3 存取（儲存桶政策授予分析帳號 IAM 角色 s3:GetObject 和 s3:ListBucket），經由 Athena 查詢。
4. 分析師對 aws_billing_cur_* 表格執行 SQL，產生每個 BU、每個專案、每個服務的月度報表。
5. Amazon QuickSight 以 Athena 作為資料來源，向財務與工程主管發布儀表板。

CUR vs 舊版 Cost Allocation Report

AWS 最初提供「Cost Allocation Report」——一份簡單的月度 CSV。CUR 是其後繼者與超集：每小時、更豐富的欄位、資源 ID、RI/SP 歸因。在 SAP-C02 中，只要題目提到 Athena、QuickSight、Parquet、BI、每小時明細或客製成本儀表板，請以 CUR 作為標準答案。

CUR 欄位速查表

• lineItem/UsageAccountId — 產生費用的成員帳號。
• lineItem/ProductCode、lineItem/UsageType、lineItem/Operation — 費用的服務與操作類型。
• lineItem/ResourceId — 特定資源的 ARN 或 ID（選擇加入時）。
• lineItem/UnblendedCost、lineItem/BlendedCost、lineItem/NetUnblendedCost — 費用欄位（blended 將 RI/SP 折扣分攤給所有使用者；unblended 顯示原始費用；net 計入折扣計畫）。
• resourceTags/user_CostCenter — 每個已啟用的使用者定義標籤都會成為一個欄位。
• savingsPlan/SavingsPlanARN、reservation/ReservationARN — 承諾歸因欄位。

AWS Billing Conductor — Proforma 計費與回沖

AWS Billing Conductor 是為組織內帳號群組產生 proforma（即替代）帳單的服務，使用你定義的客製定價規則。AWS 仍向付款人收取真實費用；Billing Conductor 為每個計費群組產生一份單獨的客製定價視圖，用於計費回沖、轉售或公司內部會計。

Billing Conductor 的四個組成要素

1. 計費群組（Billing groups） — 共用一份 proforma 帳單的成員帳號集合。每個成員帳號最多只能屬於一個計費群組。計費群組有一個主要帳號，負責接收 proforma 發票視圖。
2. 定價規則（Pricing rules） — 可重複使用的規則，用於修改價格。類型包括全局加/減價（例如所有服務 +5%）、按服務加/減價、分層定價，以及 Savings Plans 抵消（從未購買 SP 的群組中移除 SP 折扣）。
3. 定價計畫（Pricing plans） — 套用到計費群組的定價規則命名集合。
4. 客製明細項目（Custom line items） — 固定或百分比的額外費用（例如「每月受管服務費 $5,000」、「安全工具分攤 2%」），由 Billing Conductor 加到 proforma 帳單中。

Proforma 帳單 vs 真實帳單

• 真實帳單 — AWS 向付款人收取的費用。依 AWS 實際費率減去整個組織擁有的 RI/SP 折扣計算出 blended/unblended 費用。
• Proforma 帳單 — Billing Conductor 依設定的定價計畫為每個計費群組計算出的費用。呈現於 Billing Conductor 主控台、專用的 proforma Cost and Usage Report，以及 AWS Cost Explorer 中依計費群組篩選後的視圖。

真實帳單與 proforma 帳單的差額，就是轉售商或中央 IT 保留的利潤（加價）或吸收的補貼（減價）。Billing Conductor 專門用來揭示這個計算過程，讓財務可以對帳。

Billing Conductor 是正確答案的時機

• 母控股公司需要依客製內部費率向子公司進行 IT 費用的計費回沖。
• 受管服務提供商向終端客戶加價轉售 AWS，並需要帶品牌的客製定價發票。
• 內部「平台團隊」想要在業務單位的基礎設施費用上疊加一筆固定「工具費」。
• 各地區需要加上本地支援成本的區域附加費。

Billing Conductor 不是正確答案的時機

• 你只需要查看依業務單位分組的費用 → 使用 AWS Cost Categories（免費、無需重新定價）。
• 你只需要回報誰花了多少錢 → 使用 CUR + Athena。
• 你需要強制執行支出上限 → AWS Budgets 搭配 Budget Actions，而非 Billing Conductor。
• 你需要真實的 AWS 折扣 — Billing Conductor 不改變 AWS 對付款人的收費；它只重新定價你向下游展示的內容。

跨帳號資料流摘要

Reserved Instance 與 Savings Plans 共用控制

承諾共用是集中計費隱藏的超能力——在成熟的多帳號成本可視性設計中，也是受到嚴格控制的能力。SAP-C02 需要掌握三個情境。

情境 A — 預設共用（最常見）

中央「承諾採購台」在付款人帳號購買 Compute Savings Plans。共用開啟時，組織中任何帳號相符的 EC2/Fargate/Lambda 用量優先消耗 Savings Plan 配額（較便宜），然後才落到 On-Demand。財務使用 unblended vs blended 費用或 Cost Category 費用拆分規則，將承諾費用攤銷到各消耗帳號。

情境 B — 選擇性停用

一家子公司加入組織，但出於稅務或法規要求，必須看到自己未折扣的費用。付款人對該成員帳號停用承諾共用。此後該帳號按 On-Demand 費率計費，即使組織擁有閒置承諾；反之，該帳號購買的任何承諾也只對自己生效。

情境 C — 全組織停用

組織選擇將承諾嚴格分配給購買帳號（罕見，通常出於法律實體隔離需求）。每個帳號的用量只對應自己擁有的承諾。你失去彈性，但獲得乾淨的每實體帳務。

如何切換承諾共用

• 僅在付款人帳號，前往 AWS Billing → Billing preferences → Receive AWS Organizations Savings Plans / Reserved Instance discount sharing。
• 按成員帳號切換，或切換整個組織。
• 變更於下一個帳單日生效，無法追溯套用。

AWS Cost Anomaly Detection — 跨組織的 ML 監控

AWS Cost Anomaly Detection 是 AWS Cost Management 中免費、選擇性加入的 ML 服務，它學習你的正常支出模式，並在每日支出出現顯著偏差時發出警報。對於多帳號成本可視性，關鍵設計選擇是監控器類型。

四種監控器類型

1. AWS services — 一個監控器，監視所有帳號的每個服務（預設）。
2. Linked account — 每個成員帳號或每組帳號一個監控器。
3. Cost category — 每個 Cost Category 值一個監控器（例如每個業務單位一個）。
4. Cost allocation tag — 每個已啟用的標籤值一個監控器（例如每個專案一個）。

中型組織的建議模式

• 一個 AWS services 監控器作為安全網。
• 每個生產環境成員帳號一個 linked account 監控器，透過 SNS 發送警報給該帳號擁有者。
• 每個業務單位一個 Cost Category 監控器，發送警報給 FinOps 通知群組。

警報訂閱機制

• 警報發送到 SNS 主題或電子郵件，門檻以絕對金額或基準百分比表示。
• Cost Anomaly Detection 本身免費；SNS 扇出按標準費率計費。
• 警報包含根因拆解：貢獻最多的前 10 個使用類型與關聯帳號。

組織層級的 AWS Budgets

AWS Budgets 通常以單一帳號工具介紹，但在 SAP-C02 中你必須知道它也是多帳號治理工具。從付款人帳號，你可以建立範圍跨越成員帳號、Cost Categories、成本配置標籤或特定服務的預算——並對其採取行動。

組織層級預算模式

• 組織主預算 — 一個組織層級的費用預算，當月至今或預測支出超出門檻時警報財務。
• 每 BU 預算 — 範圍限定每個 Cost Category 值的預算，警報 BU 負責人。
• 每成員帳號預算 — 每個生產環境帳號一個，警報帳號團隊與中央 FinOps SNS。
• 承諾覆蓋率預算 — 跨組織的 RI 覆蓋率與 Savings Plans 覆蓋率預算，當覆蓋率低於（例如）75% 時警報。
• 承諾使用率預算 — 當擁有的承諾使用率低於（例如）80% 時警報，這代表購買過多。

Budget Actions 用於治理

Budget Actions 是 AWS 費用管理中唯一能採取自動化行動的功能。設定預算在觸發時：

• 對使用者或角色套用限制性 IAM 政策（例如拒絕 ec2:RunInstances 和 rds:CreateDBInstance）。
• 對特定 OU 或帳號附加限制性 SCP（例如拒絕所有 ec2:* 寫入操作）。
• 停止標記有相符鍵的 EC2 或 RDS 執行個體。

Budget Actions 可以在人工核准模式（類似 CloudWatch 警報）或自動模式（觸發後立即執行）下運作。

整合起來 — 母公司向 20 家子公司計費回沖 IT 費用

這是 SAP-C02 多帳號成本可視性的經典情境。端對端走過一遍，考試出現任何變體你都能認出來。

情境

一家控股公司有一個中央 IT 組織，在 AWS 上運行共用平台服務（VPCs、網路、日誌、CI/CD、安全工具），並為 20 家子公司承載工作負載。每家子公司都是獨立的法律實體，需要以合約議定的內部費率取得自己的 proforma 發票。中央 IT 想要：(a) 查看每家子公司的支出；(b) 依每家子公司的客製費率開立計費回沖發票；(c) 執行每家子公司的預算；(d) 在付款人帳號保留購買的 Savings Plans 承諾但與除一家以外的所有子公司共用（新收購的子公司在第一年仍需獨立計算費用）。

參考設計

Organizations 佈局

• 1 個付款人帳號（管理）。
• 20 個子公司 OU，每個包含該子公司擁有的 1–N 個成員帳號。
• 1 個共用服務 OU，包含平台/日誌/網路/安全帳號。
• 1 個分析 OU，含一個委派帳單管理員帳號。

集中計費與承諾

• 所有子公司在集中計費下。
• Compute Savings Plans 在付款人帳號購買。
• RI/SP 共用對 19 家子公司開啟，對新收購子公司關閉（付款人帳單偏好設定中的按帳號切換）。

標籤治理

• 標籤政策附加到組織根，要求每個支援的資源類型帶有 CostCenter、Project、Environment、Owner 標籤。
• 在每個子公司 OU 附加 SCP，拒絕在 aws:RequestTag/CostCenter 缺失或不在核准值清單中時執行 RunInstances、CreateBucket、CreateFunction 等動作。
• 在付款人帳號啟用全部四個標籤鍵的標籤配置。

費用分組

• 一個 Cost Category Subsidiary，規則將每家子公司 OU 的帳號 ID 對應到一個值（SubA、SubB、… SubT）。
• 一個 Cost Category ServiceBundle，將共用服務費用（中央 VPC、日誌、安全）分組為 PlatformShared，並設定按比例分攤到每家子公司直接運算支出的費用拆分規則。

計費回沖引擎

• AWS Billing Conductor 設定每家子公司一個計費群組（共 20 個計費群組）。
• 每個計費群組一份定價計畫，包含全局加價（例如 +8%）加上固定平台費用的客製明細項目。
• 每個計費群組啟用 Proforma CUR，交付到分析帳號的 S3，供子公司端報告使用。

客製分析

• 在付款人帳號啟用含 Athena 整合的真實 CUR，以 Parquet 格式每小時交付到付款人 S3。
• 儲存桶政策授予分析帳號讀取存取。
• 每家子公司設定獨立的 Glue Data Catalog + Athena 工作群組。
• QuickSight 儀表板：「依子公司的月度支出」、「依子公司的 Savings Plans 覆蓋率」、「本月費用最高的前 10 個資源」——每日更新。

異常與治理

• 每家子公司一個 Cost Anomaly Detection 監控器（linked-account 類型），加上每個 Cost Category 值一個監控器。
• 組織層級主預算設在計畫的 110%，警報 CFO。
• 每家子公司費用預算設在 100% 和 120%，警報子公司 CFO 與中央 FinOps。
• 跨組織 Savings Plans 使用率預算設在 80%，警報承諾採購台。
• 一家關鍵生產子公司設定了 Budget Action，當月度預算達到 150% 時在其 OU 套用拒絕 ec2:RunInstances 的 SCP。

為何每個服務是正確答案

• 集中計費 + 承諾共用 → 財務合池，按帳號共用切換解決新收購子公司的問題。
• 標籤政策 + SCP + 付款人端啟用 → 一致、強制執行、可報告的歸因。
• Cost Categories → 穩定的「Subsidiary」與「ServiceBundle」維度，含共用平台費用的費用拆分。
• CUR + Athena + QuickSight → AWS 主控台無法產生的儀表板（每小時、客製 join、子公司範圍限定）。
• Billing Conductor → 以子公司看到的客製費率產生 proforma 計費回沖。
• Cost Anomaly Detection + Budgets + Budget Actions → 分層警報與執行。

熟記這份參考設計，每一道多帳號成本可視性 SAP-C02 題目都會變成對照這個架構哪一個區塊被考的練習。

並排比較：何時使用哪個工具

關鍵數字與必背事實

• AWS Organizations 集中計費是免費的；RI/SP 共用預設開啟，可在付款人對每個成員切換。
• 標籤政策回報合規性；需加上標籤政策的「防止不合規操作」旗標或 SCP aws:RequestTag 條件才能封鎖建立。
• 成本配置標籤只能在付款人帳號啟用；每個付款人最多 500 個啟用中的使用者定義標籤；資料在約 24 小時內出現在 Cost Explorer/CUR 中。
• AWS Cost Categories 支援從標籤繼承值以及共用費用的費用拆分；值可在 Cost Explorer、Budgets 與 CUR 中看到。
• CUR 至少每天一次交付到你擁有的 S3 儲存桶，每小時顆粒度，CSV 或 Parquet 格式，可自動在 AWS Glue Data Catalog 中註冊 Athena 表格。
• AWS Billing Conductor 按計費群組建立 proforma 帳單；每個帳號最多屬於一個計費群組；proforma 不影響 AWS 對付款人的實際收費。
• AWS Cost Anomaly Detection 是免費的，支援 4 種監控器類型：services、linked account、Cost Category、cost allocation tag。
• AWS Budgets 提供 6 種預算類型加上 Budget Actions，可套用 IAM 政策、SCP 或停止 EC2/RDS；前兩個啟用 Action 的預算免費，之後每個啟用 Action 的預算每天收取 $0.10。
• 組織層級預算從付款人帳號建立；範圍可以是帳號、Cost Categories、標籤、服務。

SAP-C02 常見陷阱 — 快速識別

陷阱一 — 在成員帳號啟用成本配置標籤

成員帳號無法啟用成本配置標籤。啟用是付款人專屬動作。SAP-C02 的干擾選項會建議將啟用權委派給子公司——正確答案是付款人端啟用，或透過帳單服務的 AWS Organizations 委派管理員。

陷阱二 — 標籤政策單獨強制執行標籤

標籤政策預設只驗證並回報；只有針對支援的資源類型設定「防止不合規操作」旗標時，才會封鎖建立。要完整執行，需結合 SCP 的 aws:RequestTag 條件以及 CI/CD 時期的政策檢查。

陷阱三 — 忘記 RI/SP 共用預設開啟

「如何確保新收購的子公司不受益於我們中央 Savings Plans？」是 SAP-C02 的高頻提示。答案是在付款人的帳單偏好設定中對該成員關閉共用，而不是 SCP，也不是 IAM。

陷阱四 — 將 Billing Conductor 用於報告

Billing Conductor 用於重新定價與proforma 開票。如果題目只要求依業務單位報告，Cost Categories 更便宜且更簡單。只有下游需要看到客製價格時，Billing Conductor 才是答案。

陷阱五 — Cost Anomaly Detection vs AWS Budgets

Cost Anomaly Detection 學習基準並對偏差發出警報；AWS Budgets 對你定義的門檻發出警報。兩者都需要——不要在情境期待另一個的時候選其中一個。「意外激增」→ Anomaly Detection。「支出超過預測 $10,000」→ Budgets。

陷阱六 — CUR vs Cost Explorer 用於客製 join

如果情境提到 Athena、QuickSight、與外部資料 join 或每小時明細，答案是 CUR。Cost Explorer 無法做客製 join。

陷阱七 — 全局停用承諾共用犯下錯誤

僅因為一家問題子公司而全組織停用共用，會破壞其他十九家的靈活性。正確模式是選擇性地按成員帳號停用，而非全局切換。

陷阱八 — 委派管理員 vs 付款人專屬動作

部分帳單動作（啟用成本配置標籤、切換 RI/SP 共用）可透過帳單服務的 AWS Organizations 委派管理員委派給非付款人的 FinOps 帳號。並非所有動作都可以；SCP 和付款人根層級的動作不行。閱讀情境以判斷是否在委派範圍內。

練習題型模式

1. 「一家擁有 20 家子公司的母公司想以客製內部費率向每家子公司收取 AWS 使用費，並開立帶品牌的發票。」→ AWS Billing Conductor（每家子公司一個計費群組，每個計費群組一份定價計畫，proforma CUR）。
2. 「FinOps 團隊想建立一個跨組織的 QuickSight 儀表板，將 AWS 費用與內部 CMDB 資料合併。」→ CUR + S3 + Athena + QuickSight，搭配跨帳號讀取的儲存桶政策。
3. 「新收購的子公司不應受益於付款人購買的 Savings Plans。」→ 在付款人帳單偏好設定中對該成員帳號停用 RI/SP 共用。
4. 「財務想查看依業務單位分組的支出，即使帳號跨越多個團隊。」→ AWS Cost Categories（從標籤繼承或規則型）。
5. 「CTO 想在任何成員帳號出現異常支出激增時收到電子郵件。」→ AWS Cost Anomaly Detection，搭配 linked-account 監控器與 SNS 訂閱者。
6. 「強制每個 EC2 執行個體帶有 CostCenter 標籤。」→ 帶有 aws:RequestTag/CostCenter 條件的 SCP 加上標籤政策。
7. 「財務想查看共用日誌費用按業務單位的比例分攤。」→ 帶有費用拆分規則的 Cost Category。
8. 「當特定 OU 達到月度預算的 150% 時自動停止 EC2 執行個體。」→ 在付款人帳號設定的 AWS Budgets 搭配 Budget Actions。
9. 「將帳單管理委派給專屬 FinOps 帳號，讓 FinOps 無需付款人 root 即可運作。」→ 帳單服務的 AWS Organizations 委派管理員。
10. 「啟用使用者定義標籤，使其出現在 Cost Explorer 中。」→ 付款人帳號帳單偏好設定 → 成本配置標籤。

FAQ — 多帳號成本可視性常見問題

Q1：在 50 個帳號的 AWS 組織中，我應該在哪裡啟用成本配置標籤，讓它出現在 Cost Explorer 和 CUR 中？

成本配置標籤啟用是付款人（管理）帳號的動作，在 AWS Billing → Billing preferences → Cost allocation tags 中執行。成員帳號和 OU 層級委派都無法自行啟用標籤。如果你不想與 FinOps 團隊共用付款人的根憑證，請使用帳單服務的 AWS Organizations 委派管理員，將帳單管理（包括標籤啟用）委派給專屬的分析或 FinOps 帳號。啟用在約 24 小時內生效，且是向前看的——啟用前的歷史明細不會重新標記。

Q2：我們在付款人帳號購買了 $1M 的 Compute Savings Plans。如何阻止某家特定子公司默默受益？

前往付款人帳號 → AWS Billing → Billing preferences → Receive AWS Organizations Savings Plans and Reserved Instance discount sharing。將共用對該特定成員帳號切換為關閉。變更在下一個帳單週期生效；此後該帳號的相符用量將按 On-Demand 費率計費（除非該帳號擁有自己的 Savings Plans 或 Reserved Instances）。組織其餘部分繼續共用中央承諾。這是按成員切換——不要只因為一家問題子公司而在組織層級停用共用，否則你將失去所有地方的靈活性。SCP 和 IAM 政策無法達到這個效果，因為承諾共用是帳單層設定，而非權限。

Q3：何時該用 AWS Billing Conductor 而非 AWS Cost Categories？

當你只需要查看依業務單位、專案或環境分組的費用時，使用 AWS Cost Categories——Cost Categories 免費、在使用層零設定，且其值出現在 Cost Explorer、Budgets 和 CUR 中。當你需要重新定價費用用於下游會計時，使用 AWS Billing Conductor——例如以加價向子公司收費的母公司、向外部客戶轉售 AWS 的受管服務提供商，或在基礎設施費用上疊加固定費用的內部平台團隊。Billing Conductor 產生下游實體看到的獨立 proforma 視圖；AWS 仍向付款人收取真實費率。如果情境提到「客製定價」、「加價」、「計費回沖發票」或「proforma」，答案是 Billing Conductor；如果只提到「查看依 BU 分組的支出」，答案是 Cost Categories。

Q4：我們想要一個 Cost Explorer 無法產生的儀表板——將 AWS 費用與內部 CMDB 和客戶資料合併。正確架構是什麼？

在付款人帳號設定 AWS Cost and Usage Report (CUR)，Parquet 格式、每小時顆粒度、包含資源 ID，並啟用 AWS Glue Data Catalog / Athena 整合。將 CUR 交付到付款人（或委派帳單）帳號中的 Amazon S3 儲存桶。透過儲存桶政策將跨帳號讀取權限授予分析帳號的 IAM 角色。執行 Amazon Athena 查詢，將 CUR 表格與你的 CMDB 和客戶表格（可存放在相同或其他 S3 資料湖）join 起來。以 Amazon QuickSight 或你選擇的 BI 工具呈現結果。這繞過了 Cost Explorer 受管儀表板的限制，同時使用 AWS 原生的按查詢付費定價且無需伺服器。搭配 Cost Categories 與成本配置標籤，讓你的查詢 SQL 保持簡單穩定。

Q5：如何確保整個組織的每個資源都帶有 CostCenter 和 Project 標籤？

強制執行是三層模式。首先，以附加到組織根的 AWS Organizations 標籤政策定義綱要，指定必要的鍵、大小寫和允許值。其次，為每個支援的資源類型啟用標籤政策的**「防止不合規操作」旗標**，並在每個 OU 附加 SCP，拒絕在 aws:RequestTag/CostCenter 或 aws:RequestTag/Project 缺失或不在允許清單中時執行資源建立 API 呼叫（ec2:RunInstances、s3:CreateBucket、lambda:CreateFunction 等）。第三，在 CI/CD 中對相同綱要執行部署前檢查（cfn-lint、tflint、Checkov），讓不合規的基礎設施在抵達 AWS 之前就被攔截。第四層用於清理：使用 AWS Config 規則（required-tags）標記任何漏網的舊資源。標籤政策是必要但不充分的；SCP 才是真正的關卡。

Q6：新建立的 10 個帳號 AWS 組織，成本可視性的最低服務集合是什麼？

第一天起，在付款人帳號至少啟用這些：(1) 啟用所有功能並啟動集中計費的 AWS Organizations；(2) 在帳單偏好設定中啟用 AWS Cost Explorer；(3) AWS Cost and Usage Report 交付到付款人帳號中的 Amazon S3 儲存桶，並啟用 Athena 整合（即使你現在不建儀表板，日後也會慶幸有歷史資料）；(4) 啟用三四個成本配置標籤（CostCenter、Project、Environment、Owner）並在根附加標籤政策；(5) AWS Cost Anomaly Detection，至少有一個 AWS services 監控器和每個生產帳號一個 linked-account 監控器；(6) 一個組織層級費用預算，設在預測的 110%，附帶 SNS 警報。隨著組織成長與計費回沖需求成熟，再加入 Cost Categories、Billing Conductor 與 Budget Actions。這個最低集合以零或接近零的增量成本，提供了歸因、歷史原始資料、基準警報與預測型治理。

Q7：我們能將費用管理行政委派給 FinOps 帳號，讓 FinOps 無需付款人根憑證就能行動嗎？

可以。使用帳單服務的 AWS Organizations 委派管理員。從付款人（管理）帳號，將選定的成員帳號（通常是專屬的 FinOps 或分析帳號）登記為 billing.amazonaws.com 的委派管理員。委派管理員帳號即可管理成本配置標籤、在組織層級建立和管理 AWS Budgets、讀取 AWS Cost and Usage Report、建立和管理 Cost Categories，以及在整個組織中操作 AWS Cost Anomaly Detection——無需任何時候使用付款人的根憑證。部分動作仍為付款人專屬（尤其是 RI/SP 共用切換和付款方式更新），因此將常見日常操作委派出去，並讓付款人嚴格鎖定用於特殊變更。這個模式符合 SAP-C02 對最小權限、職責分離設計的偏好。

延伸閱讀

• AWS Organizations Consolidated Billing: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_consolidated-billing.html
• Turning off RI/SP Discount Sharing: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html
• AWS Organizations Tag Policies: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html
• Activating User-Defined Cost Allocation Tags: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html
• AWS Cost Categories: https://docs.aws.amazon.com/cost-management/latest/userguide/manage-cost-categories.html
• AWS Cost and Usage Reports: https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html
• Querying CUR with Amazon Athena: https://docs.aws.amazon.com/cur/latest/userguide/cur-query-athena.html
• AWS Billing Conductor: https://docs.aws.amazon.com/billingconductor/latest/userguide/what-is-billingconductor.html
• AWS Cost Anomaly Detection: https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
• AWS Budgets for Organizations: https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html#create-budget-org
• SAP-C02 Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-sap-pro/AWS-Certified-Solutions-Architect-Professional_Exam-Guide.pdf

相關主題

• 多帳號治理 — AWS Organizations 結構、OU 設計、委派管理，以及與成本可視性並存的治理堆疊。
• Organizations SCP 設計 — 在資源建立時強制執行成本配置標籤的 SCP 模式。
• Landing Zone 與 AWS Control Tower — 在成熟的多帳號設定中預先連接集中計費、標籤政策與 CUR 的主觀式 landing zone。
• Savings Plans 與 RI 策略 — 承諾採購策略、覆蓋率目標，以及回饋到多帳號成本可視性儀表板的使用率目標。

在這個深度掌握多帳號成本可視性，你就覆蓋了 SAP-C02 帳單與最佳化考點約四分之一的面積——同時也為每個真實世界 AWS 組織最終都需要的 FinOps 骨幹打好了基礎。