成本可視性、Budgets 與資源 Rightsizing

成本可視化與 rightsizing 是一門運維紀律：看清楚每一分雲端費用流向何處，再根據資料採取行動。在 SOA-C02 中，Domain 6 Task Statement 6.1 佔全卷 12%。SAA-C03 幾乎不考成本最佳化（頂多在架構選型層面考 Reserved vs Savings Plans），SOA-C02 則明確測試日常操作成本工具的能力：在 Cost Explorer 中篩選出讓月帳單爆掉的那個團隊、設定 AWS Budgets 搭配自動動作在下個帳單週期之前停止失控的開發帳號、解讀 Compute Optimizer 的 ML 風險等級以決定是否安全套用 rightsizing 建議，以及讀懂 Trusted Advisor 的成本最佳化檢查，清理閒置 EC2、使用率偏低的 EBS volumes、無對應實例的 Elastic IPs，以及閒置的 RDS 資料庫。

本指南從 SysOps 視角走過成本可視化與 rightsizing 全流程：成本分配標籤如何啟用（以及為何會延遲一天）、Cost Explorer 篩選如何找出費用高峰、Budgets 與 Budget Actions 如何自動補救、Compute Optimizer 的 14 天基準視窗如何為 EC2／ASG／Lambda／EBS 產生含風險等級的建議、哪些 Trusted Advisor 檢查需要 Business 或 Enterprise 支援方案、如何評估工作負載是否適合 Spot Instance 並處理 2 分鐘中斷警告、何時選用受管服務以降低成本，以及 AWS Cost and Usage Report（CUR）如何流入 S3 與 Athena 進行任意粒度分析。你也會看到反覆出現的 SOA-C02 成本可視化場景：月帳單暴增 30%——找出元兇；Compute Optimizer 說 EC2 過度配置——有信心地套用建議；團隊即將超過預算——Budget Action 觸發 SCP。

為什麼成本可視化是 SOA-C02 Domain 6 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 6.1 下列出五項技能：實作成本分配標籤；使用 Trusted Advisor、AWS Compute Optimizer 和 AWS Cost Explorer 識別並補救使用率偏低或閒置的資源；設定 AWS Budgets 與 billing alarms；評估資源使用模式以判斷工作負載是否適合 EC2 Spot Instances；以及識別使用受管服務（如 Amazon RDS、AWS Fargate、Amazon EFS）的機會。這五項技能都直接對應到成本可視化與 rightsizing 中的一個運維工具——沒有任何一項是 SAA 風格的架構設計題。考試想確認的是：你能不能操作成本工具，並根據工具的輸出採取行動。

在 SysOps 層級，問題框架是運維而非架構設計。SAA-C03 問「這個穩定負載選哪種購買模型最省錢？」（RI vs SP 數學）；SOA-C02 問「SysOps 團隊發現上個月帳單暴增 30%——在 Cost Explorer 中逐步找出原因並補救。」答案是一連串運維動作：依服務篩選找出高峰，再依 usage type 識別是 NAT gateway 的資料處理費，然後新增 S3 VPC gateway endpoint，讓 S3 流量不再繞過 NAT 計費。成本可視化與 rightsizing 是所有 Domain 6 省下的錢被衡量的地方——Compute Optimizer 建議只有在你去讀它時才有用，Budget Actions 只有在你設定時才會觸發，Spot 適用性評估只有在你依結果行動時才重要。

白話文解釋 Cost Visibility, Budgets, and Rightsizing

成本可視化的術語很密集，Cost Explorer、Budgets、Compute Optimizer 與 Trusted Advisor 之間的界線很快就會模糊。三個類比能把這些概念固定在正確位置。

類比一：夜市攤位的月結帳審計

把 AWS 的成本可視化想成一個夜市攤主每月盤點開銷的流程。Cost Explorer 是攤主的收支帳本軟體，登入後就能看到「7 月共花了 14 萬，依品項分類：食材 30%、租金 45%、瓦斯水電 15%、雜支 10%」。成本分配標籤是貼在每個進貨箱上的標籤，把珍珠奶茶食材、臭豆腐食材、滷味食材分開記帳，而不是全部算成「食材費」。AWS Budgets 是攤主在帳本 app 裡設定的每月上限——「若 7 月支出預測超過 16 萬，在達到 80% 和 100% 時傳簡訊通知我」。Budget Actions 是當上限被觸及時，收銀系統自動鎖住某個供應商的採購權限——真正的自動補救，不只是通知而已。Compute Optimizer 是帳本 app 的用電顧問，看了你最近兩週的耗電紀錄後說「你的冷凍庫效能衰退了，換一台新型號每月可省 1,200 元，風險很低」。Trusted Advisor 是每月由老師傅來做的設備盤點清單——「你有一盞霓虹燈整夜亮著卻沒顧客（閒置 EC2）、倉庫裡有個大冰箱只裝了 10% 的食材（使用率偏低的 EBS）、有個插頭沒插任何東西卻還在計電費（無對應實例的 Elastic IP）」。Spot Instances 是離峰時段的超低電價——你可以在凌晨用 90% 折扣跑大功率設備，但電力公司在用電高峰時可能切斷你 2 分鐘（中斷警告），所以別在這段時間做不能中斷的精密烹調。

類比二：健身手環的使用量統計

Compute Optimizer 是你 EC2 機群的健身手環。戴了 14 天之後，手環有足夠的資料說「你平日上班時段的平均心跳是 72 下——那台 m5.2xlarge 是為跑馬拉松的人準備的，你應該降級到 m5.large」。風險等級是手環的信心評分——「低風險：我們非常確定你可以降兩個規格」vs「中風險：偶爾有尖峰，較小的規格可能應付不來，請先驗證」vs「高風險：未經測試不要變更」。14 天基準視窗是手環需要配戴兩週才能顯示建議的等待期——剛啟動的實例以及 metrics 稀疏的實例，都不會出現在建議清單中。每條建議都附有預估月節省金額和預估效能風險，就像手環同時顯示預估消耗卡路里和心跳資料。SOA-C02 考生若把風險等級當成可忽略的裝飾，遲早會在套用建議後，凌晨兩點被 on-call 叫起來，然後學到教訓。

類比三：連鎖餐廳的週期食材耗損稽核

Trusted Advisor 的 cost optimization 檢查是連鎖餐廳總管每週的食材耗損稽核。每週一早上，總管走一圈廚房，找出：快過期卻沒用到的食材（閒置 EC2——付了機器費卻沒產生價值）、過大的湯鍋每班只裝 10%（使用率偏低的 EBS volumes——配置了 1TB 卻只用了 50GB）、印在每張菜單上卻從未有人點的孤兒菜色（無對應實例的 Elastic IPs——每小時 0.005 USD 卻毫無用途）、以及運轉中但這週菜單完全用不到的冷凍庫（閒置 RDS 資料庫）。稽核產生一份清單，附有預估月節省金額和依金額影響排列的優先順序。但有個前提：完整稽核只對加入Business 或 Enterprise 加盟方案的餐廳開放——基本方案只能看到精簡版的週摘要（即 Trusted Advisor 的支援方案限制：免費方案只有六個核心檢查，Business 與 Enterprise 才有完整的 100+ 項）。

