新專案的成本架構設計

新解決方案成本設計是 SAP-C02 的核心學科——在架構第一天就把成本最佳化內建進去，而不是等帳單暴衝後才亡羊補牢。AWS Certified Solutions Architect Professional 考試指南 Domain 2.6 要求你能針對特定解決方案目標，制定成本最佳化策略。在實務上，Professional 等級的架構師必須在白板前同時權衡：Savings Plans 組合建構、Reserved Instance 大小彈性、Spot 模式庫、Graviton 遷移路徑、Serverless 成本信封、資料傳輸陷阱、組織層級標籤，以及機器學習驅動的異常偵測——而這一切都要在第一行 Terraform 寫出之前完成。本筆記以「VP of Engineering 丟給你一張每月 50 萬美元的雲端帳單，要求你在一季內降低 30% 且不裁減功能」作為貫穿全文的情境。讀完本筆記，你將清楚知道該買哪種承諾、換掉哪種運算、加上哪個端點，以及部署哪個異常監控。

什麼是 AWS 新解決方案成本設計？

新解決方案成本設計，是將成本視為每個全新 AWS 工作負載中第一級非功能需求的架構實踐。Phase 1 是 Well-Architected Cost Optimization Pillar 應用於空白畫布；Phase 2 是 SAP-C02 考試測驗你能否在同一個 4 分鐘題目視窗內，同時推理 Savings Plans 對比 Reserved Instances、Spot 對比 On-Demand、Fargate 對比 EC2、Lambda 對比長時間執行的運算、CloudFront 對比直連來源，以及 VPC endpoints 對比 NAT Gateway。新解決方案成本設計在 SAP-C02 從來不是「哪個服務最便宜」的孤立問題——而是「給定這個工作負載形狀、這條成長曲線，以及這個風險承受度，哪種定價模型、執行個體家族、網路基元與儲存層的組合，在不犧牲既定 SLO 的前提下，產生最低的總持有成本」。

為什麼新解決方案成本設計在 SAP-C02 如此重要

近期 SAP-C02 考生的社群數據顯示，成本設計情境大量出現在 Domain 2（新解決方案，29%）和 Domain 3（持續改善，25%）。考試幾乎不會要求你背誦價格；它要求你將工作負載模式（爆量型、可預測型、可中斷型、延遲敏感型、資料密集型）對應到正確的成本基元。因此，Professional 等級的新解決方案成本設計是決策矩陣的學科，而不是計算機的學科。

白話文解釋 New Solutions Cost Design

新解決方案成本設計聽起來很抽象，因為它同時混合了十幾種定價模型。以下用四個不同領域的台灣日常類比，讓整張圖一次看懂。

類比一：手搖飲連鎖店的人力排班

想像你要開一家手搖飲連鎖店，每天要服務早上開店人潮、午休峰值、晚間客流，以及週末限定的排隊盛況。On-Demand EC2 是向人力派遣公司按小時雇用打工仔——無限彈性，但時薪最貴。Compute Savings Plans 是和一批能做所有飲品的正職員工簽一年或三年合約——你承諾每週支付他們固定薪資，無論門市是否滿客，換取的是時薪降低 30 到 40%。EC2 Instance Savings Plans 是專門聘用一位珍珠奶茶達人——比通才合約便宜，但若之後轉型主打果汁，這份合約就白花了。Spot Instances 是附近餐飲學校的實習生，在人潮多時以極低時薪來幫忙，但學校隨時可以把他們叫回去開課（兩分鐘通知）。Fargate Spot 是同樣便宜的臨時幫手，但由派遣公司負責行政作業。Lambda 是外賣平台的計件外送員——沒訂單就沒費用，若你的門市只在特定時段開放，這個模式最划算。新解決方案成本設計，就是老闆在開店第零天坐下來，看著預估出杯量和菜單，決定組合：要雇多少正職、多少通才合約、多少專才合約、多少計時打工。能算對這個比例的店才活得下去；全雇正職的店在淡季燒錢；全用派遣的店在旺季付雙倍。

類比二：夜市攤位的月結帳策略

你在夜市有一排攤位，各攤賣不同小吃。月底夜市管理方提供幾種租金方案。On-Demand 是按日繳租，想退攤隨時退但日租最貴。一年期 Compute Savings Plan 是跟夜市管委會簽整排攤位的年約，不管你哪個攤位賣什麼、哪個月淡旺，月租打七折；如果某個攤位收攤，折扣可以轉給另一個攤位使用。三年期合約折扣更深但鎖更久。EC2 Instance Savings Plan 是鎖定特定攤位類型（例如炸物區）的年約——便宜，但如果之後想轉去飲料區就沒用了。Reserved Instance 是你把某個固定攤位租下來，大小彈性意指你可以把一個大攤位的租約，等比例拆分給幾個小攤位使用。Spot 是夜市管理方每晚把臨時空位以超低價標給你，但保留隨時收回的權利。新解決方案成本設計，就是在簽約前先估算：哪幾個攤位的客流是穩定可預測的（買 Savings Plans）、哪些只在特定季節出現（留 On-Demand 或 Spot）、手頭現金夠不夠預付整年租金換取更大折扣。

類比三：電力公司的發電組合

電力公司要對城市供電。基載需求——城市全天候二十四小時都需要的電力——由核電或燃煤電廠供應，每度電成本低，但需要多年建設承諾。中間負載由天然氣聯合循環電廠供應——比尖峰電廠便宜、比基載電廠靈活。尖峰需求（颱風前冷氣全開）由快速啟動的調峰電廠供應，每度電成本是平時的十倍，但能在幾分鐘內上線。Spot 庫存是電網風力過剩時以極低價釋出的綠電。新解決方案成本設計是電力規劃師決定：要承諾多少基載（三年 Savings Plans 覆蓋工作負載底部）、多少中間負載（一年 Savings Plans）、多少調峰容量（On-Demand 搭配 Auto Scaling），以及多少機會性電力（Spot 跑批次工作）。只建調峰電廠的電力公司讓居民付高電費；只建基載電廠的電力公司無法應付颱風季；正確的組合是工程判斷加上需求預測加上每一層的定價模型。

