正式環境工作負載的成本優化

針對現有 AWS 工作負載的成本最佳化，是一門把 FinOps 理念追加植入既有 AWS 環境的學科——在不中斷生產、不要求各團隊重寫應用程式的前提下完成，更不能引發政治反彈，否則下一次最佳化行動還沒開始就注定胎死腹中。在 SAP-C02 中，現有工作負載的成本最佳化屬於 Task 3.5，位於 Domain 3（現有解決方案的持續改善，佔考試 25%），也是唯一以**整改（remediation）**視角出題的成本主題，而非全新設計。每道題目的情境都從一個正在運行的系統出發——「某公司有 20 個帳號，年支出 $2M」、「CUR 報告顯示每月 NAT Gateway 資料處理費用 $50K」、「200 台 EC2 執行個體平均 CPU 用量 8%」——並詢問該拉動哪些成本最佳化槓桿、以何種順序、搭配何種護欄。因此，現有工作負載的成本最佳化不只是認識服務，更是以正確的順序排列服務：讓第一週就有看得見的成果，第五十週仍保有動能。

本指南假設你已具備 Associate 等級的成本基礎知識（On-Demand vs Reserved Instances vs Spot、S3 儲存類別、Trusted Advisor 存在），並聚焦在 Pro 等級的稽核至整改工作流程：AWS Cost and Usage Report (CUR) 落地 Amazon S3、透過 Amazon Athena 查詢、以 Amazon QuickSight 視覺化；AWS Compute Optimizer 與 AWS Trusted Advisor 提供閒置資源發現；Savings Plans 建議與 Reserved Instance Exchange 之間的平衡；Spot 遷移計畫（兼顧中斷容忍度）；EC2 世代遷移至 Graviton；Amazon EBS gp2 → gp3 批次轉換；Amazon S3 Storage Lens → S3 Intelligent-Tiering → 生命週期規則；閒置資源清除；以及針對 AWS PrivateLink VPC endpoints、Amazon CloudFront 覆蓋率和 NAT Gateway 拓樸的資料傳輸稽核。目標是達到 Pro 等級的決策能力，並備有一份讓二十個帳號擁有者始終站在你這邊的推行計畫。

為什麼現有工作負載的成本最佳化在 SAP-C02 如此重要

在 Professional 等級，AWS 期望你把成本視為與可靠性、安全性並列的一等架構約束。SAP-C02 考試指南的 Task 3.5（「識別成本最佳化機會」）約佔 Domain 3 題目的 15%，而近期考生的社群資料顯示，最常見的陷阱包括：在執行覆蓋率與使用率報告之前就購買 Savings Plans 承諾；對有狀態工作負載建議使用 Spot；對 128 KB 以下的物件選擇 S3 Intelligent-Tiering；未確認引擎版本支援就將 RDS 遷移至 Graviton；以及忘記 Savings Plans 在承諾期內無法取消。

考試也喜歡讓 Compute Optimizer 對決 Trusted Advisor 對決 Cost Explorer 右調整建議，以及Savings Plans 對決 Reserved Instances 對決 Spot 應對同一工作負載。最快的應對方式，就是清楚知道哪個工具掌握哪種訊號，以及哪種最佳化槓桿適用於哪類浪費。

白話文解釋現有工作負載的成本最佳化

把 FinOps 追加植入既有 AWS 環境，可能令人望而生畏，因為它牽涉十個服務和二十個利害關係人。三個類比能讓整體計畫豁然開朗。

類比一：老屋水電節能改造

想像你剛買下一棟四十年的老公寓，水電費是鄰居的三倍。你不會把房子拆掉重建，而是節能翻新。針對現有 AWS 工作負載的成本最佳化，做法完全相同。首先，你聘請能源稽核員帶著熱像儀逐房掃描——這就是 CUR + Athena + QuickSight 稽核，產出哪些房間（帳號、服務、標籤）最耗費成本的熱力圖。稽核員接著按優先序列出發現：「閣樓隔熱最差、鍋爐已用二十年、一半燈泡是白熾燈、冰箱是 1998 年買的」——這就是 Trusted Advisor + Compute Optimizer + Storage Lens 的發現清單，依金額影響排序。接著是速效週：把所有燈泡換成 LED（EBS gp2 → gp3、刪除未掛載的 Elastic IP、刪除舊 AMI）——零風險、當天見效。之後才排定季節性大改——秋天替閣樓加隔熱、春天換鍋爐——因為這些需要規劃，無法同時施工（Graviton 遷移、RDS 引擎升級、Savings Plans 承諾）。最後，你針對現在掌握的穩定基準用電量，與電力公司簽訂固定費率合約（Savings Plans），並在出遊的月份保留一些浮動彈性（Spot 用於批次）。關鍵洞察是順序很重要：你不會在量電錶不到一個月就買新鍋爐，也不會在不知道基準用量前就簽固定費率合約。

類比二：超商進銷存大整頓

針對現有 AWS 環境的成本最佳化，就像接手一家前任店長從未用過存貨系統的超商。CUR 是過去十二個月每台收銀機的收據。Athena 是對這些收據跑 SQL 的分析師。QuickSight 是後台牆上每個部門主管每週一都要看的看板。Trusted Advisor 是每週巡店一次的稽查員，記錄「這台冷藏櫃是空的但還在運轉（未使用的 Elastic IP）、這些貨物已過期（舊 AMI）、這台冷凍庫對現有庫存量來說太大（超規格 EC2）」。Compute Optimizer 是冷凍設備工程師，檢視每台冷凍庫的內部溫度歷史並說「可以換一台小四成的機型，保冷效果一樣好」（從 m5.2xlarge 右調整至 m6g.large）。S3 Storage Lens 是倉庫庫存攝影機，顯示哪些貨架九十天沒被碰——正是透過生命週期規則移到深冷庫（S3 Glacier Deep Archive）的最佳候選。Savings Plans 是超商與乳製品供應商簽訂三年合約，以保底量換取七折優惠，同時繼續在現貨市場買季節性額外補貨（EC2 Spot）。就像現實中的零售主管，你絕對不會在週五下午告訴庫房員工「週一我們要換掉所有冷凍庫」——你先在 7 號走道試行，量化成果，再逐走道推廣。

類比三：物流公司車隊管理員