成本分配標籤：啟用、延遲與費用分攤

成本分配標籤是 AWS 中所有依團隊或依專案檢視費用的基礎。若未啟用標籤，Cost Explorer 的分組粒度就只能到服務與帳號層級。標籤分兩種：

AWS 自動產生的標籤

Billing console 公開一小組AWS 自動產生的標籤，由 AWS 自行填入——最常見的是 aws:createdBy（誰建立了這個資源）以及少數服務特定標籤。啟用方式：在 Billing console → Cost Allocation Tags → AWS-generated cost allocation tags 點選一次即可。

使用者自訂標籤

這些是你套用在資源上的標籤（Project=billing-svc、CostCenter=marketing、Environment=prod）。將標籤套用到資源後，還必須前往 Billing console → Cost Allocation Tags → User-defined cost allocation tags，找到標籤的 key，並點擊Activate。在啟用之前，該標籤對 Cost Explorer、AWS Budgets 和 CUR 完全不可見。

24 小時啟用延遲（最常被考的陷阱）

啟用後，標籤不會立即出現在 Cost Explorer 中。AWS Billing 需要最多 24 小時才能將標籤維度回填至成本資料。SOA-C02 經常測試這個場景：「SysOps 工程師在早上 9 點啟用了 CostCenter 標籤——10 點時，team lead 抱怨 Cost Explorer 裡看不到這個標籤，該怎麼辦？」考試正確答案是「等最多 24 小時——啟用是非同步的」，不是「重新貼標籤資源」或「建立新標籤」。

第二個細節：標籤啟用是向前生效的。標籤從啟用時刻起才成為 Cost Explorer 的維度；啟用之前的歷史費用不會被追溯重新標記。若要讓費用分攤正常運作，應在帳號開通的 runbook 中就啟用成本分配標籤，在資源建立之前完成。

多帳號環境中的成本分配標籤

在 AWS Organizations 架構下，成本分配標籤的啟用動作發生在管理帳號的 Billing console，並適用於每個成員帳號的合併帳單。成員帳號無法自行為合併帳單啟用成本分配標籤——這個決定由管理帳號掌控。這對於 SOA-C02 多帳號環境下的費用分攤題目非常重要。

AWS Cost Explorer：依服務、標籤、帳號與 Usage Type 篩選

AWS Cost Explorer 是運維團隊了解錢花到哪裡的主要主控台。它支援歷史分析（最多 12 個月的過去資料）與預測（最多 12 個月的未來趨勢）。

分組維度

Cost Explorer 可以依以下維度對費用（或使用量）分組：

• Service — EC2-Instance、RDS、S3、CloudFront、NAT Gateway。任何費用高峰調查的第一刀。
• Linked Account — 在 Organizations 環境中，依成員帳號拆分費用。
• Tag — 一旦成本分配標籤啟用，即可依 Project、CostCenter、Environment 分組。
• Usage Type — 在某個服務內，區分各明細項目（USE2-EBS:VolumeUsage.gp3 vs USE2-EBS:VolumeUsage.io2 vs USE2-DataTransfer-Out-Bytes）。找出 NAT gateway 資料處理費或跨 AZ 資料傳輸高峰的關鍵。
• Region、Availability Zone、Operation、API Operation — 更細粒度的切割。

篩選維度

與分組維度相同，另加購買類型（On-Demand、Reserved、Savings Plan、Spot、Credit）及資源標籤。篩選與分組的組合，是 SysOps 工程師從「帳單暴增 30%」鑽取到「us-west-2 的 Project=video-encoding 標籤看到 NAT Gateway 資料處理費用暴增 8 倍」的方式。

每日、每月與每小時粒度

Cost Explorer 預設顯示過去 14 天的每日粒度，以及更舊資料的每月粒度。每小時粒度與資源層級粒度是付費功能，必須在 Billing 偏好設定中明確啟用，並按每 1000 筆明細項目計費。SOA-C02 可能問「SysOps 團隊需要某次 24 小時事故的每小時成本明細」——答案是在 Cost Explorer 啟用每小時粒度（並接受小額費用），或直接拉取 CUR（CUR 永遠有每小時的資源層級資料）。

預測

Cost Explorer 的預測模型使用歷史模式，以 80% 信賴區間推算月底支出。這個預測就是 AWS Budgets 內部用來發出「預測將超支」告警的依據。

標準調查流程

每一道「月帳單暴增」的題目，在 Cost Explorer 中都遵循以下流程：

1. 查看月度總費用 — 確認是否有高峰。
2. 依 Service 分組 — 識別哪個服務增長。
3. 在該服務內依 Usage Type 分組 — 識別具體明細（資料處理、IOPS、實例小時數）。
4. 篩選至高峰 usage type，依 Linked Account 或 Tag 分組 — 識別負責的團隊或專案。
5. 依 Region 與 AZ 分組 — 判斷高峰是廣泛的還是局部的。
6. 補救 — S3 VPC gateway endpoint、實例類型 rightsizing、閒置資源清理等。

Cost Explorer 中的 Rightsizing 建議

Cost Explorer 本身也會依據 CloudWatch metrics，為 EC2 實例產生 rightsizing recommendations。入口在 Cost Explorer → Rightsizing Recommendations。

分析內容

Cost Explorer 的 rightsizing 引擎查看帳號（或組織）中每個 EC2 實例過去 14 天的 CPU 使用率、網路 I/O 和磁碟 I/O。持續顯示低使用率的實例會被標記為兩種建議類型：

• Terminate — 實例在 14 天視窗中使用率接近零。可能是閒置的開發機、被遺忘的測試實例，或已結束的專案。
• Modify（縮小規格） — 實例使用率低但非零。Cost Explorer 建議在相同 family 內換用更小的實例類型（例如 m5.4xlarge → m5.2xlarge），並顯示預估月節省金額。

跨 family vs 同 family 建議

Cost Explorer 預設在相同 family 內建議。你可以在偏好設定中啟用跨 family rightsizing，以查看如 m5.2xlarge → m6i.xlarge（更新世代，可能不同 family）的建議。跨 family 建議風險略高，因為底層 CPU 架構與基準測試可能有所不同。

Cost Explorer Rightsizing vs Compute Optimizer 的重疊

Cost Explorer 的 rightsizing 是較簡單的基準視圖。Compute Optimizer 是更深層、ML 驅動的引擎，涵蓋 EC2、ASG、Lambda 和 EBS——不只有獨立 EC2——並且提供更細緻的風險分類。SOA-C02 有時會測試兩者的邊界：題目問「跨 EC2、Auto Scaling groups、Lambda 和 EBS 的 ML 驅動建議」對應 Compute Optimizer；題目問「在 Cost Explorer 主控台中快速查看 EC2 的 rightsizing 清單」對應 Cost Explorer rightsizing。兩者互補；Compute Optimizer 是範圍更廣、更細緻的工具。