類比四：捷運系統對比叫車 App

城市交通局需要疏運通勤族。捷運是類 Serverless 的固定成本服務：龐大前期資本投入（基礎設施），之後每位乘客成本極低，且在設計容量內彈性擴充。叫車 App 是 On-Demand EC2：零承諾、無限彈性，但每公里貴。公車路線是 Savings Plans：固定班表、無論滿不滿都要發車。新解決方案成本設計是模擬通勤模式：若 90% 的行程沿著固定走廊在可預測時間發生，就建捷運；若使用量是爆量且難以預測的，就保留叫車 App；若特定路線有穩定但適中的需求，就開公車。以正確比例混搭三者，是交通規劃師的藝術，也是 AWS 架構師的藝術。

將這四個心智模型——手搖飲連鎖店、夜市攤位、電力公司、捷運系統——放在腦海中，每一道 SAP-C02 新解決方案成本設計題目都會變成比例決策，而不是死記硬背問題。

新解決方案成本設計參考架構

每個嚴肅的 AWS 新解決方案成本設計，都在全新的 landing zone 之上疊加八個能力層。把它想成一個成本堆疊。

第 0 層 — AWS Organizations 與標籤基礎

沒有這一層，其他一切在規模化後都無從量測。啟用所有功能的 AWS Organizations、根層級的標籤政策，以及在 payer 帳號啟用成本分配標籤，是所有後續層得以運作的基底。

第 1 層 — 承諾組合：Savings Plans 和 Reserved Instances

新解決方案的可預測基線，由 Compute Savings Plans 加上薄薄一層 EC2 Instance Savings Plans 和少量針對特定家族的 Reserved Instances 來覆蓋。這是新解決方案成本設計的基礎。

第 2 層 — 機會性容量：Spot 模式

在承諾底板之上，可中斷工作負載透過 Spot、Fargate Spot，以及 Karpenter 管理的 Spot 節點執行，並跨越執行個體家族、大小和可用區做分散化。

第 3 層 — 運算底盤：Graviton 優先

全新程式碼的新解決方案成本設計，預設選擇 Graviton（ARM64）作為執行個體家族，只有在工作負載有強依賴時才退回 Intel 或 AMD。

第 4 層 — 數學可行時選擇 Serverless

Lambda、Fargate、Step Functions Express、API Gateway HTTP、EventBridge，以及 DynamoDB On-Demand，在請求密度適合按請求計費的地方取代長時間執行的 EC2。

第 5 層 — 資料傳輸消除

VPC endpoints、CloudFront、Origin Shield、Transit Gateway 對比 VPC Peering 的成本交叉點，以及 PrivateLink，是新解決方案成本設計中消除隱性資料傳輸稅的槓桿。

第 6 層 — 儲存層智慧

S3 Intelligent-Tiering 作為預設、已知存取模式使用生命週期規則、EBS gp3 作為預設區塊儲存、EFS Intelligent-Tiering 用於檔案工作負載。

第 7 層 — 回饋迴路：Compute Optimizer、Cost Anomaly Detection、Storage Lens

持續的右調整建議、基於 ML 的異常警示，以及組織層級的 S3 分析，將從設計到運營的迴路閉合。

新解決方案成本設計的 Savings Plans 組合

Savings Plans 是 Professional 等級架構師手上最大的單一槓桿。新解決方案成本設計在第一個生產執行個體啟動前就決定好承諾組合。

Compute Savings Plans 對比 EC2 Instance Savings Plans

Compute Savings Plans 適用於 EC2，無論家族、區域、大小、租用模式或作業系統，也適用於 AWS Fargate 和 AWS Lambda。彈性最大；折扣最高可達 On-Demand 的 66%。EC2 Instance Savings Plans 只適用於特定區域的特定執行個體家族（例如 us-east-1 的 m6i），可跨該家族和區域內的大小及可用區。彈性較低；折扣最高可達 On-Demand 的 72%。

新解決方案成本設計組合原則

在 payer 帳號層級購買 Compute Savings Plan 覆蓋全組織可預測基線，讓折扣能流向任何成員帳號和任何運算服務。對特定高流量、穩定的工作負載——例如你知道會持續執行在特定家族的 Graviton m7g 網頁伺服器叢集——在擁有該叢集的帳號中，用 EC2 Instance Savings Plan 捕捉額外六個百分點的折扣。將 Reserved Instances 保留給 Savings Plans 未涵蓋的邊緣案例，例如帶自帶授權（BYOL）SQL Server 的 Windows。

一年對比三年決策矩陣

新解決方案成本設計經驗法則：三年期承諾用於你絕對確定三年內仍在 AWS 上的工作負載層（核心服務、資料平台）；一年期用於架構可能演化的服務（實驗性 ML、新產品線）；剩餘部分留給 On-Demand 或 Spot 不覆蓋。

無預付對比全額預付決策矩陣

三年期 Compute Savings Plan 的無預付和全額預付之間，可相差 4 到 6 個百分點的額外折扣——在每月 50 萬美元的帳單上，這是顯著的金額。

跨帳號的 Reserved Instance 策略

即便有 Savings Plans 可用，Reserved Instances 在三種情況下仍有意義：RDS、ElastiCache、Redshift 和 OpenSearch（Savings Plans 不適用）、Windows BYOL 情境，以及有 Savings Plans 之前舊承諾的組織。

區域性 RI 的大小彈性群組

區域性 Reserved Instance 在同一執行個體家族、Linux/Unix、預設租用模式下跨大小適用。AWS 以「正規化單位」計算每個大小：nano=0.25、micro=0.5、small=1、medium=2、large=4、xlarge=8、2xlarge=16、4xlarge=32、8xlarge=64、16xlarge=128。一個 m5.4xlarge 區域性 RI 可覆蓋四個 m5.xlarge 執行個體、或兩個 m5.2xlarge、或八個 m5.large——只要該區域、該家族內的組合加起來等於 32 個正規化單位即可。

RI 交換對比取消決策矩陣

新解決方案成本設計的 RI 原則