一家有機成長了十年、擁有五百台車的物流公司車隊，看起來就和一個二十帳號的 AWS 環境如出一轍。CUR 是每輛車的油卡資料。Athena 加上 QuickSight 是依每公里每司機每路線排出成本順序的車隊看板。Compute Optimizer 是遙測平台，記錄「217 號車載重永遠只有兩成——換台小貨車就好」。Trusted Advisor 是每週廠區巡查，標記未登記的拖車（未掛載的 EBS 磁碟區）、停了九十天的車（已停止的執行個體），以及路稅過期的車（閒置的 Classic Load Balancer）。Graviton 遷移是把柴油車換成同底盤的油電混合車——路線不變、司機不變，油耗少兩成，但每輛車需要一週進廠。gp2 → gp3 是把舊款輪胎換成更便宜、更高效能但相同鎖孔規格的新款——原地更換，不需要換車。Spot 是向人力派遣公司租司機應付旺季高峰，接受他們可能在兩分鐘內被召回——倉庫對倉庫的短途沒問題，易腐食品長途運輸就是自殺。Savings Plans 是三年期定量燃油合約。RI Exchange 是把舊柴油廂型車合約換成等值的新款油電車合約。而且，車隊管理員從不宣布「下季所有車輛全部汰換」——他們公布一份成本最佳化計畫（Cost Optimization Portfolio），訂定各廠區省本目標，讓各廠區先試行兩輛車，再把可行方案推廣出去。

起點：現有工作負載成本最佳化通常在哪裡出錯

在使用任何工具之前，先認清三種會讓成本最佳化計畫徹底失敗的模式。第一，「先買後量」反模式：某個團隊在執行任何覆蓋率報告之前就買了 $500K 的 Savings Plan，之後才發現半個承諾量閒置，因為一個大型工作負載下季就要下線。第二，「一刀切大規模遷移」反模式：某個中央團隊宣布全面進行 Graviton 遷移，但沒有做逐服務相容性稽核，碰到單一套件不相容後就停擺六個月。第三，「突襲式成本回沖」反模式：FinOps 透過 SCP 強制標籤執行卻未事先告知，第一天就打壞三條部署流水線，從此失去全年的政治支持。

在 SAP-C02 中，任何在執行稽核之前就以購買承諾、全面遷移或強制執行控制作為開端的答案，幾乎肯定是錯的。正確的 Pro 等級模式永遠是觀察 → 分段 → 試行 → 擴展 → 執行。

成本稽核工作流程：CUR + Athena + QuickSight

AWS Cost and Usage Report 是唯一能以小時粒度捕捉每一筆 AWS 支出明細的資料集，包含每個使用者定義的成本分配標籤、每筆 RI 或 Savings Plans 攤銷拆分，以及每個未混合和混合費率。它是 Pro 等級成本最佳化的基礎來源，且本身免費——你只需支付 Amazon S3 儲存費用和任何下游查詢費用。

針對現有工作負載成本最佳化的標準稽核架構是三段式流水線。首先，管理帳號以 Parquet 格式將 CUR 交付至共享服務或帳單帳號中的集中式 Amazon S3 儲存桶，設定小時粒度、啟用資源 ID、以時間為基礎分割（s3://bucket/cur/year=YYYY/month=MM/）。接著，AWS Glue 爬梳 CUR schema 並在 AWS Glue Data Catalog 中將其登錄為外部資料表，使 Amazon Athena 能直接對 Parquet 檔案執行 SQL 查詢。最後，Amazon QuickSight 以 Athena 作為資料來源，發布儀表板並以適當的權限等級分享給帳號擁有者——帳號擁有者只看到自己的切片，FinOps 可看見整個環境。

三個標準 QuickSight 儀表板

每個 SAP-C02 情境隱性期望的三個成本最佳化儀表板：

儀表板 1 — 標籤覆蓋率儀表板。 顯示每個帳號中各必要標籤（CostCenter、Environment、Owner、Project）的支出覆蓋率百分比。標籤覆蓋率低於 80% 是阻礙成本回沖和成本最佳化的最大單一障礙，因為未標記的資源無法歸屬、因此無人負責、也就無從整改。一個有效的成本最佳化計畫能在首季將標籤覆蓋率從 40% 提升至 95%。

儀表板 2 — 各團隊服務成本儀表板。 顯示每個團隊（從 CostCenter 標籤或 AWS Cost Categories 推導）的每月支出，依服務分解，並附七天和三十天趨勢。目標是給每個團隊一個單位成本視角：「每位活躍用戶的成本」、「每筆交易的成本」、「每 1000 次 API 呼叫的成本」。沒有單位成本視角，團隊對最佳化毫無動力，因為在用量成長時壓低絕對支出看起來像是倒退。

儀表板 3 — 浪費獵捕儀表板。 將 CUR 明細與 Trusted Advisor 閒置資源發現和 Compute Optimizer 建議合併，產出排序清單：「潛在每月節省金額前 20 名資源」。每一列顯示資源 ID、帳號、標籤擁有者、當前成本、整改後預估成本和建議行動。這是驅動每週浪費獵捕例會的核心儀表板。

前三個 Athena 查詢

對於一個年花費 $2M、二十帳號的環境，針對 CUR 的前三個 Athena 查詢值得熟記，因為它們能產出初期整改待辦清單的 80%。

查詢 1 依 line_item_usage_account_id 對最近三十天的 line_item_unblended_cost 排序——找出驅動大部分支出的三到四個帳號。查詢 2 依 product_product_name 和 line_item_usage_account_id 分組——產出服務對帳號的支出熱力圖，前十大明細通常一目了然（典型為 Amazon EC2、Amazon RDS、Amazon S3、AWS Data Transfer 和 NAT Gateway）。查詢 3 篩選 line_item_operation 中的 NatGateway 和 DataTransfer 明細——NAT Gateway 資料處理費用（us-east-1 為 $0.045/GB）往往主導資料傳輸帳單，且是風險最低、回本最快的最佳化目標。

跨組織的 Trusted Advisor + Compute Optimizer

AWS Trusted Advisor 與 AWS Compute Optimizer 是現有工作負載成本最佳化的互補工具，並非競爭關係。Trusted Advisor 是廣度工具——一次掃描、數十個檢查類別、每個檢查的深度較淺。Compute Optimizer 是深度工具——範圍較窄（EC2、Auto Scaling groups、EBS、Lambda、ECS on Fargate、RDS、EC2 上的商業資料庫），但有機器學習驅動的建議，背後由十四天的 CloudWatch 指標支撐。

企業規模下的 Trusted Advisor 成本最佳化檢查