AWS Compute Optimizer：EC2、ASG、Lambda 與 EBS 的 ML 建議

AWS Compute Optimizer 是 SOA-C02 考試中最核心的 rightsizing 工具。它以帳號或組織為單位選擇加入（opt-in），建議本身免費（你需要為底層的 CloudWatch metrics 和 agent 付費），涵蓋四種資源類型。

EC2 實例建議

Compute Optimizer 吸收每個 EC2 實例14 天的 CloudWatch metrics（CPU、網路 I/O、磁碟 I/O，以及——若已安裝 CloudWatch agent——記憶體），並輸出以下其中一種結果：

• Under-provisioned — 實例過小，接近飽和狀態。建議升級。
• Over-provisioned — 實例過大，有大量餘裕。建議縮小規格，附目標實例類型與預估節省金額。
• Optimized — 實例在 Compute Optimizer 的容忍範圍內配置正確，無需操作。
• None — Compute Optimizer 無法產生建議（metrics 不足、實例運行未滿 14 天，或不支援的實例類型）。

14 天基準視窗

Compute Optimizer 需要14 天的滾動基準才能產生建議。剛啟動的實例在 14 天的 metrics 累積完成之前不會出現在建議清單中。考試持續測試這個數字——當題目說「Compute Optimizer 對剛啟動的實例沒有顯示建議，SysOps 工程師的下一步是什麼？」，答案是「等待 14 天讓基準建立完成」。

風險等級

每條建議都帶有從 Very Low 到 Very High 的效能風險評分。評分反映 Compute Optimizer 對建議實例類型能否應付工作負載觀測到的高峰的信心程度。Very Low 和 Low 風險的建議通常可以直接套用；Medium 風險需要在非生產環境驗證；High 和 Very High 風險的建議只應在明確進行負載測試後才套用。

記憶體 metrics 對 CloudWatch agent 的依賴

若缺少記憶體 metrics，Compute Optimizer 的建議僅基於 CPU、網路和磁碟 I/O。記憶體使用率只能來自CloudWatch agent，將資料發布至 CWAgent namespace。希望獲得高信心建議的 SysOps 團隊應確保 agent 部署至整個機群——否則 Compute Optimizer 可能建議縮小至記憶體不足的實例。

EC2 Auto Scaling group 建議

對於 ASG，Compute Optimizer 評估launch template / launch configuration 的實例類型，並依據整個群組的聚合負載輪廓給出建議實例類型。建議會考量 scaling 行為：若 ASG 在負載下積極向外擴展，可能不需要更大的每實例類型，讓 scaling policy 完成工作即可。

AWS Lambda function 建議

Compute Optimizer 分析 function 的記憶體設定（也決定了 Lambda 的 CPU 配置）和執行時間歷史，給出如「目前 1024 MB → 建議 768 MB」的建議及預估月節省金額——有時違反直覺，因為給 Lambda function 更多記憶體可以縮短執行時間，使每毫秒費用實際降低。

Amazon EBS volume 建議

對於 EBS，Compute Optimizer 查看 IOPS、吞吐量和 burst-balance 趨勢，並建議：

• Volume 類型變更 — gp2 → gp3，以相同或更好的效能降低成本。
• 大小與 IOPS 調整 — 從未使用到的 provisioned IOPS 可以縮減。

啟用 Compute Optimizer

單一帳號：前往 Compute Optimizer 主控台並 opt-in。組織範圍：在管理帳號啟用或指定委派管理員帳號，受信任存取會將建議傳播至所有成員帳號。對於已有 14 天以上 metrics 的資源，opt-in 後 12–48 小時開始出現建議。

AWS Budgets：成本、使用量與 Reservation 使用率預算

AWS Budgets 是針對月度、季度或年度支出定義目標後的告警與動作引擎。每個帳號前 2 個預算免費建立；額外的預算收取小額的每預算每日費用。

預算類型

• Cost budget — 每月／季度／年度的金額閾值。最常見的 SysOps 預算。
• Usage budget — 每個服務的使用量閾值（例如 1 TB S3 儲存、100,000 次 Lambda 呼叫）。
• Savings Plans utilization budget — 當 SP 使用率低於目標時告警（你承諾每小時花 $X，但只用了 80%——你正在浪費承諾）。
• Savings Plans coverage budget — 當 SP 對總計算支出的涵蓋率低於目標百分比時告警。
• RI utilization budget — 當 Reserved Instance 使用率低於目標時告警（你有 RI 但對應的實例沒有運行）。
• RI coverage budget — 當 RI 對符合資格支出的涵蓋率低於目標時告警。

閾值類型

• Actual — 當實際支出達到閾值時告警（例如預算金額的 80% 或 100%）。
• Forecasted — 當 Cost Explorer 的預測模型預測期末支出將超過閾值時告警。讓你在突破之前就能行動。

通知目標

• Email 地址（最多 10 個）。
• SNS topic ARN — 用於聊天整合、工單系統、自動補救 pipeline。
• AWS Chatbot 用於 Slack / Microsoft Teams。

常見的 SysOps 預算模式

• 依 CostCenter 標籤篩選的每團隊月度 cost budget — 預測達到 80% 告警、實際達到 100% 告警。
• 管理帳號中的帳號層級月度 cost budget — 整個組織的防護欄。
• 特定服務的 usage budget — 例如「若 NAT Gateway 資料處理量本月超過 1 TB 則告警」（捕捉典型的 NAT gateway 洩漏）。
• SP utilization budget 設在 95% — 當承諾浪費超過 5% 時發出通知。

Budget Actions：閾值突破時的自動補救

AWS Budget Actions 將被動告警轉化為自動補救措施。當預算閾值被突破時，Budget Action 執行以下三種具體步驟之一。

三種 Budget Action 類型

• 套用拒絕 SCP — 在 AWS Organizations 層級，將一個 service control policy 附加到受影響的帳號或 OU，拒絕指定的動作集合（例如 ec2:RunInstances、rds:CreateDBInstance）。這是針對成本超支的組織層級防護欄。
• 套用 IAM 拒絕 policy — 將受管拒絕 policy 附加至指定的 IAM 使用者、群組或角色。阻止該身份執行昂貴的 API 呼叫，直到 policy 被移除為止。
• 停止 EC2 或 RDS 實例 — 最直接的補救。動作以特定實例（依 ID）或所有符合標籤篩選條件的實例為目標，在閾值突破時停止它們。

核准模式

• Automatic — 動作在閾值突破的瞬間自動執行，無需人工核准。適用於允許自我施加上限的非生產預算。
• Manual approval required — Budgets 傳送含連結的通知；指定的核准者必須點擊才能執行。適用於自動關機風險過高的生產環境。

IAM 角色要求