在全新建置上，EC2 預設選擇 Compute Savings Plans。只有 Savings Plans 不適用的 RDS、ElastiCache、Redshift 和 OpenSearch，才買 Convertible RI。在新解決方案上絕不買 Standard RI，除非你對三年後的執行個體家族有絕對把握——而依定義，新解決方案幾乎不可能有這種確定性。

Professional 深度的 Spot 模式庫

Spot Instances 提供最高達 On-Demand 90% 的折扣，換取 AWS 以兩分鐘通知收回容量的權利。新解決方案成本設計將 Spot 視為一個模式庫，而非單一基元。

模式一 — 採用 Capacity-Optimized 配置策略的 ASG MixedInstancesPolicy

Auto Scaling Groups 支援混合執行個體政策，讓你指定多種執行個體類型、多種購買選項（On-Demand 加 Spot），以及配置策略。Spot 的建議策略是 capacity-optimized，它會選擇可用容量最深的 Spot 池（最低中斷機率），而非 lowest-price（最便宜的池，中斷率較高）。

典型的無狀態 Web 層新解決方案成本設計：

• 執行個體家族：m6i.large、m6a.large、m5.large、m5a.large、m6g.large、m7g.large（跨 Intel、AMD、Graviton 分散化）
• On-Demand 基礎：20%（以保證容量覆蓋工作負載底板）
• Spot 比例：80%，以 capacity-optimized 配置跨六個池
• 結果：相較全 On-Demand 約 60 到 75% 的有效折扣，各池中斷率低於 5%

模式二 — 帶 InstanceRequirements 的 EC2 Spot Fleet

Spot Fleet 是較舊的 API；對於全新建置的新解決方案成本設計，優先使用帶 InstanceRequirements（屬性型執行個體選擇）的 ASG。你宣告「給我 4 到 8 個 vCPU、16 到 32 GB RAM、ARM 或 x86、任何比當前世代早兩代以內的執行個體」，ASG 就會從每個可用區中每個符合條件的池中選擇，大幅擴展 Spot 分散化範圍。

模式三 — 容器化批次工作使用 Fargate Spot

Fargate Spot 是 ECS 的容量提供者，以約 70% 折扣在可中斷的 Fargate 容量上執行任務。搭配 Fargate On-Demand 基礎容量提供者和權重設定：FARGATE 權重 1，基礎 2 個任務；FARGATE_SPOT 權重 3，基礎 0。這樣前兩個任務保證執行，之後每五個任務中的三個使用 Spot 擴充。

模式四 — EKS 使用 Karpenter Spot

Karpenter 是 EKS 的開源即時節點配置器，取代 Cluster Autoscaler 和受管節點群組。單一 Karpenter NodePool 可指定 spot 容量類型、一組執行個體家族和大小（或 InstanceRequirements），Karpenter 透過高效的 Pod 裝箱並替換低利用率節點來整合工作負載。中斷處理透過 SQS + EventBridge 與 EC2 Spot 中斷通知的整合內建支援。

模式五 — 長時間執行 Spot 工作的檢查點機制

對於機器學習訓練、視訊編碼、科學運算——執行數小時的工作——新解決方案成本設計每 N 分鐘在應用程式層級將狀態儲存到 S3。收到 Spot 中斷通知時，工作負載將狀態刷新到 S3，替換執行個體啟動時取回狀態，工作繼續執行。帶 Spot 和受管運算環境的 AWS Batch 為你處理這些；SageMaker Training Jobs 原生支援帶檢查點的受管 Spot。

新解決方案成本設計的 Graviton 遷移計畫

AWS Graviton 處理器（ARM64）在廣泛的工作負載上，相較同等 x86 執行個體提供高達 40% 的更佳性價比。新解決方案成本設計預設選擇 Graviton，除非存在硬性阻礙。

Graviton 遷移瀑布流

1. 受管服務 — Aurora、RDS、ElastiCache、OpenSearch、MemoryDB、MSK 皆支援 Graviton，只需更改執行個體類別的一個參數。零程式碼變更。
2. Serverless — Lambda arm64 架構、帶 ARM 的 Fargate 平台版本。在函數設定或任務定義中改一行。
3. 容器工作負載 — ECS 和 EKS 在 Graviton 節點上執行。需要多架構容器映像（docker buildx 產生 linux/amd64,linux/arm64 manifest）。
4. EC2 應用層 — 直譯語言（Node.js、Python、Java、Go、.NET 6+）通常可直接遷移；需確認原生相依套件。
5. 帶原生相依套件的 EC2 — 編譯後的 C/C++ 函式庫、專有代理程式、BYOL 軟體：需謹慎測試，最後才遷移。

Graviton 與 Savings Plan 的交互作用

Compute Savings Plans 對 Graviton 的適用方式與 Intel 和 AMD 相同。在 m7g 家族上的 EC2 Instance Savings Plan，與 Graviton 固有的性價比優勢疊加，使節省效果倍增。

新解決方案成本設計原則

每個新工作負載從 Graviton 開始。只有在特定原生相依套件測試失敗時才退回 x86。光是這一點，就是全新建置上可用的最大單一運算成本降低措施。

Professional 深度的 Serverless 成本模式

Serverless 不是自動更便宜——它在請求模式是爆量型、閒置期長或流量難以預測時才更便宜。新解決方案成本設計策略性地使用 Serverless。

模式一 — Lambda Power Tuning

Lambda 按 GB 秒計費（記憶體 × 執行時間）。反直覺的是，增加記憶體往往能降低總成本，因為 CPU 隨記憶體擴充，函數完成得更快。開源的 AWS Lambda Power Tuning 工具以 128 MB 到 10,240 MB 的記憶體值執行函數，繪製成本和延遲對記憶體的圖表，找出最佳點。一個 CPU 密集函數從 512 MB 調到 1,792 MB，可以同時降低 40% 成本和 60% 延遲。

模式二 — Step Functions Express 對比 Standard

新解決方案成本設計選擇 Express 用於高吞吐量的短期微服務協調（API Gateway 後端、IoT 資料處理），選擇 Standard 用於有人工審批、法律留存或財務對帳的長時間工作流程。

模式三 — EventBridge 規則成本