Trusted Advisor 在 Business 或 Enterprise Support 等級下解鎖完整的成本最佳化類別——約二十項檢查，包含低使用率 Amazon EC2 執行個體、閒置 Load Balancer、未關聯的 Elastic IP 位址、未充分使用的 Amazon EBS 磁碟區、Amazon RDS 閒置資料庫執行個體、Amazon S3 Bucket 生命週期政策、Amazon EC2 Reserved Instance 租約到期、AWS Lambda 函數高錯誤率，以及 Savings Plan 覆蓋率檢查。在組織規模下，Trusted Advisor 的發現透過 AWS Organizations 彙總——管理帳號或委派管理員可以跨每個連結帳號檢視組織層級的發現。

針對現有二十帳號工作負載的成本最佳化，每週的浪費獵捕例會會審視每個帳號中金額影響最高的五項 Trusted Advisor 檢查：超過三十天未掛載的 EBS 磁碟區、未關聯的 Elastic IP、七天內零請求的閒置 Classic 或 Application Load Balancer、連續十四天 CPU 低於 10% 且網路 I/O 低於 5 MB 的未充分使用 EC2 執行個體，以及低使用率 RDS 執行個體。

組織層級的 Compute Optimizer

從管理帳號透過組織層級 opt-in 啟用的 AWS Compute Optimizer，能在一個地方為每個連結帳號產出建議。EC2 的四種建議類型為：NotOptimized 搭配 Underprovisioned（執行個體受 CPU 或記憶體瓶頸制約，需要更大的系列或規格）、Overprovisioned（執行個體可以縮小，通常是最高價值的建議）、Optimized（無需更動），以及 None（指標資料不足——觀察時間未滿十四天）。

Compute Optimizer 的建議具備 Graviton 感知能力——對每一項建議，它都會顯示對應的 Graviton 執行個體系列（例如：目前 m5.2xlarge → 建議 m6g.large 或 m7g.large）及預計每月節省金額。針對記憶體型右調整，Compute Optimizer 需要在執行個體上安裝 CloudWatch 代理程式以擷取記憶體使用率指標；若沒有代理程式，Compute Optimizer 只能依 CPU 和網路進行右調整。

稽核工作流程的 Pro 等級順序

SAP-C02 所認可的 Pro 等級稽核工作流程是：(1) 第一週啟用 CUR + Trusted Advisor Business/Enterprise + Compute Optimizer 組織層級 opt-in；(2) 等待十四天讓 Compute Optimizer 積累足夠的指標資料；(3) 第三週建立三個 QuickSight 儀表板；(4) 第四週舉行首次浪費獵捕例會，依金額影響排序發現；(5) 從第五週起每週舉行例會，從清單頂端逐步建立工單。

稽核工作流程：每週浪費獵捕例會

每週浪費獵捕例會是將成本最佳化發現轉化為整改行動的操作節奏。這不是 AWS 發明的儀式——而是 FinOps Foundation「告知、最佳化、營運」循環在 AWS 工具上的落地實踐。

針對現有工作負載的成本最佳化，一次典型例會議程為 45 分鐘。FinOps 負責人呈現浪費獵捕儀表板中最新的前十項發現。每項發現都有具名擁有者（從 Owner 標籤或帳號分配推導）、金額，以及建議行動。擁有者在五分鐘內確認或質疑建議——若確認，即在團隊的問題追蹤系統中建立工單，設定兩週截止日；若質疑，擁有者提供業務理由，該發現在 QuickSight 中被靜音（更新一張由 CUR 支撐的靜音對照表）。

例會有三個明確需要避免的反模式。首先，絕不點名羞辱——各團隊以 CostCenter 列出並附節省目標，絕不以個別工程師姓名呈現。其次，絕不強制推翻擁有者的拒絕——如果某團隊說「這台執行個體必須維持 r5.4xlarge，因為它跑的是年度批次作業，在十四天窗口內無法評估」，FinOps 記錄例外並繼續推進。第三，絕不在例會上批准承諾購買——Savings Plans 和 Reserved Instance 的採購另行召開每月預測會議討論。

Savings Plans 建議引擎與覆蓋率缺口

AWS Savings Plans 是現有工作負載中單一金額影響最高的成本最佳化槓桿——一年期全額預付 Compute Savings Plan 比 On-Demand 折扣 27% 至 36%，三年期全額預付最高可達 66%。對於年支出 $2M、穩定基準佔 60% 的環境，一個規模適當的 Savings Plans 組合每年可節省 $400K 至 $600K。

Savings Plans 有三種類型：Compute Savings Plans（最靈活——適用於所有地區、執行個體系列、規格、租用方式和作業系統的 EC2，以及 Fargate 和 Lambda）、EC2 Instance Savings Plans（鎖定特定地區的特定執行個體系列，折扣高於 Compute，但彈性較低），以及 SageMaker Savings Plans（僅適用於 SageMaker ML 工作負載）。針對異質性的二十帳號工作負載成本最佳化，Compute Savings Plans 幾乎永遠是正確選擇，因為其彈性能在執行個體系列遷移時（例如 m5 → m6g）不破壞承諾。

解讀覆蓋率與使用率報告

AWS Cost Explorer 發布兩份 Savings Plans 報告，合在一起驅動承諾決策。覆蓋率回答「我的合格 On-Demand 支出中，有多少百分比已被 Savings Plan 覆蓋？」——覆蓋率 40% 意味著 60% 的運算支出仍以全額 On-Demand 費率計費，是一個購買機會。使用率回答「我已擁有的 Savings Plan 承諾中，有多少百分比正在被使用？」——使用率 95% 表示承諾健康；使用率 60% 表示過度承諾，正在為未使用的容量付費。

針對現有工作負載成本最佳化的 Pro 等級啟發式規則是：以整體組合達到 80% 覆蓋率和 95% 使用率為目標。覆蓋率低於 80%，購買更多 Savings Plans。使用率低於 95%，停止購買並調查現有承諾未被充分使用的原因——通常是某個工作負載已下線，或遷移到 EC2 Instance Savings Plan 未覆蓋的地區。

AWS 在 Cost Explorer 提供 Savings Plans 建議引擎，分析最近七天、三十天或六十天的 On-Demand 使用情況，並提出承諾水準建議及預估每月節省和損益平衡小時數。引擎支援三種付款選項（全額預付、部分預付、無預付）和兩種期限（一年、三年）。對於不穩定的現有環境的成本最佳化，一年期無預付 Compute Savings Plan，大小定在目前基準的 70% 至 80%，是最安全的起始承諾——它捕捉了大部分折扣，不鎖定資本或超過下一個預算週期的期限。

Spot 遷移計畫：識別、試行、推廣