Budget Actions 需要一個 IAM 角色，由 Budgets 扮演後執行動作。角色的信任 policy 必須允許 budgets.amazonaws.com 扮演它，且其權限 policy 必須授予相關動作（SCP 附加需要 organizations:AttachPolicy、IAM 附加需要 iam:AttachUserPolicy、停止實例需要 ec2:StopInstances 和 rds:StopDBInstance）。缺少或範圍錯誤的角色會導致 Budget Actions 靜默失敗——動作在 Budgets 主控台中顯示為「execution failed」，但補救從未發生。

重置行為

Budget Actions 是每次預算閾值突破的一次性動作。一旦預算週期結束並重置，動作就會被清除。但套用的 SCP、IAM policy，或已停止的實例狀態仍然保留，直到有人手動還原——這是刻意設計的，讓補救措施能跨週期持續，除非有人明確移除。

Trusted Advisor 成本最佳化檢查

AWS Trusted Advisor 是多類別的檢查引擎。Cost Optimization 類別是清理工作中高效益最高的 SysOps 工具。

重點成本檢查項目

• Low Utilization Amazon EC2 Instances — 過去 14 天每日 CPU 和網路 I/O 都很低的實例。終止或縮小規格的候選。
• Idle Load Balancers — 沒有關聯目標或請求量極低的 load balancers。刪除的候選。
• Underutilized Amazon EBS Volumes — 過去 7 天 IOPS 極低的 EBS volumes。快照後刪除或縮小的候選。
• Unassociated Elastic IP Addresses — 未附加到任何運行中實例的 Elastic IPs。每個未關聯的 EIP 每小時收費約 0.005 USD，在大量 EIP 的情況下費用相當可觀。
• Idle Amazon RDS DB Instances — 過去 7 天沒有連線且 CPU 極低的 RDS 實例。快照後刪除的候選。
• Amazon RDS Idle DB Instances — 類似；專門捕捉已配置後被遺忘的非生產 RDS。
• Underutilized Redshift Clusters — 查詢量低的叢集。
• Savings Plans / Reserved Instance 建議 — 與帳單資料交叉比對，建議購買承諾型方案。

支援方案限制

Trusted Advisor 的完整檢查集需要 Business、Enterprise 或 Enterprise On-Ramp 支援方案。免費的 Basic 和 Developer 支援方案只能看到六個核心檢查（主要是 Security 和 Service Limits），而非完整的 Cost Optimization 類別。SOA-C02 直接測試這點：「SysOps 團隊想啟用完整的 Trusted Advisor 成本檢查——需要什麼條件？」答案是「至少升級到 Business Support」。

Trusted Advisor 與 EventBridge 整合

Trusted Advisor 將檢查狀態變更以 Trusted Advisor Check Item Refresh Notification 事件發布到 EventBridge。SysOps 團隊可以建立 EventBridge 規則，比對 category=cost_optimizing 並路由至 SNS 或 Lambda 進行工單自動化。這是「團隊希望在 Trusted Advisor 出現新的閒置 EC2 實例的瞬間就被通知」的運維模式。

刷新頻率

大多數 Trusted Advisor 檢查每 24 小時自動刷新一次。也可以在主控台手動刷新。程式化存取方面，AWS Support API 公開了 Trusted Advisor 檢查（同樣需要 Business+ 支援方案）。

Spot Instance 適用性評估與中斷處理

EC2 Spot Instances 提供最高約 90% 的 On-Demand 折扣，代價是中斷風險——當 On-Demand 需求上升時，AWS 可在給予 2 分鐘警告後收回 Spot 容量。SOA-C02 Task Statement 6.1 明確測試評估工作負載是否適合 Spot。

適合 Spot 的工作負載特性

• Stateless（無狀態） — 失去實例不會遺失任何客戶端 session、進行中的請求或未儲存的資料。
• Fault-tolerant（容錯） — 工作負載能容忍實例損失，通常因為工作已被 checkpoint 或排入佇列（SQS、Kinesis、S3-backed batch）。
• 跨實例類型與 AZ 靈活 — 工作負載在 m5、m5a、m6i、c5 等上都能同樣良好運行，讓 Spot 分配器有更多容量池可選擇。
• Time-elastic（時間彈性） — 工作負載能容忍延遲；若目前沒有 Spot 容量，工作可以等待。

典型的 Spot 適用工作負載：批次處理、大數據 ETL、CI/CD 建置 workers、render farms、網頁爬蟲、佇列後面的容錯容器化微服務、有 Mixed Instances Policy 的 ASG 機群。

不適合 Spot 的工作負載特性

• Stateful（有狀態） — 長時間運行的資料庫、有本地狀態的單一實例應用伺服器。
• Hard-deadline（硬性截止時限） — 有嚴格 SLA、無法接受 2 分鐘中斷的工作負載。
• Single-AZ 鎖定 — 無法跨 AZ 運行的工作負載可選擇的容量池較小。

2 分鐘中斷警告

當 AWS 決定收回 Spot Instance 時，會透過兩個管道發出 2 分鐘警告：

• EC2 Instance Metadata Service（IMDS） — metadata 路徑 http://169.254.169.254/latest/meta-data/spot/instance-action 在中斷迫近時回傳含計劃終止時間的 JSON 文件。
• EventBridge EC2 Spot Instance Interruption Warning 事件 — 發布至預設事件匯流排，可路由至 Lambda、SNS 或 Step Functions 進行優雅關機處理。

工作負載應輪詢 IMDS 或訂閱 EventBridge 事件，利用這 2 分鐘：從 load balancer 排空進行中的請求、將狀態 checkpoint 至 S3 或 DynamoDB、從服務登錄中取消登錄，並乾淨地退出。

Spot Fleet vs 有 Mixed Instances Policy 的 EC2 Auto Scaling group

大規模使用 Spot 的兩種 SOA-C02 相關方式：

• 有 Mixed Instances Policy 的 EC2 Auto Scaling group — 現代、推薦的模式。指定相容實例類型清單和目標 Spot 百分比；ASG 負責分配、Capacity Rebalancing 和 Spot 中斷替換。
• EC2 Spot Fleet — 較舊、可設定性更高的機群管理器。仍受支援，但在 SOA-C02 場景中通常被 ASG Mixed Instances Policy 取代。

Capacity Rebalancing

啟用 Capacity Rebalancing 的現代 ASG 會監控 Spot Instance 的中斷風險（在 2 分鐘警告之前發出訊號），並主動在風險較低的容量池中啟動替換 Spot 容量。這降低了 2 分鐘警告同時影響多個實例的機率。

Savings Plans 與 Reserved Instances — SOA-C02 的考點

SOA-C02 不要求像 SAA-C03 有時測試的那種 Savings Plans vs Reserved Instances 深度數學計算。考試希望你對承諾模型有足夠的理解，能夠對 Compute Optimizer 和 Cost Explorer 的建議採取行動。

Reserved Instances（RI）

對特定 instance family、region、OS 和 tenancy 進行 1 年或 3 年承諾，換取最高約 72% 的 On-Demand 折扣。兩種類型：Standard RI（最高折扣，鎖定所選屬性）和 Convertible RI（較低折扣，可在期限內換成不同 family）。付款選項：All Upfront、Partial Upfront、No Upfront。