EventBridge 按發布到自訂匯流排的每百萬事件計費（預設 AWS 服務匯流排事件和部分目標不收費）。在規模化時，一個每月產生十億事件的喋喋不休微服務，光 EventBridge 就要花費約 1,000 美元。新解決方案成本設計在規則層級使用內容過濾（而非在 Lambda 收到後才過濾），避免不必要地觸發下游目標，並使用帶有內建過濾和豐富化的 Pipes 來整合以 Lambda 為基礎的連接器程式。

模式四 — API Gateway HTTP API 對比 REST API

HTTP API 在同等請求量下比 REST API 便宜約 70%，且支援大多數常見模式（Lambda proxy、JWT 授權器、CORS）。新解決方案成本設計預設使用 HTTP API，只有在需要 API keys 搭配使用計畫、請求驗證器或 WAF 原生整合等功能時才退回 REST API。

模式五 — DynamoDB On-Demand 對比 Provisioned

On-Demand 按請求計費（在 us-east-1 約每百萬寫入請求 $1.25、每百萬讀取請求 $0.25）。穩定利用率超過約 18% 時，Provisioned 較便宜。新解決方案成本設計在前幾個月存取模式未知時，讓新資料表從 On-Demand 開始，等利用率曲線穩定後再切換到帶有自動擴展的 Provisioned。

模式六 — S3 Intelligent-Tiering 作為預設

S3 Intelligent-Tiering 根據觀察到的存取情況，在存取層（Frequent、Infrequent、Archive Instant、Archive、Deep Archive）之間移動物件。每月每千個物件有小額監控費，但 Instant 層不收取取回費。新解決方案成本設計預設將每個新儲存桶設為 Intelligent-Tiering，除非存取模式已知（例如寫入一次永不讀取的日誌，應透過生命週期規則直接送往 Standard-IA + Glacier Deep Archive）。

資料傳輸減少模式

資料傳輸是 AWS 帳單的隱形殺手。NAT Gateway 處理費用、跨可用區複製，以及對外傳輸到網際網路，這些費用疊加成讓人驚訝的帳單項目。

模式一 — S3 和 DynamoDB 的 VPC Gateway Endpoints

Gateway endpoints 是免費的，讓 S3 和 DynamoDB 的流量在 AWS 網路內部路由，不必通過 NAT Gateway。一個每月透過 NAT 處理 100 TB S3 流量的 VPC，光是 NAT Gateway 資料處理費用就可能超過每月 4,500 美元。在路由表中加入 gateway endpoint，可將此費用降為零。

模式二 — AWS Service API 的 VPC Interface Endpoints

Interface endpoints（PrivateLink）將 AWS 服務 API（SSM、Secrets Manager、ECR、STS、KMS、SQS、SNS 等）以私有 ENI 的形式暴露在你的 VPC 內部。每個可用區每小時 ENI 費用約 $0.01，加上每 GB 處理費。對於高流量服務（如 ECR 容器映像拉取）或 CloudWatch Logs，interface endpoints 在成本和延遲上都優於 NAT Gateway。

模式三 — CloudFront Origin Shield

Origin Shield 是 CloudFront 區域邊緣快取和你的來源之間的額外快取層。它透過將所有區域邊緣的請求整合到每個來源的一或兩個 shield POP，提高來源的快取命中率。對於每月從 S3 透過 CloudFront 傳出 100 TB 的視訊串流工作負載，啟用 Origin Shield 可將來源傳出量減少 30 到 50%，而 Origin Shield 的請求費用相對較小，整體仍有正面效益。

模式四 — Transit Gateway 對比 VPC Peering 的成本交叉點

VPC Peering 連線本身免費（只有跨可用區資料傳輸成本）。Transit Gateway 按每小時每個連接（約 $0.05）加上每 GB 處理（$0.02）計費。VPC 數量少時 Peering 較便宜；規模化時 TGW 的運營簡便性更優。交叉點取決於每個連接的流量量：

• 不到約 5 個 VPC 時，Peering 通常較便宜
• 10 個以上 VPC 時，TGW 的 N 連接模型在運營上優於 N 平方的 Peering
• 若大量流量跨越超過 2 個 VPC（如共享服務模式），TGW 的集中化避免了 Peering 的迂迴成本

新解決方案成本設計對小型穩定配對（例如開發和生產）使用 Peering，其餘一律使用 TGW。

模式五 — 私有 SaaS 和第三方服務使用 PrivateLink

私下使用第三方 SaaS 服務（例如某安全廠商的 API）時，PrivateLink 避免了消費方的網際網路傳出費用，並消除了公開 IP 的暴露面。提供方承擔 NLB 成本；消費方承擔 interface endpoint 的每小時費用加上處理費。與透過 NAT Gateway 路由到公開 API 相比，每個服務每月超過約 200 GB 後，PrivateLink 通常更便宜。

模式六 — 熱路徑使用同區域、同可用區部署

跨可用區資料傳輸每 GB 雙向各 $0.01（來回共 $0.02）。對於同步的喋喋不休微服務配對，使用分區端點並將兩端放在同一可用區，可消除此費用。對於用作唯讀的 RDS 副本，將讀取副本保留在與主要消費層相同的可用區，可將持續的複製讀取成本減半。新解決方案成本設計將可用區配置視為成本維度，而不僅僅是可靠性維度。

規模化的標籤政策與成本分配

沒有標籤，歸因就沒有意義。新解決方案成本設計在第一個資源部署之前就寫好標籤政策。

強制標籤綱要

• CostCenter — 財務歸因（例如 CC-Retail-100）
• Project — 產品或計畫（例如 checkout-v3）
• Environment — prod、staging、dev、sandbox
• Owner — 團隊電子郵件或群組（例如 platform@example.com）
• DataClassification — public、internal、confidential、restricted
• ManagedBy — terraform、cdk、console、cloudformation

強制執行層