Amazon EC2 Spot 容量提供比 On-Demand 最高 90% 的折扣，代價是 AWS 可在兩分鐘中斷通知後回收容量。在現有工作負載上進行 Spot 遷移是一項精準手術：先識別可容忍中斷的工作負載，在一個服務上試行，再擴展推廣。

識別：哪些現有工作負載能容忍 Spot

針對現有工作負載成本最佳化的分類規則是：一個工作負載可容忍 Spot，當且僅當它是無狀態、水平可擴展、可重跑，且在個別執行個體層面不具時間敏感性。標準候選包括：EMR 上的批次 ETL 作業、CI/CD 建置執行器、算圖農場、ALB 後方具備健康檢查驅動替換的無狀態 Web 層、具備優雅關閉處理程式的容器化微服務，以及有多個副本的 Amazon EKS 或 Amazon ECS 工作負載。標準非候選包括：單一主節點資料庫（RDS、自管理 PostgreSQL）、沒有外部 session 儲存的 session 有狀態伺服器、任何具備「無中斷」SLA 的工作負載，以及無法設定檢查點的遷移或批次作業。

兩週試行

針對現有工作負載成本最佳化的 Spot 遷移試行，使用 AWS Auto Scaling Groups 搭配混合執行個體政策：On-Demand 基礎容量 100%，加上所有擴展容量使用 Spot，跨越四到六種相同 vCPU 等級的執行個體類型。Auto Scaling Group 設定 capacity-optimized-prioritized 分配策略，優先選擇 Spot 容量最充裕的池。一個 Lambda 函數訂閱 EC2 Spot Instance Interruption Warning 事件（EC2 Spot Instance Interruption），在兩分鐘通知窗口內將執行個體從 ALB 目標群組中排除。

兩週試行量測中斷率、平均替換時間、應用程式層錯誤率和單位成本。若中斷率維持在每天 5% 以下，且應用程式層錯誤維持在 SLO 以內，則工作負載晉升為全 Spot 擴展。若中斷激增或應用程式錯誤超過 SLO，工作負載維持 50% Spot 或退回全額 On-Demand。

全組織推廣

推廣模式是每個 sprint 一個服務，先在流量最低的帳號試行（通常是開發 OU），再升至測試，最後升至生產。一個季度結束時，年支出 $2M、40% 工作負載可使用 Spot 的環境，通常能達到 25% 至 30% 的 Spot 覆蓋率，在 Savings Plans 之外再追加約 $150K 至 $200K 的年度節省。

EC2 世代遷移：Pre-Graviton → Graviton 及 t2 → t3 → t3a

EC2 世代遷移是現有工作負載成本最佳化中，繼 Savings Plans 之後金額影響第二高的槓桿。每次世代轉換，相同工作負載的性價比提升 10% 至 40%，而遷移通常是一次原地執行個體類型變更，僅需單次重新開機。

三種標準世代遷移

t2 → t3 → t3a。 t2 系列使用可能在持續負載下急劇節流的 CPU Credits；t3 預設使用無限制 Credits（有每 vCPU/小時附加費上限），性價比提升約 10% 至 20%。t3a 使用 AMD EPYC 處理器，相同 vCPU/記憶體比下比 t3 便宜 10%，對大多數通用工作負載效能相當。針對現有二十帳號環境的成本最佳化，將機群從 t2 遷移至 t3a 通常是一個 sprint 的專案，每個遷移執行個體可節省 15% 至 25%。

m4 → m5 → m6i → m7i-flex / m7g。 m4 系列是 Intel Haswell/Broadwell；m5 是 Intel Skylake/Cascade Lake；m6i 是 Intel Ice Lake；m7i-flex 是 Intel Sapphire Rapids 的彈性突發變體。每個世代對相同工作負載提供約 10% 至 15% 的性價比提升。m7g 是 Graviton 3 等效——對相容工作負載提供比 m6i 高 20% 至 40% 的性價比。

Pre-Graviton → Graviton（m5 → m6g → m7g、c5 → c6g → c7g、r5 → r6g → r7g）。 Graviton 是 AWS 的 ARM64 處理器系列（Graviton 2、3、4）。對相容工作負載，Graviton 比同世代 Intel 等效機型提供 20% 至 40% 的性價比提升。相容性需要 OS 和所有原生相依套件的 ARM64 編譯二進位檔——純 Java、Python、Node.js、Go 和 .NET Core 工作負載通常可無程式碼變更地完成遷移；C/C++ 原生二進位檔、特定商業軟體，以及含有 x86 專屬組合語言的工作負載需要重新編譯，或根本不相容。

Graviton 遷移工作流程

針對現有工作負載成本最佳化的 Pro 等級 Graviton 遷移工作流程是：(1) 使用 lscpu、dpkg --print-architecture 或容器映像 manifest 對整個環境執行相容性盤點；(2) 將工作負載分類為三個桶——綠色（純直譯/JVM，原地遷移）、黃色（需要容器重建或套件重新編譯）、紅色（商業軟體不支援 ARM64）；(3) 每個團隊試行一個綠色工作負載；(4) 以 docker buildx 將容器映像重建為多架構 manifest；(5) 在一個季度內推廣整個綠色桶；(6) 綠色桶完成後再回頭處理黃色桶。

RDS Graviton 遷移是獨立的工作流程——需要小版本引擎升級和維護窗口重啟。RDS MySQL、PostgreSQL、MariaDB 和 Aurora 均支援 Graviton；RDS 上的 SQL Server 和 Oracle 則不支援。

S3 生命週期改造：Storage Lens → Intelligent-Tiering → 生命週期規則

Amazon S3 在現有工作負載上的成本最佳化，往往是繼 Savings Plans 和 Graviton 之後 ROI 最高的行動，因為大多數環境有大量物件存放在 S3 Standard 中，但已數月未被存取。三段式工作流程是：用 Storage Lens 觀察存取模式、用 S3 Intelligent-Tiering 處理無法預測的存取而無需生命週期規則，以及針對可預測存取模式使用生命週期規則。

階段 1 — Amazon S3 Storage Lens 進階指標

Amazon S3 Storage Lens 是唯一的組織層級 S3 可觀測性工具。免費版提供二十八項指標；進階指標（付費）解鎖活動指標（每個儲存桶每天的 GET/PUT/DELETE 數量）、前綴層級彙總，以及十五項額外成本最佳化指標，例如「三十天內未被存取的物件百分比」、「Standard 中可移至 Intelligent-Tiering 的位元組數」，以及「未完成的多部分上傳」。對於 S3 中超過 100 TB 的現有環境成本最佳化，Storage Lens 進階指標在第一週就能回本。