Savings Plans（SP）

對每小時計算支出金額進行 1 年或 3 年承諾，換取折扣。兩種類型：

• Compute Savings Plans — 廣泛適用於 EC2（任何 family、任何 region、任何 OS）、Fargate 和 Lambda。最大靈活性，最高約 66% 折扣。
• EC2 Instance Savings Plans — 鎖定特定 region 中的特定 instance family；最高約 72% 折扣，與 Standard RI 相當，但承諾是基於金額而非實例。

SOA-C02 關心 SP 和 RI 的時機

考試在三種運維場景中測試這些：

• SP utilization budget — 當 SP 承諾被浪費時通知團隊（使用率 < 95%）。
• SP coverage budget — 當 SP 對符合資格計算支出的涵蓋率低於目標時通知。
• 來自 Cost Explorer 的建議 — Cost Explorer 依據使用歷史推薦 SP／RI 購買；SysOps 工程師的工作是讀取並行動，不需要從頭推算數學。

考試立場

SOA-C02 明確不測試「根據這些使用小時數計算哪種購買模型最便宜」——那是 SAA 的範疇。SOA-C02 測試「根據 Cost Explorer 的建議，哪種 Budgets 類型會在 SP 使用率下降時告警？」答案是 SP utilization budget。

受管服務的成本效益：Fargate vs EC2、RDS vs 自建

SOA-C02 Task Statement 6.1 明確提到「識別使用受管服務的機會（例如 Amazon RDS、AWS Fargate、Amazon EFS）」。這是運維層面的 TCO 比較。

受管服務勝出的情境

• AWS Fargate vs 自建 EC2 容器 — Fargate 消除容量規劃、AMI 修補和主機層級 scaling。Fargate 的每任務定價比 EC2 的每 CPU 小時高，但在中小型規模時，運維節省（無修補週期、無 scaling 調整、無 AMI 生命週期管理）通常更划算。
• Amazon RDS vs EC2 上的自建資料庫 — RDS 處理備份、修補、Multi-AZ 容錯移轉、唯讀副本配置、參數調整。RDS 相對 EC2 的每小時溢價，遠低於以相同可靠性運行自建資料庫所需的人力成本。
• Amazon EFS vs 自建 NFS — EFS 自動擴展儲存和吞吐量，並在多個 AZ 之間複製。自建 NFS on EC2 需要檔案伺服器配置、複製和容量管理。
• AWS Backup vs 自建快照腳本 — 集中化的備份計劃、保存庫、生命週期、跨 region 複製和合規報告。
• AWS Lambda vs EC2 上的自建 cron — Lambda 按毫秒計費；EC2 上的 cron 需要主機持續運行。

SOA-C02 的 TCO 框架

考試希望你認識到受管服務的成本不只是 AWS 的定價——而是定價減去省下的工程工時。重視自身時間的 SysOps 團隊，對任何非差異化的層（資料庫、load balancer、憑證、DNS、備份）都會偏好受管服務。只有在工作負載確實需要受管服務不提供的控制權時（例如 RDS 不支援的資料庫引擎，或 Fargate 不運行的 Linux 發行版），才會選擇自建。

AWS Cost and Usage Report（CUR）+ Athena 分析

對於超出 Cost Explorer 預建維度範圍的 SysOps 成本分析，**AWS Cost and Usage Report（CUR）**以原始檔案形式在 S3 中提供每個資源、每小時的明細。

CUR 交付

• 預設為每小時粒度；也提供每日和每月彙總。
• CSV 或 Apache Parquet 格式；Parquet 是 Athena 效率的首選。
• 交付至指定路徑的 S3 bucket；AWS 在每個交付週期寫入一個 manifest JSON。
• 月中多次更新 — AWS 在帳單確定時重寫 CSV／Parquet 檔案；月份的最終報告在月底後約 24 小時提供。

Schema 重點

CUR schema 有 100+ 個欄位，涵蓋身份（帳號、region）、產品（服務、實例類型、AZ）、定價（rate code、On-Demand 成本、混合成本、未混合成本、攤銷成本）、reservation（RI ARN、RI 使用率）和 Savings Plans（SP ARN、SP 有效成本）。每個已啟用的成本分配標籤都會出現為自訂欄位。

使用 Amazon Athena 查詢 CUR

標準模式：

1. 在 CUR 設定中選擇 Parquet 格式並啟用 Athena 整合。
2. AWS 自動建立一個 AWS Glue crawler 以及指向 S3 prefix 的 Athena 資料庫／資料表。
3. 在 Athena 中執行 SQL：SELECT product_servicecode, SUM(line_item_unblended_cost) FROM cur_table WHERE line_item_usage_start_date BETWEEN ... GROUP BY product_servicecode ORDER BY 2 DESC。

何時使用 CUR 而非 Cost Explorer

• Cost Explorer 用於臨時調查、儀表板和內建維度。主控台驅動。
• CUR + Athena 用於：程式化報告、自訂費用分攤腳本、多月趨勢分析、財務團隊整合，以及任何 Cost Explorer UI 原生不支援的切割方式。
• CUR + QuickSight 用於在 CUR 之上建置含視覺化的高管儀表板。

場景模式：月帳單暴增 30%——找出元兇

這是 SOA-C02 成本可視化的標準場景。操作流程：

1. 開啟 Cost Explorer。 設定日期範圍為「Last 6 Months」、粒度為「Monthly」。確認高峰——是月與月之間，還是逐漸爬升？
2. 依 Service 分組。 識別哪個服務增長。常見元兇：EC2-Other（NAT Gateway、EBS、資料傳輸）、CloudWatch（高基數自訂 metrics 或 Logs 攝入）、S3（儲存增長或跨 region 複製）、RDS（實例數量或儲存擴展）。
3. 篩選至該服務，依 Usage Type 分組。 在這裡可以看到 NAT Gateway 資料處理費 vs NAT Gateway 小時費、S3 PUT/GET vs 儲存費、RDS 儲存 vs 實例小時費。
4. 篩選至高峰 usage type，依 Linked Account 或 Tag 分組。 識別哪個帳號或團隊負責。若成本分配標籤未啟用，這個步驟就會失敗——這就是為什麼任何成本紀律的第 0 步都是啟用標籤。
5. 依 Region 和 AZ 分組。 集中在某個 region 的高峰通常指向工作負載遷移；跨 AZ 流量高峰指向架構問題。
6. 識別並套用補救措施。 常見模式：NAT Gateway 資料處理高峰 → 新增 S3／DynamoDB VPC gateway endpoint 繞過 NAT 給這些服務；跨 AZ 資料傳輸高峰 → 將喜歡聊天的工作負載層次集中在同一個 AZ；過大的 RDS → 快照、縮小規格、還原；閒置 EC2 → 依 Trusted Advisor 或 Compute Optimizer 建議終止。
7. 對受影響維度設定 Budget。 在新正常值的 80% 預測值設定告警，讓未來的退步能及早被捕捉。