1. AWS Organizations 根層級的標籤政策定義綱要和允許值。
2. SCP 在 aws:RequestTag/CostCenter 缺失或不在核准清單中時，拒絕 RunInstances、CreateBucket、CreateFunction 等操作。
3. Terraform / CDK 模組從共享函式庫自動套用標籤，讓開發者無需手動操作即可繼承。
4. AWS Config 規則 required-tags 標記現有不合規資源以供修正。
5. payer 帳號中的成本分配標籤啟用，讓標籤出現在 Cost Explorer、CUR 和 Budgets 中。

顯示帳和計費設計

新解決方案成本設計預先決定組織採用顯示帳（showback，回報各團隊花費，不做內部開立發票）還是計費（chargeback，內部開立發票，各團隊預算被扣款）。顯示帳使用 Cost Categories 和按標籤過濾的 Cost Explorer。計費使用 AWS Billing Conductor，為各業務單位產生附選擇性內部加成的形式發票。

多帳號新解決方案中的 AWS Compute Optimizer

Compute Optimizer 是免費的 AWS ML 型右調整服務。對於新解決方案成本設計，它在上線後兩週關閉回饋迴路。

在組織層級啟用

從 payer 帳號以 Organizations 登記啟用 Compute Optimizer。這提供跨所有成員帳號的單一視窗：EC2、EBS、Lambda、ECS on Fargate、Auto Scaling groups，以及 RDS（MySQL、PostgreSQL）的建議。

建議類別

• 供應不足 — 工作負載受 CPU 或記憶體限制，建議升級
• 供應過剩 — 利用率低，建議降規
• 已最佳化 — 目前選擇良好
• 未最佳化（有風險） — 建議涉及風險（例如家族變更）——需手動審查

14 天觀察視窗

Compute Optimizer 需要 14 天的 CloudWatch 指標才會發出建議。對於基於記憶體的 EC2 建議，必須安裝 CloudWatch agent（預設不安裝）。因此，新解決方案成本設計將 CloudWatch agent 內建到 AMI 中，或透過 Systems Manager State Manager 以基準設定加入。

執行建議

1. 篩選中或低風險且節省至少 20% 的建議
2. 透過參考的 CloudWatch 指標驗證
3. 在維護視窗期間透過 Systems Manager Automation 套用（修改啟動範本，透過 ASG 輪換執行個體）
4. 30 天後重新確認 SLO 是否維持

新工作負載的 AWS Cost Anomaly Detection

Cost Anomaly Detection 免費，使用機器學習學習每個監控器的基線，然後在統計上顯著的峰值時發出警示。對於新解決方案，監控器集合在第零天就部署好。

新解決方案的標準監控器集合

1. 服務監控器 — 涵蓋帳號中所有 AWS 服務
2. 每個生產成員帳號一個連結帳號監控器
3. 每個主要新工作負載的 Project 標籤成本分配標籤監控器
4. 業務單位類別的 Cost Category 監控器

警示訂閱

警示透過 SNS（搭配 SQS 或 Lambda 扇出）或電子郵件觸發，最低異常閾值由你設定（$100、$1,000、自訂）。新解決方案成本設計將異常警示路由到與服務 SLO 警示相同的值班頻道——成本異常是運營事件。

情境 — 在一季內將每月 50 萬美元帳單降低 30%

VP of Engineering 分享月度帳單：50 萬美元。Cost Explorer 顯示主要項目：EC2（23 萬）、RDS（8.5 萬）、NAT Gateway 處理（4.2 萬）、S3（3.8 萬）、資料傳輸出（3.5 萬）、Lambda（1.8 萬）、其他（5.2 萬）。目標是在一季內減少 30%（15 萬），且不裁減產品功能。

行動一 — 承諾可預測 EC2 的 Savings Plans（預計節省：每月 5.5 萬）

分析 Cost Explorer 對三年期和一年期承諾的 Savings Plans 建議。購買三年期 Compute Savings Plan，以無預付方式覆蓋目前 EC2 基線的 70%（20 萬美元受覆蓋用量的 27% 折扣，每月節省 5.5 萬）。保留 30% 不承諾，為成長和 Spot 遷移留出空間。

行動二 — 將無狀態層遷移到 Spot（預計節省：每月 3 萬）

識別無狀態 Web 和 API 層（Savings Plan 前目前為 On-Demand 10 萬）。將 ASG 重新設定為 MixedInstancesPolicy，六個分散池中 20% On-Demand 基礎和 80% Spot，capacity-optimized 配置。Spot 80% 部分的預期有效折扣約 60%，節省 4.8 萬，扣除 Savings Plan 重疊後淨節省 3 萬。

行動三 — 受管服務 Graviton 遷移（預計節省：每月 1.8 萬）

將 RDS 主要執行個體和副本從 m5 切換到 m7g（Aurora）、ElastiCache 從 r5 切換到 r7g、OpenSearch 從 r5 切換到 r6g。每個服務改一個參數。8.5 萬 RDS + 2 萬快取的約 20% 成本降低 = 節省 2.1 萬，扣除遷移工作後淨節省 1.8 萬。

行動四 — 透過 Endpoints 消除 NAT Gateway 資料處理（預計節省：每月 2.8 萬）

VPC Flow Logs 揭示 NAT Gateway 流量：60% 是 S3、15% 是 DynamoDB、15% 是 ECR 映像拉取、10% 是其他。加入 S3 和 DynamoDB gateway endpoints（免費），加上 ECR、Secrets Manager、SSM、CloudWatch Logs、STS 的 interface endpoints。NAT Gateway 資料處理從 4.2 萬降至約 1.2 萬。Interface endpoint 成本增加約 0.2 萬。淨節省：2.8 萬。

行動五 — CloudFront Origin Shield 降低 S3 傳出（預計節省：每月 1.2 萬）

3.5 萬的資料傳輸出中包含 1.8 萬來自 S3 來源。在公開 S3 儲存桶前啟用帶 Origin Shield（設於 us-east-1）的 CloudFront。公開傳出從 S3 轉移到 CloudFront（超過層級閾值後每 GB 更便宜），Origin Shield 快取整合讓來源傳出降低 40%。淨節省：1.2 萬。

行動六 — Lambda Power Tuning 和 Step Functions Express 遷移（預計節省：每月 0.6 萬）