針對年支出 $2M 環境的標準 Storage Lens 發現是：按數量計算，60% 至 80% 的物件九十天內未被存取，但仍存放在 S3 Standard。整改方式是對淨新物件採用 S3 Intelligent-Tiering，並使用生命週期規則轉移現有物件。

階段 2 — S3 Intelligent-Tiering 採用

S3 Intelligent-Tiering 是存取模式未知或變動的任何物件的預設儲存類別。它自動在四個層之間移動物件：頻繁存取、不頻繁存取（連續三十天未存取後）、封存即時存取（九十天後，若已在儲存桶層級啟用 opt-in），以及選用的封存存取和深封存存取（非同步取回，透過設定 opt-in）。頻繁、不頻繁和封存即時層不收取取回費用——只有兩個非同步封存層才收取。

Intelligent-Tiering 有每月每千物件 $0.0025 的監控和自動化費用。對於小於 128 KB 的物件，此費用超過儲存節省，因此 Intelligent-Tiering 僅對大於或等於 128 KB 的物件具成本效益。對於小物件工作負載（例如縮圖圖片流水線、每請求日誌檔），Intelligent-Tiering 是錯誤的選擇，改用三十天後轉移至 S3 Standard-IA 的生命週期規則更為適合。

階段 3 — 可預測存取的生命週期規則

生命週期規則適用於存取模式已知且確定性的情況。針對現有工作負載成本最佳化的三種標準生命週期模式：(1) 應用程式日誌——Standard 三十天，轉至 S3 Standard-IA 六十天，轉至 S3 Glacier Instant Retrieval 二百七十五天，三百六十五天後過期（典型合規保留期）；(2) 備份快照——Standard 七天，轉至 S3 Glacier Deep Archive 二千五百五十五天（金融合規七年），二千五百五十五天後過期；(3) 建置產物和 CI/CD 輸出——Standard 十四天，十四天後過期（無封存價值）。

每個現有工作負載都應該有的一條生命週期規則是未完成多部分上傳清理——七天後轉至 AbortIncompleteMultipartUpload。許多年支出 $2M 的環境有 5 至 20 TB 的孤立多部分上傳，在 S3 主控台中不可見，卻悄悄產生 Standard 儲存費用。

EBS gp2 → gp3 批次遷移

Amazon EBS gp2 → gp3 遷移是現有工作負載中單一 ROI 最高的速效行動。gp3 在結構上比 gp2 便宜（大多數地區每 GB 儲存成本低 20%），提供獨立於磁碟區大小的保證 3000 IOPS 和 125 MB/s 吞吐量基準（gp2 的 IOPS 隨大小線性擴展），並透過 ModifyVolume 支援原地類型修改且零停機——執行個體從不重新開機，I/O 在整個過程中持續進行。

針對現有二十帳號工作負載，假設有 200 TB 的 gp2 磁碟區，gp2 → gp3 遷移依地區不同每年可節省 $40K 至 $60K。遷移腳本透過 aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 迭代每個磁碟區，執行 aws ec2 modify-volume --volume-type gp3，然後繼續——以 AWS API 速率限制，200 TB 的全環境遷移通常在二十四至四十八小時內完成。

gp3 唯一需要注意的情況是：對於大於 1 TB 且 gp2 IOPS 超過 3000 的磁碟區——在這種情況下，gp3 轉換還必須指定更高的 --iops 值以保留工作負載的效能。對於絕大多數磁碟區（小於 1 TB，以預設 gp2 IOPS 執行），預設的 gp3 3000 IOPS / 125 MB/s 設定與 gp2 基準相當或更好。

閒置資源清除：第一週的速效成果

閒置資源清除是任何現有工作負載成本最佳化計畫第一週的「多巴胺」。六種標準閒置資源類別能立即、零風險地節省費用，並建立後續更艱難行動所需的政治動能。

未關聯的 Elastic IP 位址。 AWS 對每個已分配但未關聯至運行資源的 Elastic IP 收取 $0.005/小時（約 $3.60/月）。一個二十帳號環境通常有 20 至 80 個未關聯的 Elastic IP。整改方式：aws ec2 describe-addresses 篩選 AssociationId=None，透過 aws ec2 release-address 釋放。

舊 Amazon Machine Images (AMI) 和快照。 每個 AMI 參照一個或多個 EBS 快照，直到 AMI 被取消登錄且快照被刪除前持續計費。一個二十帳號環境在其生命週期中會累積 100 至 500 個 AMI，許多來自已下線的專案。整改方式：取消登錄超過九十天且未被任何 Launch Template 或 Auto Scaling Group 參照的 AMI，然後刪除底層快照。

停止超過三十天的 EC2 執行個體。 已停止的執行個體不產生運算費用，但其附加的 EBS 磁碟區仍以全費率計費。一台附有 500 GB gp2 根磁碟區的已停止 m5.xlarge，每月 EBS 費用 $50，對業務毫無價值。整改方式：識別停止超過三十天的執行個體，與擁有者確認後，終止（釋放 EBS）或快照後終止。

已分離的 EBS 磁碟區。 從終止的執行個體分離但從未刪除的磁碟區。Trusted Advisor 會直接標記這些磁碟區。整改方式：對有業務價值的磁碟區建立快照，然後刪除磁碟區。

閒置的 Classic、Application 和 Network Load Balancer。 七天內 RequestCount 為零的 Load Balancer 通常表示服務已下線。ALB 每月費用約 $16 加上 LCU 費用；NLB 類似。整改方式：與擁有者確認後刪除。

未使用的 RDS 執行個體。 七天內 DatabaseConnections 為零且 CPU 低於 5% 的 RDS 執行個體，是刪除或停止的候選。RDS 執行個體可一次停止最多七天（無運算費用，僅收儲存費用）；更長時間需要排程自動重新停止的自動化。

一個年支出 $2M、二十帳號環境的第一週清除，通常以兩到三個人日的工程投入，每年回收 $30K 至 $80K。

資料傳輸削減稽核：NAT、VPC Endpoints、CloudFront

資料傳輸是隱形的成本項目。篩選 product_product_name = 'AWS Data Transfer' 或 line_item_operation LIKE '%NatGateway%' 的 CUR 查詢，往往揭示資料傳輸是繼 EC2 和 RDS 之後第二或第三大的成本項目。

NAT Gateway 費用結構