SOA-C02 考試偏好的措辭傾向強調「使用 Cost Explorer 從 Service 鑽取至 Usage Type 再到 Tag」——多步驟逐層鑽取，而非直接跳到 CUR。

場景模式：Compute Optimizer 說 EC2 過度配置——有信心地套用

第二個 SOA-C02 標準場景。操作流程：

1. 讀取建議。 Compute Optimizer 顯示目前 m5.4xlarge、建議 m5.2xlarge、月節省 $147、效能風險 Low。
2. 驗證基準視窗。 確認有 14 天以上的 metrics。若工作負載在視窗期間有異常閒置期（假日、凍結期），等待一個具代表性的視窗後再套用。
3. 確認記憶體 metrics 是否存在。 若未安裝 CloudWatch agent，Compute Optimizer 的建議僅基於 CPU／網路；記憶體受限的工作負載可能被誤判。先安裝 agent 讓 metrics 累積，再信任 Medium 風險建議。
4. Low / Very Low 風險：先在非生產環境直接套用，觀察一個完整的業務週期，然後透過 launch template version bump + ASG instance refresh 在生產環境套用。
5. Medium 風險：在非生產環境以真實高峰流量進行負載測試，之後才在任何地方套用。
6. High / Very High 風險：沒有明確的負載測試和利害關係人確認，不要套用；建議只是參考資訊。
7. 追蹤節省成效。 套用後，在 Cost Explorer 中驗證相關明細是否下降了約等於預測金額。差異通常指向 Compute Optimizer 未建模的資料傳輸或其他組件。

考試正確模式是將建議風險對應至行動：Low 風險 + 生產 rightsizing 是可接受的；Medium 風險需要非生產驗證；High 風險需要負載測試。

常見陷阱：成本分配標籤啟用延遲

前文已涵蓋，此處因出現頻率高而重複：成本分配標籤在啟用後最多需要 24 小時才會出現在 Cost Explorer 中，且啟用是向前生效的——歷史費用不會被追溯重新標記。SysOps 帳號開通 runbook 應在第 0 天啟用標籤 key，在預期到任何團隊層級的費用分攤報告之前。

常見陷阱：Compute Optimizer 14 天基準視窗

前文已涵蓋，此處重複以加強記憶：Compute Optimizer 需要 14 天的 CloudWatch metrics 才能產生建議。剛啟動的實例、metrics 稀疏的實例，或缺少 CloudWatch agent（記憶體）的實例，在基準累積完成之前不會產生可信的建議。

常見陷阱：Budget Action 需要範圍正確的 IAM 角色

前文已涵蓋，此處重複以加強記憶：Budget Actions 需要一個 IAM 角色，其信任 policy 允許 budgets.amazonaws.com，且其權限 policy 授予相關動作類別（organizations:AttachPolicy、iam:AttachUserPolicy、ec2:StopInstances、rds:StopDBInstance）。缺少或範圍錯誤的角色會導致 Budget Actions 靜默失敗——預算突破，動作顯示「execution failed」，補救從未發生。

常見陷阱：Spot 中斷的 2 分鐘警告是唯一通知

當 AWS 決定收回 Spot Instance 時，2 分鐘警告是唯一訊號——沒有更長的警告、沒有協商、沒有重試。需要超過 2 分鐘進行優雅關機的工作負載（長時間執行的資料庫交易、多 GB 的快取暖機）不適合 Spot。把有狀態工作負載放在 Spot 上的 SysOps 工程師，終究會遇到資料損失；正確答案要麼是對有狀態層使用 On-Demand，要麼是將工作負載設計為在 2 分鐘以內完成 checkpoint。

常見陷阱：Trusted Advisor 免費方案的檢查有限

前文已涵蓋，此處重複：Basic 和 Developer 支援方案只能看到六個核心 Trusted Advisor 檢查。完整的 Cost Optimization 類別（Idle Load Balancers、Underutilized EBS、Unassociated EIPs 等）需要 Business 或 Enterprise（含 Enterprise On-Ramp）Support。

常見陷阱：Cost Explorer 每小時粒度需要付費

Cost Explorer 預設的每日粒度是免費的；每小時粒度與資源層級粒度是 opt-in 付費功能，按每 1000 筆查詢明細計費。需要 24 小時事故窗口成本分析的 SysOps 團隊，必須在 Billing 偏好設定中啟用每小時粒度（小額費用），或拉取 CUR（免費檔案交付，但 Athena 查詢需要費用）。

常見陷阱：已停止的 EC2 實例的 EBS 仍在計費

一個常見的 SysOps 成本衝擊：停止 EC2 實例可以省下實例小時費，但不會停止 EBS volume 的計費。附加到已停止實例的 EBS volumes 繼續以相同費率計費。長期停止的實例應被終止（若需要資料，先建立 AMI／快照）——或獨立分離和刪除 EBS volumes。附加到已停止實例的閒置 Elastic IPs 也繼續以約 0.005 USD／小時計費。Trusted Advisor 的「Unassociated Elastic IP」和「Underutilized EBS」檢查可以捕捉這兩者。

SOA-C02 vs SAA-C03：運維視角的差異

SAA-C03 和 SOA-C02 都涉及成本，但視角不同。

SAA 考生選擇模型；SOA 考生操作成本工具、設定告警與動作，並在預算突破時進行補救。

考試訊號：如何識別 Domain 6.1 的題目

SOA-C02 上的 Domain 6.1 題目遵循可預測的模式。

• 「帳單暴增」 — 答案是 Cost Explorer 鑽取流程：Service → Usage Type → Tag → Region。有時補救是 VPC gateway endpoint（NAT 資料處理），有時是 rightsizing，有時是清理閒置資源。
• 「應清理閒置資源」 — 答案是 Trusted Advisor 成本檢查（Idle EC2、Underutilized EBS、Unassociated EIP、Idle RDS），需要 Business 或 Enterprise Support。
• 「Compute Optimizer 沒有顯示建議」 — 答案是 14 天基準視窗或缺少記憶體 metrics（CloudWatch agent）。
• 「Compute Optimizer 說過度配置，可以套用嗎？」 — 答案是讀取風險等級：Low/Very Low → 以正常變更管理套用；Medium → 非生產環境驗證；High/Very High → 先負載測試。
• 「需要在超出預算之前通知團隊」 — 答案是 AWS Budgets 在 80% 預測值設定，加上通知 SNS topic。
• 「需要自動停止超支」 — 答案是 Budget Actions（拒絕 SCP、IAM 拒絕 policy，或停止 EC2/RDS），搭配範圍正確的 IAM 角色。
• 「標籤已啟用但不在 Cost Explorer 中」 — 答案是 24 小時啟用延遲。
• 「工作負載適合 Spot Instances 嗎？」 — 答案是 stateless + fault-tolerant + 跨類型/AZ 靈活 + time-elastic；透過有 Capacity Rebalancing 的 ASG Mixed Instances Policy 使用。
• 「SP / RI 使用率太低」 — 答案是 SP utilization budget 或 RI utilization budget，在低於 95% 時告警。
• 「自訂細粒度成本分析」 — 答案是 CUR（Parquet）+ 透過 Glue crawler 的 Athena。