對每個生產 Lambda 執行 Power Tuning，將記憶體調整到成本最佳點。將短期 Step Functions 工作流程從 Standard 遷移到 Express。Lambda 成本從 1.8 萬降至約 1.2 萬。節省：0.6 萬。

行動七 — S3 Intelligent-Tiering 和生命週期規則（預計節省：每月 0.9 萬）

分析 S3 Storage Lens：60% 的 S3 成本來自 Standard 儲存，這些資料超過 90 天且過去 30 天沒有任何存取。對新前綴套用 Intelligent-Tiering，生命週期規則將 90 天以上的資料移至 Standard-IA，365 天以上移至 Glacier Deep Archive。淨節省：0.9 萬。

預計每月總節省：15.8 萬美元

這是 50 萬美元帳單的 31.6%。這些行動會相互疊加：行動一降低基線，行動二和行動三在此基礎上進一步最佳化；行動四和行動五消除的費用不受承諾影響。這些行動都不需要功能裁減、架構重寫或面向客戶的 SLO 變更。每一項都是 SAP-C02 新解決方案成本設計的答案模式——不是死記的技巧，而是本筆記涵蓋的成本基元的應用。

新解決方案成本設計關鍵數字與必記事實

• Compute Savings Plans 折扣最高約 66%；適用於 EC2、Fargate、Lambda；跨家族、大小、區域、OS、租用模式皆有彈性。
• EC2 Instance Savings Plans 折扣最高約 72%；鎖定特定區域的特定執行個體家族；仍可跨大小和可用區彈性使用。
• 三年期全額預付 Savings Plan 提供最深折扣，約為一年期無預付的兩倍。
• Savings Plans 無法取消或交換 — 採用梯形承諾。
• Convertible RI 可在家族間、大小間、區域間交換；Standard RI 只能在 Marketplace 出售。
• Reserved Instance 大小彈性在家族-區域內使用正規化單位（nano=0.25 ... 16xlarge=128）。
• Spot 折扣最高約 90%；2 分鐘中斷通知；使用 capacity-optimized 配置跨 ≥6 個池。
• Fargate Spot 約比 Fargate On-Demand 便宜 70%。
• Graviton 提供高達 40% 的更佳性價比；新工作負載的預設 CPU。
• Lambda Power Tuning 通常能找到 20 到 40% 的成本降低。
• Step Functions Express 對短期工作流程而言比 Standard 便宜約 95%。
• S3 Intelligent-Tiering 每千個物件有小額監控費；Instant 層不收取取回費。
• NAT Gateway 約每可用區 $0.045/小時 + 約每 GB 處理 $0.045。
• VPC gateway endpoints 用於 S3 和 DynamoDB 是免費的。
• Interface endpoints 約每可用區 ENI-小時 $0.01 + 每 GB 處理費。
• TGW 連接 約 $0.05/小時 + 每 GB 處理 $0.02；VPC Peering 連接免費。
• Compute Optimizer 需要 14 天的指標；記憶體建議需要 CloudWatch agent。
• Cost Anomaly Detection 免費；基於 ML；支援 4 種監控器類型（服務、連結帳號、Cost Category、成本分配標籤）。
• S3 Storage Lens 免費層顯示 14 個指標；進階層顯示 29 個指標，含活動和前綴層級洞察。

SAP-C02 新解決方案成本設計常見陷阱

陷阱一 — 為有狀態或同步工作負載選擇 Spot

Spot 只適合無狀態、冪等、水平可擴展的工作。若情境提到「主要資料庫」、「有嚴格 p99 的客戶端 API」或「單節點有狀態服務」，Spot 是錯誤答案。

陷阱二 — 在全新建置上購買 Standard RI

Standard RI 無法交換。在執行個體家族可能改變的新解決方案上，Convertible RI 或 Savings Plans 才是正確答案。

陷阱三 — 在工作負載可能改變家族時選擇 EC2 Instance SP

EC2 Instance SP 鎖定家族。若情境描述一個演化中的平台（例如「團隊計畫在 6 個月後評估 Graviton」），Compute Savings Plan 才是正確答案。

陷阱四 — 忘記 NAT Gateway 資料處理費用

服務 S3 流量透過 NAT 的 VPC 密集設計會產生驚人費用。正確答案是加入 S3 和 DynamoDB gateway endpoints，以及其他服務的 interface endpoints。

陷阱五 — 對寫入一次永不讀取的日誌使用 S3 Intelligent-Tiering

Intelligent-Tiering 有小額監控費。對於存取模式已知的資料（封存日誌），透過生命週期規則送往 Standard-IA 和 Glacier Deep Archive，比 Intelligent-Tiering 更便宜。

陷阱六 — 在 50 個 VPC 的組織中使用 VPC Peering

Peering 在運營上是 N 平方，且非傳遞性。規模化時，Transit Gateway 是正確答案，儘管有每連接每小時的費用。

陷阱七 — 混淆 Compute Optimizer 和 Cost Anomaly Detection

Compute Optimizer 右調整資源（結構性建議）。Cost Anomaly Detection 警示費用峰值（即時警示）。考試兩者都會問；針對每個情境選對正確的一個。

陷阱八 — 為阻止某個子公司而關閉全組織的承諾共享

這是每成員帳號的切換開關，不是全組織設定。SCP 和 IAM 政策無法更改承諾共享。

陷阱九 — 忘記 Savings Plans 無法取消

考生因為預期有安全閥而承諾不足或過多。採用梯形承諾：三年期覆蓋絕對底板，一年期覆蓋有信心的中間層，On-Demand 覆蓋不確定的頂端。

陷阱十 — 對短期高吞吐量使用 Step Functions Standard

Express 對於規模化時 5 分鐘以內的工作流程便宜 90% 以上。Standard 只有在長時間執行、有人工介入，或確實一次性關鍵的協調情境才是正確答案。

練習題型