AWS NAT Gateway 有兩個費用維度：每小時（us-east-1 為 $0.045/小時，每 NAT 約 $33/月）和資料處理（$0.045/GB）。對於每月透過單一 NAT 路由 20 TB 流量的工作負載（例如從 Amazon ECR、套件鏡像或不同地區的 Amazon S3 拉取），資料處理費用每 NAT 每月達 $900——通常是每小時費用的三十倍。乘以 15 個 VPC 中每個 VPC 的三個 AZ，NAT Gateway 在年支出 $2M 的環境中可達每月 $40K 至 $50K。

三步 NAT 削減計畫

步驟 1 — 為 Amazon S3 和 Amazon DynamoDB 新增 VPC Gateway Endpoints。 Gateway endpoints 免費（無每小時費用、無資料處理費用），透過 VPC 路由表直接路由 S3/DynamoDB 流量，不經過 NAT。對於每月從 S3 拉取 5 TB 建置產物或 ML 訓練資料的工作負載，每個 VPC 的 gateway endpoint 每月節省 $225。

步驟 2 — 為大量使用的 AWS 服務新增 VPC Interface Endpoints（AWS PrivateLink）。 Amazon ECR、Amazon CloudWatch Logs、AWS Systems Manager、Amazon SNS、Amazon SQS、AWS KMS 和 AWS Secrets Manager 的 interface endpoints，能消除對這些服務 API 的 NAT 流量。Interface endpoints 每個 AZ 每個 endpoint 收取 $0.01/小時加上 $0.01/GB 資料處理費——對任何每月超過 2 GB 的服務，比 NAT 便宜。

步驟 3 — 採用 Amazon CloudFront 處理出口流量。 對於向公共網際網路提供內容的工作負載，從邊緣節點的 CloudFront 出口比從地區直接出口便宜（且效能更好）。此外，從 S3 或 ALB 到 CloudFront 的資料傳輸是 $0.00/GB（免費）。將靜態資產工作負載放在 CloudFront 後方，可完全消除地區出口費用。

NAT 拓樸：共用 vs 每 AZ

一個常見的成本最佳化討論是：每個 AZ 部署一個 NAT（容錯，昂貴）還是在單一 AZ 部署一個共用 NAT（便宜，但引入跨 AZ 資料傳輸費用）。Pro 等級的答案是生產環境永遠使用每 AZ 一個 NAT，因為跨 AZ 資料傳輸費用（$0.01/GB 單向，來回 $0.02/GB）在任何非微量流量下都超過 NAT 每小時費用差異，而且單一 AZ 的 NAT 引入了可靠性單點故障，在 AZ 事件期間消除了任何成本節省。

保留容量右調整：RI Exchange 與 Savings Plans 組合再平衡

一旦現有工作負載有了 Savings Plans 覆蓋率，並遷移至較新的執行個體世代，承諾組合本身就需要再平衡。兩個機制至關重要：Convertible Reserved Instance Exchange，以及 Savings Plans 組合構成。

Convertible Reserved Instance Exchange

可轉換 RI（在 Savings Plans 出現之前購買，或工作負載仍偏好 RI 的情況下）可在期限中途交換為等值或更高價值的另一個可轉換 RI，只要新 RI 的剩餘期限相同或更長，且總預付價值相同或更高。這是工作負載從 m5 遷移至 m6g 時的正確整改方式——原始 m5 可轉換 RI 被交換為等效的 m6g 可轉換 RI，在遷移過程中保留折扣承諾。

Standard RI（不可轉換）無法交換——只能在 RI Marketplace 上出售，而 Marketplace 有地區限制，且需要可能花費數週才能完成的上架流程。

Savings Plans 組合構成

一個成熟的現有 $2M/年工作負載成本最佳化組合，通常有三層承諾堆疊：三年期全額預付 Compute Savings Plan 用於運算支出基礎的 50%（最大折扣、最高鎖定）；一年期無預付 Compute Savings Plan 用於中間的 20%（中等折扣、中等鎖定，每年重新評估）；On-Demand 和 Spot 用於頂端的 30%（零鎖定，吸收成長和波動）。隨著時間推移，當基礎趨於穩定，部分中間層升級至基礎層；當新工作負載上線，部分頂端遷移至中間層。

再平衡節奏為每季一次——FinOps 團隊審視覆蓋率、使用率、預測支出和任何已規劃的架構變更，然後購買增量承諾以補充基礎層和中間層。任何單季採購不超過年度總支出的 20%，如此可將任何預測失誤限制在可控範圍內。

整改順序：$2M/年二十帳號環境的 12 週推行計畫

針對現有工作負載成本最佳化的 Pro 等級整改順序，在技術相依性（在有基準資料前無法購買 Savings Plan）與政治現實（不能連續三週沒有可見成果）之間取得平衡。

第 1-2 週 — 可觀測性。 啟用 AWS Cost and Usage Report 交付至集中式 S3 儲存桶。在 Organizations 層級啟用 AWS Compute Optimizer。在 Business 或 Enterprise Support 等級啟用 AWS Trusted Advisor。啟用 Amazon S3 Storage Lens 進階指標。透過 AWS Systems Manager State Manager 將 CloudWatch 代理程式部署至每台 EC2 執行個體。交付項目：原始資料開始流動，但尚未進行任何最佳化。這週沒有可見的節省，但是後續所有事項的硬相依性。

第 3-4 週 — 儀表板與浪費獵捕。 建立三個 QuickSight 儀表板（標籤覆蓋率、各團隊服務成本、浪費獵捕）。舉行首次浪費獵捕例會。為前二十項閒置資源發現（未關聯的 Elastic IP、舊 AMI、已停止執行個體、已分離磁碟區、閒置 Load Balancer）建立工單。交付項目：第一週節省 $10K 至 $20K，與每個團隊進行首次有資料支撐的成本對話。

第 5-6 週 — 速效遷移。 執行全環境 EBS gp2 → gp3 遷移。執行 t2 → t3a 遷移。兩者均為原地、低風險、無需回滾。交付項目：每月節省 $5K 至 $15K，零生產影響，高度團隊認同。

第 7-8 週 — Savings Plans 第一輪。 以三十天回顧期執行 Savings Plans 建議引擎。購買一年期無預付 Compute Savings Plan，規模定在目前基準的 60% 至 70%（刻意保守）。交付項目：計畫中最大的單一行節省，每月 $15K 至 $25K。

第 9-10 週 — S3 生命週期與 NAT 削減。 透過儲存桶預設值將 S3 Intelligent-Tiering 設為所有新物件的預設儲存類別。對日誌、備份和未完成多部分上傳套用生命週期規則。將 VPC Gateway Endpoints 新增至每個生產 VPC 的 S3 和 DynamoDB。將 VPC Interface Endpoints 新增至兩個流量最高 VPC 的 ECR、Logs、SSM。交付項目：每月節省 $5K 至 $15K。