決策矩陣 — 各 SysOps 目標對應的成本工具

考試時使用以下查找表。

常見陷阱總回顧 — 成本可視化、Budgets 與 Rightsizing

每次 SOA-C02 考試都會出現其中兩三個干擾選項。

陷阱 1：成本分配標籤套用後立即生效

不是這樣的。將標籤套用到資源是第一步；在 Billing console 中啟用標籤是第二步；等待最多 24 小時讓回填完成是第三步。啟用是向前生效的，所以啟用之前的歷史費用不會被追溯重新標記。

陷阱 2：Compute Optimizer 永遠有建議

並非如此。剛啟動的實例（不足 14 天）、metrics 稀疏的實例、缺少 CloudWatch agent 取得記憶體 metrics 的實例，以及被分類為「Optimized」的實例，都不會產生可操作的建議。

陷阱 3：Trusted Advisor 完整檢查是免費的

完整的 Cost Optimization 類別需要 Business、Enterprise 或 Enterprise On-Ramp Support。Basic 和 Developer 方案只能看到六個核心檢查（主要是 Security 和 Service Limits）。

陷阱 4：已停止的 EC2 實例不需費用

實例小時費停止，但 EBS volumes 仍在計費，任何附加到已停止實例的 Elastic IP 也以約 0.005 USD/小時繼續計費。真正閒置的實例應被終止，或獨立清理 volumes 和 EIPs。

陷阱 5：詳細監控或每小時 Cost Explorer 是免費的

EC2 詳細監控按每個 metric 每月計費。Cost Explorer 每小時粒度按每 1000 筆查詢明細計費。兩者費用都很小，但在機群規模下會累積。

陷阱 6：預算告警設在 100% 就足夠了

到了 100%，那個週期已經超支了。運維成熟度的體現是設定 80% 預測值告警，讓團隊有充足的前置時間採取行動。

陷阱 7：Budget Actions 不需要 IAM 角色就能自動觸發

不是這樣的——Budgets 需要一個可以扮演的 IAM 角色，且該角色需有正確的權限類別。缺少或範圍錯誤的角色會導致靜默失敗。

陷阱 8：Spot Instances 可以在沒有警告的情況下被收回

收回永遠會附帶 2 分鐘的警告，透過 IMDS 和 EventBridge 發出。但 2 分鐘是唯一的視窗——沒有更長的通知，所以需要超過 2 分鐘進行優雅關機的工作負載不適合 Spot。

陷阱 9：Cost Explorer rightsizing 可以取代 Compute Optimizer

不能。Cost Explorer 的 rightsizing 僅涵蓋 EC2，且是較簡單的引擎；Compute Optimizer 涵蓋 EC2、ASG、Lambda 和 EBS，有更深層的 ML 模型和明確的風險等級。兩者互補；SOA-C02 期望你在需要更廣、更細緻視圖時使用 Compute Optimizer。

陷阱 10：CUR 和 Cost Explorer 是同一件事

CUR 是交付至 S3 的原始明細檔案（CSV 或 Parquet），可透過 Athena／Redshift Spectrum／QuickSight 查詢。Cost Explorer 是帶有內建維度的互動式主控台。臨時調查用 Cost Explorer，程式化和自訂報告用 CUR。

FAQ — 成本可視化、Budgets 與 Rightsizing

Q1：為什麼我剛啟用的成本分配標籤不出現在 Cost Explorer 中？

Billing console 中的標籤啟用是非同步的——AWS Billing 需要最多 24 小時才能將標籤維度回填至 Cost Explorer、AWS Budgets 和 Cost and Usage Report。啟用也是向前生效的：啟用時刻之前的歷史費用不會被追溯重新標記，所以即使 24 小時過去後，你也只會看到新支出依標籤分組，舊的支出不會有。SysOps 最佳實踐是在帳號開通時就定義標籤分類法並啟用 key，在資源建立之前——並以 SCP 或 AWS Config rule 強制執行標籤存在，確保未來的資源不能逃脫費用分攤。

Q2：為什麼 Compute Optimizer 沒有為我的 EC2 實例顯示建議？

四個常見原因。(1) Compute Optimizer 未對帳號或組織 opt-in — 在 Compute Optimizer 主控台修正。(2) 實例運行不足 14 天 — Compute Optimizer 需要 14 天的滾動 CloudWatch metrics 基準才能產生建議。(3) 記憶體 metrics 缺失 — 對於記憶體受限的工作負載，安裝 CloudWatch agent 讓它將 mem_used_percent 發布至 CWAgent namespace，否則建議只基於 CPU／網路／磁碟 I/O。(4) 實例被分類為 Optimized — 已正確配置，無需建議。等待 14 天，若記憶體很重要就安裝 agent，建議就應該出現了。

Q3：如何設定一個在預算突破時自動停止 EC2 實例的 Budget Action？

設定分為四個部分：(1) 建立 AWS Budget，設定你想要的閾值（成本或使用量）；(2) 建立一個 IAM 角色，其信任 policy 允許 budgets.amazonaws.com 扮演它，且其權限 policy 授予對相關資源 ARN 的 ec2:StopInstances；(3) 設定類型為「Apply IAM policy」或「Stop EC2/RDS instances」的 Budget Action，並引用 IAM 角色及目標實例 ID 或標籤篩選；(4) 選擇 Automatic 或 Manual approval。最常見的失敗模式是 IAM 角色缺少權限——動作在 Budgets 主控台中顯示「execution failed」，而非執行。在依賴該動作之前，用 IAM Policy Simulator 驗證 IAM 角色。

Q4：我的月帳單暴增 30%——在 Cost Explorer 中的第一步是什麼？

開啟 Cost Explorer，設定日期範圍為「Last 6 Months」、粒度為「Monthly」，並依 Service 分組識別哪個 AWS 服務增長。找到服務後，篩選至該服務並依 Usage Type 分組識別具體明細——NAT Gateway 資料處理費 vs NAT Gateway 小時費、S3 PUT/GET vs 儲存費、RDS 儲存 vs 實例小時費。然後篩選至高峰 usage type 並依 Linked Account 或 Tag 分組識別負責的團隊。最後，依 Region 或 AZ 分組找出局部問題。常見補救：S3/DynamoDB 的 VPC gateway endpoint 繞過 NAT、實例 rightsizing、閒置資源清理，或將喜歡聊天的層次集中在同一個 AZ 以減少跨 AZ 資料傳輸。

Q5：哪些工作負載適合 EC2 Spot Instances？

無狀態（失去實例不會遺失狀態）、容錯（工作已被 checkpoint 或排入佇列，損失可恢復）、跨實例類型與 AZ 靈活（工作負載在 m5、m5a、m6i、c5 等上都能同樣良好運行，給 Spot 分配器更多容量池）以及時間彈性（啟動延遲是可接受的）的工作負載。典型的 Spot 適用工作負載：批次處理、大數據 ETL、CI/CD 建置 workers、render farms、網頁爬蟲、SQS 後面的容錯容器化服務、有 Mixed Instances Policy 的 ASG 機群。不適合的：有狀態資料庫、有本地狀態的單一實例應用伺服器、2 分鐘中斷警告時間不足以完成優雅關機的硬截止時限工作負載。