1. 「全新無狀態 Web 應用程式，基線 100 個 m5.large，峰值 300 個 m5.large。」→ Compute Savings Plan 覆蓋 100 個執行個體 + MixedInstancesPolicy 搭配 Spot 分散化覆蓋 200 個峰值差額。
2. 「批次 ML 訓練每天執行 6 小時，使用 100 個 GPU 執行個體。」→ 透過 AWS Batch 或 SageMaker Managed Spot 使用 Spot + S3 檢查點。
3. 「新 SaaS 預計 12 個月內成長 10 倍，家族可能改變。」→ Compute Savings Plan（家族靈活）+ 受管服務使用 Convertible RI。
4. 「VPC 每月透過 NAT Gateway 處理 200 TB S3 流量。」→ S3 Gateway Endpoint（免費，解決問題）。
5. 「面向公眾的視訊平台，S3 來源，每月 500 TB 傳出。」→ 以 S3 為來源的 CloudFront + Origin Shield。
6. 「新 Lambda 函數，團隊不確定最佳記憶體。」→ Lambda Power Tuning。
7. 「高吞吐量微服務協調，平均執行時間 1 秒以下，每天 1,000 萬次執行。」→ Step Functions Express。
8. 「新 S3 儲存桶，存取模式未知。」→ 預設 Intelligent-Tiering。
9. 「財務部門想要每個業務單位異常費用峰值的警示。」→ 帶 Cost Category 或標籤監控器的 Cost Anomaly Detection。
10. 「新 EKS 叢集，想積極採用 Spot 而不造成節點群組流失。」→ 帶 spot 容量類型和 InstanceRequirements 的 Karpenter。

FAQ — 新解決方案成本設計常見問題

Q1：在全新解決方案上，何時選擇 Compute Savings Plan 對比 EC2 Instance Savings Plan？

預設選擇 Compute Savings Plans 作為全組織基線，因為在架構仍在演化時，彈性比額外 6 個百分點的折扣更重要。Compute SP 適用於 EC2，無論家族、大小、區域、OS 和租用模式，也覆蓋 AWS Fargate 和 AWS Lambda——所以若第四個月團隊決定將某個服務從 EC2 遷移到 Fargate，承諾會跟著工作負載走。在特定穩定高流量叢集上疊加 EC2 Instance Savings Plans，這些叢集需是你絕對確定家族不會改變的（例如有 100 個承諾 vCPU 的生產 Graviton m7g 網頁層）。EC2 Instance SP 的額外折扣是真實的，但只有工作負載特性已充分明確時，家族鎖定才值得。SAP-C02 的新解決方案成本設計幾乎總是以 Compute SP 作為基礎，並以 EC2 Instance SP 作為特定工作負載的精準工具。

Q2：如何在一年期和三年期 Savings Plans 之間，以及無預付和全額預付之間做決定？

採用梯形承諾。取你的承諾基線，分成三個部分。底部部分——你確定三年後仍然存在的絕對底板——承諾三年期。中間部分——接下來 12 到 18 個月有信心但之後可能演化的工作負載——承諾一年期。頂部部分——成長空間和實驗性工作負載——留給 On-Demand 或 Spot 不承諾。在每個部分內，選擇符合財務團隊偏好的付款選項：全額預付給出最深折扣（三年期約多 4 到 6 個百分點），適合財務長想鎖定單位經濟學且現金充裕的情況；無預付保留現金流，將折扣作為 OPEX 減少；部分預付是折衷方案。具體例子：在每月 50 萬美元的帳單上，有 60% 可預測基線，可承諾每月 18 萬三年期全額預付（若現金充裕）加每月 9 萬一年期無預付，留每月 3 萬 On-Demand 保持彈性。Savings Plans 無法取消，所以梯形配置是安全機制——若工作負載縮減，讓最短的那一層到期，不買下一輪即可。

Q3：在全新架構中，何時適合使用 Spot？何時是陷阱？

Spot 適合無狀態、冪等、水平可擴展、可中斷的工作負載。典型的適用情境：負載平衡器後方的無狀態 Web 和 API 層、批次處理（Glue、EMR、Batch）、CI/CD 執行器、渲染農場、有 PodDisruptionBudgets 和優雅終止處理的 Kubernetes 工作負載，以及帶 S3 檢查點的機器學習訓練。Spot 是陷阱，不適用於：主要資料庫（RDS、ElastiCache、MemoryDB）、單節點有狀態服務、授權需要數分鐘重新激活的工作負載，以及兩分鐘驅逐會造成可感知影響的有嚴格 p99 SLO 的客戶端同步 API。無狀態層的 Spot 新解決方案成本設計模式：MixedInstancesPolicy 搭配 20% On-Demand 基礎（保證工作負載底板）和 80% Spot，跨六個以上分散執行個體池使用 capacity-optimized 配置。將 Spot 執行個體中斷通知處理器（EventBridge → Lambda → 優雅排水）作為基礎設施的一部分加入。對於容器，ECS Fargate Spot 和帶 spot 容量類型的 EKS Karpenter，以更簡單的運營提供相同節省。絕不要將工作負載底板放在 Spot 上——那個底板屬於 Savings Plans。

Q4：我的團隊正在建立新的微服務平台，每個服務都從 S3 處理資料並寫入 DynamoDB。第一天能拉動的最重要成本槓桿是什麼？

在生產切換之前安裝 Amazon S3 和 Amazon DynamoDB 的 VPC gateway endpoints。兩個 endpoints 都是免費的，將 S3 和 DynamoDB 的流量在 AWS 骨幹網路內路由，不通過 NAT Gateway。一個每月透過 NAT Gateway 處理 100 TB S3 流量的三可用區架構，會產生約 4,500 美元的 NAT 資料處理費加 NAT 每小時費——只要在 VPC 路由表中加入 gateway endpoint，這些費用全部消失。此變更不會影響現有程式：現有的 S3 和 DynamoDB SDK 客戶端使用相同的 endpoint URL，流量透過路由表中的 gateway endpoint 條目自動路由。搭配為工作負載呼叫的頂級 AWS 服務 API 加入 interface endpoints（PrivateLink）——Amazon ECR（容器映像拉取通常是下一個最大的 NAT 花費）、AWS Secrets Manager、AWS Systems Manager、Amazon CloudWatch Logs、AWS STS、AWS KMS、Amazon SQS、Amazon SNS。Interface endpoints 按每 ENI-小時加每 GB 處理計費，但每個服務每月超過幾百 GB 後，經濟效益就會轉正。最後，在組織層級啟用 S3 Storage Lens，這樣你就能看到每個前綴的流量流向，以及下一步在哪裡最佳化。