第 11-12 週 — Graviton 試行與 Spot 試行。 每個團隊識別 3 至 5 個 Graviton 相容工作負載並試行遷移。識別 2 至 4 個無狀態工作者層，透過混合執行個體 ASG 試行 Spot。交付項目：已驗證的遷移操作手冊，試行節省每月 $2K 至 $5K，第二季推廣準備就緒。

十二週結束時，一個典型的年支出 $2M、二十帳號環境，已將運行費率削減 18% 至 25%（年化 $360K 至 $500K），建立了每週持續挖掘每季 2% 至 4% 額外節省的節奏，並讓每位團隊擁有者始終保持認同，因為每次整改都帶著資料、具名擁有者和兩週截止日，而非突如其來的驚嚇。

情境：在不引發團隊反彈的情況下整合二十帳號年花費 $2M 的 AWS 支出

以標準 SAP-C02 情境整合完整的大局觀。某公司在單一 AWS Organization 下運行二十個 AWS 帳號，包含共享服務帳號和帳單帳號。年度 AWS 支出為 $2M。CFO 要求解決方案架構師在六個月內將支出降低 20%，且不降低服務品質；工程副總裁則明確警告，之前的集中式降成本行動損害了團隊士氣，並產生了短暫的一次性節省而非持久的文化轉變。

第一個月 — 可觀測性與速效成果。 架構師啟用 AWS Cost and Usage Report、AWS Compute Optimizer、AWS Trusted Advisor Enterprise 和 Amazon S3 Storage Lens 進階指標。架構師建立三個 QuickSight 儀表板，舉行首次浪費獵捕例會。例會產出跨二十帳號的四十二張工單。月底前，四十二張中的三十五張已關閉，閒置資源清除每月回收 $28K，每個團隊首次看到了依服務分解的自身支出。

第二個月 — 機群遷移。 架構師對 180 TB EBS 執行 gp2 → gp3（每月節省 $4K），對 400 台執行個體執行 t2 → t3a（每月節省 $3K）。兩次遷移均為零停機，提前一週告知各團隊，並承諾如有問題可回滾。無回滾請求。

第三個月 — Savings Plans 與 S3 生命週期。 基於六十天的觀察基準，架構師購買一年期無預付 Compute Savings Plan，大小為基準的 65%，每月節省 $22K。S3 Intelligent-Tiering 啟用為所有新物件的預設儲存類別。日誌儲存桶和備份儲存桶推行生命週期規則，每月節省 $6K。

第四個月 — NAT 削減。 架構師對所有 15 個生產 VPC 新增 S3 和 DynamoDB 的 VPC Gateway Endpoints（每月節省 $5K 資料處理費）。VPC Interface Endpoints 新增至 NAT 資料量最高的三個 VPC 的 ECR、Logs 和 SSM（額外每月節省 $4K）。

第五個月 — Graviton 試行。 三個 Java 微服務和兩個 Python ML 服務層試行從 m5 遷移至 m6g。效能相當或更好；成本降低 20%。操作手冊發布後，十二個額外服務承諾在第六個月遷移。

第六個月 — Spot 試行與組合審查。 兩條批次 ETL 流水線和一組 CI/CD 執行器機群透過混合執行個體 ASG 遷移至 Spot。中斷率 3%，SLO 維持。購買第二批 Savings Plans，覆蓋五個月期間識別出的淨新穩定工作負載。

半年結果。 運行費率從 $2M/年降至 $1.56M/年——削減 22%。每位團隊擁有者每週參與。無團隊被公開點名。每項最佳化都有已記錄的擁有者、工單和結果。FinOps 儀表板已成為每位工程總監週一早上的預設起始頁。計畫既產出了絕對的節省，也培育了持續節省的組織能力——這才是 SAP-C02 考試真正在測試的答案。

SAP-C02 現有工作負載成本最佳化的常見陷阱

本主題在 SAP-C02 出現頻率最高的五個陷阱：

陷阱 1 — 未執行覆蓋率報告就購買 Savings Plans。 正確的第一步永遠是稽核。在第一週就購買承諾的答案是錯的。

陷阱 2 — 對有狀態工作負載建議 Spot。 Spot 僅適用於無狀態、水平可擴展、可重跑的工作負載。對 RDS、Elasticsearch 主節點或有狀態的單例使用 Spot，永遠是錯的。

陷阱 3 — 對小於 128 KB 的物件選擇 S3 Intelligent-Tiering。 監控費用超過節省。正確答案是彙整或使用轉至 S3 Standard-IA 的生命週期規則。

陷阱 4 — 建議使用單一 NAT Gateway 節省成本。 跨 AZ 資料傳輸費用在任何非微量流量下都超過 NAT 節省。正確答案是每 AZ 一個 NAT，搭配 VPC endpoints 減少流量。

陷阱 5 — 建議「取消並重新購買」Savings Plan。 Savings Plans 不可撤銷。正確答案是驅動更多合格工作負載消耗承諾，或接受過度承諾作為安全邊際的代價。

對比 AWS Cost Anomaly Detection 和 AWS Budgets

AWS Cost Anomaly Detection 使用機器學習識別帳號、服務或標籤層級的異常支出模式，並透過 SNS/電子郵件發出警報。它是一個偵測工具，不是最佳化工具——在異常發生後才浮出。AWS Budgets 是一個閾值工具——當實際或預測支出超過設定閾值時觸發警報。兩者都無法取代上述的稽核與整改工作流程；兩者都是互補的護欄，屬於可觀測性層，與 CUR + QuickSight 並列。

考試訊號：SAP-C02 需要熟記的內容

在 SAP-C02 中，現有工作負載的成本最佳化每次考試約出現 8 至 12 題。考試測試的具體訊號：五步稽核流水線（CUR → S3 → Glue → Athena → QuickSight）；Compute Optimizer 記憶體盲點（需要 CloudWatch 代理程式）；Savings Plans 不可撤銷規則；Spot 合格規則（僅限無狀態、水平擴展、可重跑）；S3 Intelligent-Tiering 128 KB 門檻；NAT 每 AZ 規則搭配 VPC endpoints；Convertible vs Standard RI 交換規則；以及排序規則（觀察 → 分段 → 試行 → 擴展 → 執行）。熟記這八個訊號，你就能在大多數 Task 3.5 考題中，讀完兩遍就認出正確答案。