Q6：Spot Instance 的 2 分鐘中斷警告如何到達我的應用程式？

兩個管道。(1) EC2 Instance Metadata Service（IMDS） — 路徑 http://169.254.169.254/latest/meta-data/spot/instance-action 在中斷迫近時回傳含計劃終止時間的 JSON 文件；應用程式可以每 5–10 秒輪詢 IMDS 並作出反應。(2) Amazon EventBridge — AWS 將 EC2 Spot Instance Interruption Warning 事件發布至預設事件匯流排，可路由至 Lambda、SNS、Step Functions 或 Systems Manager Automation runbook 進行集中處理。穩健的模式是使用 EventBridge 進行機群層級的處理（排空 ALB 目標、從服務探索取消登錄），並在實例內輪詢 IMDS 進行本地清理（將記憶體狀態刷新至 S3、乾淨地退出容器程序）。2 分鐘是唯一的視窗——需要更長時間的工作負載不適合 Spot。

Q7：何時使用 AWS Cost and Usage Report（CUR）而非 AWS Cost Explorer？

使用 Cost Explorer 進行臨時調查、使用內建維度的高管儀表板、主控台驅動的鑽取（Service → Usage Type → Tag），以及最多 12 個月的預測。使用 CUR + Athena（或 Redshift Spectrum 或 QuickSight） 進行程式化報告、需要每個資源每小時明細的自訂費用分攤腳本、細粒度的多月趨勢分析、與非 AWS 工具的財務團隊整合，以及任何 Cost Explorer UI 原生不支援的自訂切割方式。標準的 CUR 設定是啟用 Athena 整合的 Parquet 格式，會自動建立 Glue crawler 和 Athena 資料表——然後執行如 SELECT product_servicecode, SUM(line_item_unblended_cost) FROM cur_table GROUP BY 1 ORDER BY 2 DESC 的 SQL。CUR 月度最終資料在月底後約 24 小時提供。

Q8：為什麼我的帳號中大多數 Trusted Advisor 成本檢查都缺失？

Trusted Advisor 的完整檢查集——包含整個 Cost Optimization 類別（Idle EC2、Underutilized EBS、Unassociated Elastic IPs、Idle RDS、Idle Load Balancers 等）——需要 Business、Enterprise 或 Enterprise On-Ramp 支援方案。免費的 Basic 和 Developer 支援方案只能看到六個核心檢查（主要是 Service Limits 和少量 Security 檢查）。要解鎖完整的 Cost Optimization 類別，請升級支援方案。SOA-C02 直接測試這點：當題目問「團隊想啟用 Idle Load Balancers 和 Underutilized EBS Volume 檢查」，正確答案是將 Trusted Advisor 服務與 Business/Enterprise Support 要求配對。

Q9：SOA-C02 中 Reserved Instances 和 Savings Plans 的差異是什麼？

**Reserved Instances（RI）**是對特定 instance family、region、OS 和 tenancy 的 1 年或 3 年承諾，換取最高約 72% 的 On-Demand 折扣。Standard RI 鎖定那些屬性；Convertible RI 可以在期限內換成不同 family，折扣略低。Savings Plans（SP）是對每小時計算支出金額的 1 年或 3 年承諾，換取折扣。Compute SP 廣泛適用於 EC2（任何 family/region/OS）、Fargate 和 Lambda，最高約 66% 折扣。EC2 Instance SP 鎖定特定 region 中的特定 family，最高約 72%，與 Standard RI 相當，但承諾是基於金額而非實例。SOA-C02 不要求深度數學——它測試使用率預算（當 SP/RI 使用率低於 95% 時告警）、涵蓋率預算，以及讀取 Cost Explorer 的購買建議。

Q10：應該使用 Compute Optimizer 還是 Cost Explorer rightsizing？

Compute Optimizer 是範圍更廣、更深層的工具——涵蓋 EC2 實例、EC2 Auto Scaling groups、AWS Lambda functions 和 Amazon EBS volumes，並為每條建議輸出明確的風險等級（Very Low 到 Very High）。Cost Explorer 的 rightsizing 建議只涵蓋獨立 EC2 實例，且是較簡單的引擎，風險粒度沒有那麼細緻。兩者互補。SOA-C02 對任何「跨計算和儲存的 ML 驅動建議」題目都偏好 Compute Optimizer，只在「在 Cost Explorer 主控台中快速查看 EC2 rightsizing」的題目中使用 Cost Explorer rightsizing。在實際操作中，為記憶體 metrics 安裝 CloudWatch agent，在組織層級 opt-in Compute Optimizer，等待 14 天基準，然後優先套用 Low 和 Very Low 風險建議。

延伸閱讀與相關運維模式

• What is AWS Cost Explorer
• Cost Explorer Rightsizing Recommendations
• Activating User-Defined Cost Allocation Tags
• Managing Costs with AWS Budgets
• Configuring AWS Budgets Actions
• What is AWS Compute Optimizer
• Compute Optimizer EC2 Recommendations
• Compute Optimizer Auto Scaling Group Recommendations
• Compute Optimizer Lambda Recommendations
• Compute Optimizer EBS Volume Recommendations
• AWS Trusted Advisor User Guide
• Trusted Advisor Cost Optimization Checks
• EC2 Spot Instances
• Spot Instance Interruptions
• AWS Savings Plans User Guide
• AWS Cost and Usage Report (CUR)
• Querying CUR with Amazon Athena
• AWS SOA-C02 Exam Guide v2.3 (PDF)

成本可視化建立之後，下一個運維層是：效能最佳化（EBS、RDS、EC2、S3），這是 Domain 6 rightsizing 的效能面（成本視角在此與效能視角於 Compute Optimizer 和 CloudWatch metrics 交匯）；Multi-Account 策略搭配 Organizations 和 Control Tower，提供 Budget Actions 附加的 SCP 防護欄，以及組織層級的成本分配標籤和 Compute Optimizer 啟用；EC2 Auto Scaling、ELB 和 Multi-AZ HA，這些工具所管理的工作負載層的 rightsizing 和 Spot 使用正是由這些工具所治理；以及 CloudWatch Metrics、Alarms 與 Dashboards，這是 Compute Optimizer 和 Cost Explorer rightsizing 兩者都消耗的底層 metrics。

• 效能最佳化：EBS、RDS、EC2 與 S3 — SOA-C02 學習筆記
• Multi-Account 策略搭配 Organizations 和 Control Tower — SOA-C02 學習筆記
• EC2 Auto Scaling、ELB 與 Multi-AZ 高可用性 — SOA-C02 學習筆記
• CloudWatch Metrics、Alarms 與 Dashboards — SOA-C02 學習筆記