Q5：如何為成長不確定的新 SaaS 產品設計承諾組合——我們可能在 12 個月內成長 10 倍，也可能維持平穩？

從保守的底板開始，採用梯形配置。只為你確定無論成長如何都一定存在的基線購買 Savings Plans——通常是服務每位客戶的共享平台服務（可觀測性、CI/CD 執行器、內部 API、資料平台）。將客戶可變層（Web 層、工作層）留給 On-Demand，或對其預期基線的 40 到 60% 購買一年期 Compute Savings Plan，其餘用 On-Demand 和 Spot。隨著成長曲線在前三到六個月內逐漸明朗，使用 Cost Explorer 的 Savings Plans 建議（分析過去 7、30 或 60 天的用量）再疊加一層承諾。這種梯形方法接受前幾個月在未承諾用量上多付一些，換取不過度承諾於可能不會實現的成長情境。搭配 AWS Cost Anomaly Detection 監控器，範圍設定在新產品的 Cost Category 和標籤，這樣你就能偵測費用峰值（功能發布、失控費用）和下降（減少運算的產品變更），並快速回應。不要忘記 Graviton 預設和 Spot 分散化模式——兩者都與承諾疊加，在穩定狀態下實現對比全 On-Demand 50 到 70% 的有效折扣。

Q6：Compute Optimizer 和 Cost Anomaly Detection 如何融入新解決方案成本設計工作流程？

它們關閉回饋迴路。在設計階段，你根據最佳猜測和基準測試選擇初始執行個體類型、記憶體大小和定價模型。在 14 天的生產流量之後，AWS Compute Optimizer 開始發出建議：哪些 EC2 執行個體供應過剩、哪些 ASG 可以使用不同類型、哪些 EBS 磁碟區可以縮減、哪些 Lambda 記憶體設定不理想、哪些 ECS Fargate 任務過大。每週審查中等風險、節省 20% 以上的建議，並在維護視窗期間透過 Systems Manager Automation 執行。同時，AWS Cost Anomaly Detection 監控器學習每個監控器的基線——服務、連結帳號、Cost Categories、成本分配標籤——並在統計偏差超過你的閾值時發出警示（可設定，通常 100 美元或 1,000 美元）。將這些警示路由到與值班頻道相同的 SNS 主題。典型的新解決方案成本設計在前 90 天透過 Compute Optimizer 捕捉額外 10 到 20% 的結構性節省，Cost Anomaly Detection 每季捕捉兩到三個驚訝峰值（遺忘的開發環境、設定錯誤的批次工作、資料傳輸誤路由），在超出預算之前就發現。兩個服務都是免費的。

Q7：團隊在新解決方案成本設計上最常犯的最大錯誤是什麼？如何避免？

將成本最佳化視為帳單令人警覺後才開始的第三季度專案，而不是第零天的架構承諾。最大的錯誤是在 Intel 執行個體上用 On-Demand EC2 建置，沒有標籤、沒有 endpoints、沒有 Spot、沒有承諾、沒有回饋迴路——然後三個季度後試圖在已抗拒變更的生產系統上補救安裝 Savings Plans、Graviton 和 endpoints。補救可行，但工程工作量比第一次就做對多 3 到 5 倍。避免此問題的方法是在預生產設計審查中將新解決方案成本設計作為清單項目：Graviton 預設、承諾基線已購買 Compute Savings Plan、無狀態層使用 MixedInstancesPolicy 搭配 Spot 分散化、S3 和 DynamoDB 及頂級服務 API 的 VPC endpoints、公開來源使用帶 Origin Shield 的 CloudFront、S3 Intelligent-Tiering 作為預設、透過 SCP 強制執行標籤政策、登記 Compute Optimizer、部署 Cost Anomaly Detection 監控器、啟用 S3 Storage Lens。每一項都是單一的 Terraform 模組或單一的主控台勾選框；架構師的工作是確保所有這些在生產切換之前都已上線。SAP-C02 考試測試的正是這種紀律——任何「設計成本最佳化新工作負載」問題的正確答案模式，不是單一服務，而是分層堆疊。

延伸閱讀

• AWS Well-Architected Framework Cost Optimization Pillar: https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
• AWS Savings Plans User Guide: https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
• Amazon EC2 Reserved Instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
• EC2 Spot Instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html
• Auto Scaling Groups with Multiple Instance Types and Purchase Options: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html
• Amazon ECS Fargate Capacity Providers: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html
• Karpenter for EKS: https://karpenter.sh/docs/concepts/
• AWS Graviton: https://aws.amazon.com/ec2/graviton/
• AWS Lambda Power Tuning: https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/
• Step Functions Standard vs Express: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html
• Amazon S3 Intelligent-Tiering: https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html
• AWS PrivateLink and VPC Endpoints: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html
• CloudFront Origin Shield: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html
• AWS Compute Optimizer: https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html
• AWS Cost Anomaly Detection: https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
• Amazon S3 Storage Lens: https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.html
• SAP-C02 Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-sap-pro/AWS-Certified-Solutions-Architect-Professional_Exam-Guide.pdf

相關主題

• Cost Visibility Multi-Account — 組織層級的可見性、標籤和計費模式，為新解決方案成本設計的歸因方面提供輸入。
• Continuous Improvement Cost Optimization — 現有工作負載的修復模式，補充新解決方案成本設計的全新建置焦點。
• New Solutions Performance — 快取和專用資料庫與成本決策交叉的效能架構槓桿。
• Event-Driven Serverless Architecture — 當請求密度適合按請求計費時，新解決方案成本設計所選擇的 Serverless 模式。
• Containerization ECS EKS — 容器成本模式，包括 Fargate Spot、Karpenter 和 EKS 節點群組策略。

在這個深度掌握新解決方案成本設計，你就涵蓋了 SAP-C02 約五分之一的成本面——並建立了每個生產 AWS 工作負載都應該從第一天就具備的 FinOps 紀律。