FAQ：現有 AWS 工作負載的成本最佳化

Q1. 對於成本分配標籤覆蓋率僅達 40% 的二十帳號 AWS Organization，最快達到成本回沖就緒資料的路徑是什麼？

正確順序是：(1) 啟用含資源 ID 和所有使用者定義標籤的 AWS Cost and Usage Report；(2) 透過將 CUR 與標籤要求清單合併，建立 QuickSight 標籤覆蓋率儀表板；(3) 套用 AWS Organizations 標籤政策，定義允許的標籤鍵和值格式，並在 AWS Config 中呈現不合規情況；(4) 透過 Service Control Policies 使用 aws:RequestTag 和 aws:TagKeys 條件鍵，在資源建立時強制執行標籤；(5) 透過 AWS Resource Groups Tagging API 和 AWS Config 自動修復，對現有資源進行追溯標籤。標籤政策本身不強制執行標籤——它們只報告合規情況；SCP 加上 Config 自動修復組合，才是將覆蓋率從 40% 提升至 95% 的實際機制。

Q2. CUR 查詢顯示 15 個 VPC 的 NAT Gateway 資料處理費用每月達 $50K。哪種整改方式的 ROI 最高？

ROI 最高的整改是對每個 VPC 新增 VPC Gateway Endpoints for Amazon S3 和 Amazon DynamoDB——gateway endpoints 免費（無每小時費用、無每 GB 費用），對典型工作負載而言，40% 至 70% 的 NAT 資料處理量是 S3 或 DynamoDB 流量。步驟二是新增 VPC Interface Endpoints for Amazon ECR、Amazon CloudWatch Logs、AWS Systems Manager 和 AWS KMS——每 AZ 每 endpoint $0.01/小時，但每月超過 2 GB 的服務都能省下 NAT 的 $0.045/GB 費用，立即回本。步驟三是將面向公眾的出口移至 Amazon CloudFront。生產環境中不要減少 NAT Gateway 數量——跨 AZ 資料傳輸費用超過 NAT 節省。

Q3. 200 台 EC2 執行個體全天候以平均 8% CPU 運行。正確的成本最佳化順序是什麼？

正確順序是：(1) 確認 Compute Optimizer 已有十四天的指標資料，且已安裝 CloudWatch 代理程式以提供記憶體可見度；(2) 依照 Compute Optimizer 建議對每台執行個體進行右調整（通常縮小 40% 至 60%）；(3) 評估工作負載是否依排程運行——若全天候運行並非業務要求，新增 Instance Scheduler 或 AWS Systems Manager 自動化，在夜間和週末停止執行個體（節省 65% 至 75% 的運行時間）；(4) 只有在完成右調整和排程之後，才購買規模對應最佳化後基準的 Savings Plan。先購買 Savings Plan 會鎖定過度配置的基準，浪費承諾。

Q4. 某團隊拒絕 Compute Optimizer 將 r5.4xlarge 縮小至 m6g.large 的建議，因為他們的應用程式需要大量記憶體。架構師應如何回應？

最可能的根本原因是執行個體上未安裝 CloudWatch 代理程式，因此 Compute Optimizer 只能看到 CPU 和網路指標，並基於此做出建議。正確回應是：(1) 透過 AWS Systems Manager State Manager 部署 CloudWatch 代理程式，以發布 mem_used_percent；(2) 等待十四天讓 Compute Optimizer 攝取記憶體資料；(3) 重新評估建議。若在攝取記憶體資料後 Compute Optimizer 仍建議縮小，則團隊的顧慮沒有依據。若建議改變（例如改為 r6g.xlarge），則原始建議是基於不完整的資料。絕不強制推翻團隊的反對意見——收集資料，讓資料決定。

Q5. 三年期 Savings Plan 在六個月後被發現過度承諾。覆蓋率 100% 但使用率只有 70%。有哪些可用的整改方式？

AWS Savings Plans 不可撤銷，無法取消、退款或縮減規模。可用的整改方式是：(1) 驅動更多合格工作負載至付款帳號——將現有 On-Demand EC2、Fargate 或 Lambda 工作負載從覆蓋豁免模式遷移至覆蓋帳號，使承諾被消耗；(2) 暫停新的 Savings Plans 採購，直到現有承諾被充分使用；(3) 對預測進行事後分析——過度承諾幾乎總是因為工作負載下線、遷移至 EC2 Instance Savings Plan 未覆蓋的地區，或 Graviton 遷移破壞了系列鎖定的 EC2 Instance Savings Plan。往後，新承諾上限設在觀察基準的 70% 至 80% 而非 100%，並在異質環境中優先選擇 Compute Savings Plans（地區和系列彈性）而非 EC2 Instance Savings Plans（系列鎖定）。

Q6. 對於在 Amazon S3 Standard 中有二十億個平均大小為 8 KB 物件的工作負載，S3 Intelligent-Tiering 是正確的成本最佳化方式嗎？

不是。S3 Intelligent-Tiering 有每月每千物件 $0.0025 的監控和自動化費用。對於二十億個物件，這單是監控費用就達每月 $5000，超過小於 128 KB 物件的儲存節省（這些物件無論存取模式如何都以頻繁存取費率計費，因為它們無法被降級）。正確的最佳化方式是：(1) 彙整小物件——用 1 MB Parquet 檔案取代個別 8 KB JSON 記錄——這也能改善下游 Amazon Athena 的查詢效能；(2) 對不常存取的小物件使用帶有生命週期規則的 S3 Standard-IA；(3) 對不符合 S3 Standard 成本模型的小物件熱存取工作負載，考慮 Amazon DynamoDB 或 Amazon S3 Express One Zone。

Q7. 哪個 AWS 服務是跨二十個連結帳號檢視組織層級閒置資源發現的正確工具？

AWS Trusted Advisor 在 Business 或 Enterprise Support 等級是廣度工具——跨所有連結帳號的彙整組織層級發現，在管理帳號或委派管理員處呈現。AWS Compute Optimizer 在組織 opt-in 層級，跨連結帳號提供 EC2/ASG/EBS/Lambda/Fargate 的右調整建議。AWS Cost Explorer 的右調整建議是按帳號計算的，且是 Compute Optimizer 資料的子集。對於閒置資源發現（未關聯的 Elastic IP、閒置 Load Balancer、未充分使用的 EC2、已分離磁碟區），主要工具是 Trusted Advisor；對於右調整和世代遷移建議，主要工具是 Compute Optimizer。兩者都匯入浪費獵捕 QuickSight 儀表板，用於每週節奏。