成本最佳化運算解決方案

成本最佳化運算是 SAA-C03 Task 4.2 的核心能力，要求你為每個 workload 找到能符合可用性、延遲與彈性 SLA 的最低成本運算合約及執行環境。不同於 CLF-C02 的定價模型主題只要求認識 On-Demand、Reserved Instances、Savings Plans、Spot 和 Dedicated Hosts，SAA-C03 的成本最佳化運算要求你架構整個技術堆疊：選擇採購方案、在 Auto Scaling group 中混合 Spot 與 On-Demand、遷移至 Graviton、使用 Compute Optimizer 進行 right-sizing、調校 Lambda 記憶體，並判斷何時 Fargate Spot 優於 EC2 Spot。

本學習指南完整拆解成本最佳化運算決策樹，在考試深度比較 Compute Savings Plans 與 EC2 Instance Savings Plans，剖析 Spot Instance 的架構模式（混合執行個體 ASG、中斷處理、Spot Fleet），說明 Graviton 2/3 的 40% 成本優勢，最後以 Lambda 記憶體對比執行時間的數學運算及 Compute Optimizer right-sizing 工作流程作結。讀完之後，你應該能夠看到任何 SAA-C03 成本最佳化運算情境，並立即說出正確的採購方案、執行個體系列和執行環境。

什麼是 AWS 的成本最佳化運算

成本最佳化運算是一種設計原則，而非單一服務。它結合三個同時操作的槓桿：採購方案（如何付費）、執行環境（EC2 vs 容器 vs Lambda），以及處理器系列（x86 Intel、x86 AMD 或 ARM Graviton）。SAA-C03 考試測驗這三個槓桿，而且常在同一道情境題中同時出現。

成本最佳化運算的三個槓桿

1. 採購方案 — On-Demand、Reserved Instances、Compute Savings Plans、EC2 Instance Savings Plans、Spot Instances、Dedicated Hosts、On-Demand Capacity Reservations。每種方案都在承諾期限或中斷風險與折扣之間做取捨。
2. 執行環境選擇 — EC2、ECS on EC2、ECS on Fargate、EKS on EC2、EKS on Fargate、AWS Batch、AWS Lambda。每種環境的計費粒度不同（EC2 按秒、Lambda 按毫秒、Fargate 按秒）。
3. 處理器系列 — Intel x86（預設）、AMD x86（同 vCPU 規格比 Intel 便宜約 10%）、AWS Graviton（相較同等 x86 執行個體，效能價格比高達 40%）。

為什麼成本最佳化運算主導 Domain 4

SAA-C03 的 Domain 4 佔考試 20%，而社群的考後心得一致反映，成本最佳化運算題目比 Domain 4 所有其他子主題加總還多。原因很簡單：運算是大多數 AWS 帳單中最大的支出項目，因此 AWS 期望解決方案架構師副級（Solutions Architect Associate）能在其他一切之前，先為客戶節省運算成本。SAA-C03 上每一道成本最佳化運算題，最終都是在測驗你能否在情境的可用性需求下，選出最便宜的運算方案。

白話文解釋 Cost-Optimized Compute

Cost-optimized compute 本質上就是「用最便宜的方式買到你需要的運算力」。把它想成三個不同情境的日常比喻會最快內化。

類比 1：夜市攤位的三種付法（飲食類比）

• On-Demand 就像「想吃就走進去點一碗」— 沒會員、沒儲值，現場全額付費，最貴但最自由。
• Reserved Instances 是「年度訂閱套餐」— 你承諾一年每天吃同一攤的滷肉飯，老闆給你 72% 折扣。但只能吃滷肉飯（特定 instance family），你不去錢也要付。
• Compute Savings Plans 是「夜市集點卡的每日預付額度」— 你承諾每天花 $5，整排夜市任何攤位（EC2、Fargate、Lambda）都能抵，彈性比訂閱大得多。
• EC2 Instance Savings Plans 是「限定一攤的每日預付額度」— 折扣跟 RI 一樣深（72%），但只能在同一家攤位同一種餐點規格抵。
• Spot Instances 是「打烊前的即期便當」— 便宜到 90% off，但攤主一忙就收回，只給你 2 分鐘離場。適合「現在吃沒關係、晚一點再吃也沒關係」的需求。
• Graviton 是「換成在地食材自製」— 同樣一碗麵，成本結構更便宜，客人吃起來甚至更讚（ARM 的 price-performance 比 x86 好 40%）。
• Lambda 是「只為你實際吃的每一口付費」— 不吃就不付，連座位、餐具都不租（pay-per-invocation + memory × duration）。

類比 2：計程車 vs 租車 vs 自己開車（導航類比）

• On-Demand EC2 是「路邊招計程車」— 上車就走，表跳多少付多少，沒合約。
• Reserved Instance 是「買車每月養」— 固定月費、綁三年，但每公里成本最低。
• Savings Plans 是「月租共享車服務」— 固定月費，但可以換車款（c5 → m5 → Fargate → Lambda），機動性比買車高。
• Spot Instances 是「順風車平台」— 別人反正要出發、捎你一程超便宜，但人家臨時不走你就沒車。
• Fargate 是「叫專車 app」— 不用自己保養車（不管 OS、patch），按分鐘計費，比買車彈性，比計程車便宜。
• Compute Optimizer 是「GPS 同時建議最省油路線和換車建議」— 看你平常都只載一個人，建議你把七人座換小車。
• Graviton 是「換成油電混合車」— 同樣路線，油錢省 40%。

類比 3：發電廠與電網的合約（電網類比）

• On-Demand 是「一般家庭電表」— 用多少算多少。
• Reserved Instance 是「工廠簽的固定契約容量」— 承諾每月最低用電量，電費便宜，但用不到也要付。
• Compute Savings Plan 是「跨廠區的集團用電合約」— 承諾每小時花某個額度，集團內任何機台（EC2、Fargate、Lambda）都能抵。
• Spot Instances 是「即時電力現貨市場」— 凌晨兩點離峰電便宜到不行，但尖峰一到電網就切斷你。
• Capacity Reservations 是「保留輸電通道但不簽合約」— 保證你要電時一定有，但電費按牌告價付。
• Dedicated Hosts 是「蓋自己的變電所」— 整條專線只給你用，符合合規和 BYOL 授權。
• Lambda memory tuning 是「調整每台機器的耗電設定」— 有時候開大一點反而跑得快、整體電費反而便宜。

三個類比串起來的核心觀念：On-Demand 最貴最彈性、Spot 最便宜但可能被搶走、RI 折扣深但鎖最死、Compute Savings Plans 是現代版的 RI（彈性大折扣只少一點）、Graviton 是換底層硬體省 40%、Compute Optimizer 是找出你買太大的機器、Lambda 是完全不租只買使用量。

成本最佳化運算採購決策樹

SAA-C03 Domain 4 最常被測驗的核心工具，就是成本最佳化運算採購決策樹。請按以下確切順序記憶。

七步驟決策樹

1. 這個 workload 能否容忍 2 分鐘的中斷？ 若可以 → 考慮 Spot Instances（或容器使用 Fargate Spot）。若不行 → 繼續。
2. 這個 workload 是否穩定、可預測，且預計運行 1 年以上？ 若否 → On-Demand 是底線。若是 → 繼續。
3. 你能否在整個承諾期間維持相同的 instance family、region、OS 和租用方式？ 若可以 → Standard Reserved Instance 或 EC2 Instance Savings Plan（折扣最深，高達 72%）。若不行 → 繼續。
4. 你需要彈性更換 instance family，或切換至 Fargate/Lambda 的彈性嗎？ 若是 → Compute Savings Plan（最高 66% 折扣，涵蓋 EC2 + Fargate + Lambda）。
5. 你需要在特定 AZ 保證容量，但不想綁定定價承諾？ 若是 → On-Demand Capacity Reservation（可與 Savings Plans / RIs 疊加使用）。
6. 你需要實體伺服器隔離或每插槽 BYOL 授權（SQL Server、Oracle）？ 若是 → Dedicated Hosts。
7. 你能否完全脫離 EC2？ 若 workload 是事件驅動且執行時間短 → Lambda。若已容器化但流量起伏大 → Fargate 或 Fargate Spot。

採購方案並排比較

Compute Savings Plans vs EC2 Instance Savings Plans — SAA 經典陷阱

SAA-C03 非常喜歡考 Compute Savings Plans 與 EC2 Instance Savings Plans 的差異，因為兩者都針對成本最佳化運算，但彈性範圍截然不同。讓我們逐一拆解。

Compute Savings Plan — 最大彈性

Compute Savings Plan 要求你承諾每小時的運算支出（例如 $10/小時），期限 1 或 3 年。AWS 作為回報，在以下所有服務上提供最高 66% 的 On-Demand 折扣：

• 任何 EC2 instance family（c5、m6g、r7i，任何類型）。
• 任意大小（同 family 下任意 size）。
• 任意 region（折扣隨 workload 移動）。
• 任意 OS（Linux、Windows、RHEL、SUSE）。
• 任意租用方式（共用或 dedicated instance tenancy）。
• AWS Fargate — ECS on Fargate 與 EKS on Fargate 皆適用。
• AWS Lambda — 執行時間費用（Lambda duration 定價最高折扣 17%）。

Compute Savings Plans 是 AWS 上彈性最高的承諾型成本最佳化運算方案。只要情境提及更換 instance family、混合 EC2 與 Fargate 或 Lambda、或跨 region 遷移，Compute Savings Plans 就是正確答案。

EC2 Instance Savings Plan — 折扣更深，限制更緊

EC2 Instance Savings Plan 的折扣與 Standard Reserved Instance 相當（最高 72%），但彈性不如 Compute Savings Plan。你承諾每小時支出，同時鎖定：

• 特定 EC2 instance family（例如 c5）。
• 特定 AWS region（例如 us-east-1）。

在該 family + region 的限制下，你仍可更換 size（c5.large → c5.xlarge）、OS（Linux → Windows）、AZ 和租用方式。但 EC2 Instance Savings Plan 不適用於 Fargate、Lambda 或其他 family。

涵蓋範圍一覽

折扣如何疊加及套用順序

當你同時擁有 Reserved Instances 和 Savings Plans，AWS 依下列順序套用折扣以最大化節省：

1. Zonal / Standard Reserved Instances — 優先套用至符合條件的用量。
2. EC2 Instance Savings Plans — 接著套用至剩餘符合條件的 EC2 用量。
3. Compute Savings Plans — 最後套用至剩餘的 EC2、Fargate 或 Lambda 支出。
4. On-Demand 費率 — 超出 Savings Plan 承諾額度的用量按原價計費。

這種疊加機制是為什麼成熟的 FinOps 團隊會在彈性的 Compute Savings Plan 底層鋪上 RI 作為穩固基礎——RI 涵蓋確定不會改變的精確執行個體設定，Compute Savings Plan 則吸收其餘的成本最佳化運算支出。

Spot Instances — 成本最佳化運算的架構模式

Spot Instances 為可容忍中斷的 workload 提供最高 90% 的 On-Demand 折扣。SAA-C03 不只考「什麼是 Spot？」，而是測驗你如何以 Spot 架構設計，在不犧牲可用性的前提下降低成本最佳化運算支出。

Spot 中斷處理基礎

當 AWS 需要收回 Spot 容量供 On-Demand 客戶使用時，你會透過兩個管道收到 2 分鐘的中斷通知：

• EC2 執行個體 metadata 端點 — http://169.254.169.254/latest/meta-data/spot/instance-action 會在回收開始時回傳一個時間戳記。
• Amazon EventBridge — 發出 EC2 Spot Instance Interruption Warning 事件，可路由至 Lambda、SQS 或 Step Functions。

你的執行個體可以在收到中斷通知後採取下列行動：

• 排空連線 — 在 2 分鐘視窗到期前，從 Application Load Balancer 目標群組取消註冊。
• 儲存檢查點 — 將進行中的工作刷新至 S3、DynamoDB 或 EBS。
• 優雅關閉任務 — 若執行 ECS，在 task definition 設定 stopTimeout，讓 ECS Agent 收到訊號後正常關閉。

中斷行為 — stop、hibernate、terminate

2 分鐘視窗結束後，EC2 套用你事先設定的中斷行為：

• Terminate（預設）— 執行個體移除，instance store 遺失，EBS 依 DeleteOnTermination 旗標決定保留。
• Stop — EBS-backed Spot Instances 停止（EBS 保留）。Spot 容量重新可用時可重新啟動。
• Hibernate — 停止前將 RAM 寫入根 EBS Volume。重新啟動後，程序從中斷處繼續執行。僅支援特定 instance family。

Spot Fleet 與 EC2 Fleet

Spot Fleet 或 EC2 Fleet 跨多個 instance type 和 AZ 啟動目標容量，自動分散以降低中斷的影響範圍。Fleet 類型：

• request — 一次性啟動以達到目標容量。
• maintain — 若有任何執行個體被中斷，Fleet 自動從其他資源池補充 Spot 執行個體。

ASG 混合執行個體方案 — SAA 最愛考的模式

SAA-C03 最常測驗的成本最佳化運算架構模式，就是搭配混合執行個體方案的 EC2 Auto Scaling group。你不再把 ASG 鎖定在單一採購方案和單一 instance type，而是設定：

• 多種 instance type — 例如 c5.large、c5a.large、c6i.large、c6a.large、m5.large。更多 instance 資源池意味著任何一個 Spot 資源池被中斷的機率更低。
• 多種採購方案 — OnDemandBaseCapacity 設定一個穩定的 On-Demand 執行個體基底；OnDemandPercentageAboveBaseCapacity 決定基底以上的執行個體中，On-Demand 與 Spot 各佔的比例。
• 分配策略 — price-capacity-optimized（建議）選擇價格最低且中斷機率最低的 Spot 資源池。capacity-optimized 優先考量可用性。lowest-price 純粹追求成本（風險較高）。

一個典型的成本最佳化運算 ASG 混合執行個體方案可能是：基底容量 2 個 On-Demand 執行個體、基底以上 20% 為 On-Demand、80% 為 Spot，跨 3 個 AZ 使用 5 種 instance type。相較純 On-Demand，混合節省大約可達 70%，同時為 Spot 中斷時的優雅降級維持穩定基底。

Spot workload 適用模式 — 什麼適合，什麼不適合

適合 Spot 的情境：

• Amazon EMR task node（core node 應維持 On-Demand 以確保 HDFS 持久性）。
• AWS Batch 陣列作業（中斷時自動重試）。
• CI/CD 建置 worker（GitHub Actions runner、Jenkins agent）。
• ALB 後端的無狀態 Web 層，且有足夠的超額容量吸收 Spot 驅逐。
• 有建立檢查點的 ML 訓練作業。
• 執行無狀態 Pod 的 Kubernetes worker node（搭配 Pod Disruption Budget）。

不適合 Spot 的情境：

• 有狀態的正式資料庫（RDS primary、自行管理的 PostgreSQL）。
• 沒有 Session 複寫的 Session-affinity Web 伺服器。
• 無法中斷並恢復的作業（即時交易撮合引擎）。
• Kubernetes control plane node。

Graviton — 40% 成本最佳化運算的捷徑

AWS Graviton 是 AWS 自行設計的 ARM 架構處理器系列，相較同等 x86 Intel 或 AMD 執行個體，提供高達 40% 的效能價格比優勢。Graviton 是在不需要承諾 Savings Plans 或忍受 Spot 中斷的情況下，單一最大的成本最佳化運算槓桿。

Graviton 世代 — 2、3 與 4

• Graviton 2 — instance family 後綴為 g（c6g、m6g、r6g、t4g、x2gd、i4g）。相較同等 x86 第五世代執行個體，效能價格比高達 40%。
• Graviton 3 — 第七世代 family 後綴為 g（c7g、m7g、r7g）。效能比 Graviton 2 高達 25%，意味著更深的效能價格比優勢。
• Graviton 4 — 最新世代，搭載於 r8g 及最新 c8g/m8g family。針對記憶體密集型 workload 進一步提升效能。

如何從執行個體名稱辨識 Graviton

若 EC2 執行個體名稱中，點號前有 g——例如 m6g.large、c7g.2xlarge、r7g.16xlarge、t4g.medium——就是 Graviton。g 代表 Graviton。Intel 通常是 i 或無字母（c5、m5、r5、m5n、r5i）。AMD 是 a（c5a、m5a、r5a）。

哪些 workload 適合 Graviton

Graviton 可執行任何能編譯至 ARM 的程式，現在幾乎涵蓋所有主流 workload：

• 容器 — 任何具有多架構 manifest 的 OCI 映像（大多數 AWS 官方映像已是多架構）。
• Java、Go、Python、Node.js、.NET 6+、Ruby — 皆可在 Graviton 上原生執行。
• 資料庫 — RDS 和 Aurora 支援 Graviton db.r6g / db.m6g / db.r7g 節點。
• ElastiCache — Redis 和 Memcached 支援 cache.m6g / cache.r6g。
• OpenSearch Service — 資料節點支援 r6g / m6g。
• AWS Lambda — Lambda 支援 ARM 架構；相較 x86，每毫秒成本最低可降 20%。

哪些 workload 不適合 Graviton

• 使用手動調校 x86 組語的 workload。
• 僅提供 x86 二進位檔、無 ARM 版本的專有軟體。
• 需要 Windows Server 的 Windows workload（Graviton 支援 Windows Server 2022，但工具鏈成熟度不如 Linux）。

Graviton 遷移手冊

典型的成本最佳化運算 Graviton 遷移流程如下：

1. 稽核現有支出 — 使用 AWS Compute Optimizer 查看哪些執行個體有 Graviton 建議。
2. 為容器映像建立多架構版本 — docker buildx build --platform linux/amd64,linux/arm64。
3. 在 staging 環境測試 — 以 10% 容量在 ASG 混合執行個體方案中，將 Graviton 節點與 x86 並排部署。
4. 效能基準測試 — 確認延遲與吞吐量符合預期。
5. 逐步推進 — 將 ASG 切換至 100% Graviton，或若部分 workload 仍需 x86 則保持混合。
6. 疊加 Savings Plans — Compute Savings Plans 同樣適用於 Graviton 用量，如同 x86。

使用 AWS Compute Optimizer 和 CloudWatch 進行 Right-Sizing

在購買 Savings Plan 或遷移至 Graviton 之前，投資報酬率最高的成本最佳化運算動作往往是 right-sizing——關掉過度配置的資源。SAA-C03 期望你熟悉 AWS Compute Optimizer 和 CloudWatch 這兩個工具。

AWS Compute Optimizer

AWS Compute Optimizer 是一種機器學習服務，透過分析你的資源使用率（來自 CloudWatch 指標），針對以下資源提供 right-sizing 建議：

• EC2 執行個體 — 建議縮小規格、改用 Graviton 或切換至其他 family。
• EC2 Auto Scaling group — 建議在成本與可用性之間取得平衡的 instance type 組合。
• EBS Volume — 建議改用 gp3 Volume 或縮小容量。
• AWS Lambda function — 建議在可接受執行時間下達到最低成本的記憶體配置。
• Fargate 上的 Amazon ECS 服務 — 建議適合的 task CPU/記憶體大小。
• Amazon RDS 執行個體 — 建議較小的 DB instance class。

每項 Compute Optimizer 建議包含：

• 發現分類 — Under-provisioned（配置不足）、Over-provisioned（配置過度）、Optimized（已最佳化）或 Not optimized（未最佳化）。
• 預估節省 — 每項建議的預計每月節省金額。
• 風險 — 效能退化的低、中或高風險。

Compute Optimizer 至少需要 14 天的 CloudWatch 指標歷史才能產生可靠建議。該服務對預設指標免費；啟用「增強基礎設施指標」（每資源每小時 $0.0003360215）可解鎖 93 天分析和更深度的建議。

偵測低使用率的 CloudWatch 指標

在 Compute Optimizer 推出之前，標準的成本最佳化運算 right-sizing 工作流程使用原始 CloudWatch 指標：

• CPUUtilization — 若 14 天平均值低於 20%，該執行個體可能過度配置。
• NetworkIn / NetworkOut — 確認執行個體實際上有在服務流量。
• MemoryUtilization（透過 CloudWatch Agent；非預設指標）— 若低於 40%，考慮縮小記憶體規格。
• DiskReadOps / DiskWriteOps — 對 I/O 密集型 workload，確認你付費的 IOPS 確實有被使用。

SAA-C03 常見情境是「公司有許多 CPU 持續低於 10% 的 EC2 執行個體——哪個工具可建議 right-sizing？」答案永遠是 AWS Compute Optimizer。

Right-sizing 建議類型

• 縮小規格 — c5.4xlarge → c5.xlarge（若使用率支持，可降低 75% 成本）。
• 切換 family — 若瓶頸是記憶體而非 CPU，從 c5.2xlarge → m5.2xlarge。
• 世代升級 — c5.large → c6i.large，以相同價格獲得更好效能。
• Graviton 遷移 — c5.large → c6g.large，效能價格比最高可提升 40%。
• 採購方案 — 搭配 Compute Savings Plans 達到複利節省效果。

AWS Lambda 成本最佳化 — 記憶體與執行時間的數學

AWS Lambda 是一種根本不同的成本最佳化運算模型：你按呼叫次數付費，再加上每 GB-秒的運算時間費用。公式為：

Lambda 成本 = 呼叫次數 × 請求單價 + （記憶體 GB × 執行時間秒數）× GB-秒單價

以目前定價（us-east-1、x86、2026 年 4 月）：

• 請求 — 每 100 萬次請求 $0.20。
• 執行時間 — x86 每 GB-秒 $0.0000166667；Graviton / arm64 每 GB-秒 $0.0000133334。
• Provisioned Concurrency — 保持 function 執行個體常駐的額外費用。

記憶體調校 — 反直覺的成本槓桿

Lambda 依比例分配 CPU 給記憶體：記憶體越大 = vCPU 越多 = 執行越快。這意味著若執行時間縮短的幅度超過比例，增加記憶體反而可能降低總成本。

範例：某 function 在 512 MB（0.5 GB）下執行 10 秒。每次呼叫成本 = 0.5 GB × 10 s × $0.0000166667 = $0.0000833335。

將記憶體增加至 1024 MB（1 GB）。若 function 現在執行 4 秒（因為分配了更多 CPU），成本 = 1 GB × 4 s × $0.0000166667 = $0.0000666668。記憶體加倍，成本反而降低 20%。

增加至 2048 MB（2 GB）。若執行時間降至 2.5 秒，成本 = 2 × 2.5 × $0.0000166667 = $0.0000833335 — 回到原始成本。這個 function 的最佳點是 1024 MB。

AWS Lambda Power Tuning

社群打造的 AWS Lambda Power Tuning 工具（一個從 Serverless Application Repository 部署的 Step Functions 狀態機）會在多種記憶體設定下執行你的 function，測量執行時間，並繪製成本對記憶體的曲線圖。這是 SAA 中尋找最佳 Lambda 記憶體設定的參考機制。

AWS Compute Optimizer 也根據觀察到的呼叫模式提供 Lambda 記憶體建議。

Lambda 成本最佳化運算的其他槓桿

• arm64（Graviton）架構 — 對相容 function 而言，每毫秒成本最低可降 20%。大多數執行環境免費切換。
• Compute Savings Plans — Lambda 執行時間成本最高可享 17% 折扣。
• Provisioned Concurrency 搭配 Compute Savings Plan — 對於可預測的高吞吐量 function，當使用量穩定時，Provisioned Concurrency 可能比 On-Demand Lambda 更便宜。Compute Savings Plan 適用於 Provisioned Concurrency 費用。
• 階梯定價 — Lambda 執行時間成本有量級分級；每月超過 60 億 GB-秒後，每 GB-秒費率下降。
• 避免過度配置記憶體 — 記憶體調校論點的反面；對於不受益於更多 CPU 的 I/O 密集型 function，額外記憶體是浪費的成本。

Lambda 何時在成本最佳化運算上勝過 EC2

Lambda 比 EC2 便宜的情況：

• 呼叫是突發性或不頻繁的 — 閒置時間不需付費。
• 平均使用率低於 EC2 執行個體的約 30% — 你在為大部分閒置的 EC2 付費。
• 開發運維overhead高 — Lambda 將 patch、OS 更新和容量規劃抽象化。

Lambda 在成本上輸給 EC2 的情況：

• 流量持續且高 — 持續繁忙的 workload，搭配 Compute Savings Plan 的 EC2 在規模下勝過 Lambda 按次計費的定價。
• 執行超過 15 分鐘 — Lambda 的硬性逾時限制迫使你轉向 Fargate 或 EC2。
• 記憶體需求超過 10 GB — Lambda 最大記憶體為 10,240 MB。

Fargate 和 Fargate Spot — 容器的成本最佳化運算

AWS Fargate 是 Amazon ECS 和 Amazon EKS 的無伺服器容器運算。你按分配給 task 的每 vCPU-秒和每 GB-秒記憶體付費，無需管理任何 EC2 執行個體。

Fargate 定價模型

Fargate 以每秒為單位計費兩個維度（每個 task 最低 1 分鐘）：

• vCPU — 每 vCPU 每小時 $0.04048（us-east-1、Linux、x86）。
• 記憶體 — 每 GB 每小時 $0.004445。
• Graviton（arm64）Fargate — 每秒費用比 x86 Fargate 便宜約 20%。
• 儲存 — 暫時性儲存在 20 GB 以內免費；超出部分另行計費。

Fargate Spot — 可中斷容器享 70% 折扣

Fargate Spot 在備用 Fargate 容量上執行你的 ECS task，價格最高可比 Fargate On-Demand 便宜 70%。當 AWS 需要收回容量時，Fargate Spot task 可能在收到 2 分鐘 SIGTERM 訊號後被中斷（之後 2 分鐘發出 SIGKILL）。

Fargate Spot 僅適用於 ECS on Fargate，不適用於 EKS on Fargate（截至 SAA-C03 考試指南範圍）。你透過附加至 ECS cluster 的**容量供應商（capacity provider）**設定 Fargate Spot。

容量供應商策略 — 混合 Fargate 與 Fargate Spot

典型的成本最佳化運算 ECS 容量供應商策略混合 FARGATE（On-Demand）和 FARGATE_SPOT，設定 base + weight 配置：

• FARGATE — base 為 2 個 task（永遠是 On-Demand），weight 為 1。
• FARGATE_SPOT — base 為 0，weight 為 4。

採用此策略時，前 2 個 task 永遠在 Fargate On-Demand 上執行（穩定基底）。超過此數量後，每啟動 5 個 task，1 個在 Fargate 上、4 個在 Fargate Spot 上——達到約 56% 的混合成本節省。

Fargate Spot 適用模式

Fargate Spot 適合：

• ALB 後端有健康檢查驅動替換的無狀態 API 層。
• 處理 SQS queue 並妥善處理可見性逾時的非同步 worker。
• 可重新啟動的平行 CI 作業。
• 開發和 staging 環境，70% 的節省可抵消偶發的重啟。

Fargate Spot 不適合：

• 沒有外部狀態檢查點的長時間執行有狀態 task。
• 無法優雅處理 SIGTERM 的 task。
• 不能接受延遲重啟的有硬性 SLA 的正式批次作業。

On-Demand Capacity Reservations 與 Dedicated Hosts

兩個成本最佳化運算結構位於主要採購方案折扣流程之外，但仍會出現在 SAA-C03 情境題中。

On-Demand Capacity Reservations

**On-Demand Capacity Reservation（ODCR）**在不需要定價承諾的情況下，在特定可用區域保留 EC2 容量。無論你是否使用該保留，都以 On-Demand 費率計費，但容量有保證。

ODCR 使用情境：

• 災難復原 — 保證需要時容錯移轉容量必然存在。
• 可預測的高峰事件 — 雙十一購物節、產品上線、媒體直播時段。
• 合規或可用性 SLA — 需要 AZ 層級的容量保證。

ODCR 可與 Savings Plans 和 Regional Reserved Instances 疊加——保留容量，SP/RI 在上層套用折扣。這是當你同時需要容量保證和承諾折扣時的成本最佳化運算模式。

Dedicated Hosts — BYOL 與實體隔離

Dedicated Hosts 為你的帳戶保留整台實體 EC2 伺服器。你可以看到插槽、核心和實體主機 ID。Dedicated Hosts 是以下情境的唯一選項：

• 自帶授權（BYOL） — 用於每插槽或每核心授權的軟體：Microsoft Windows Server、Microsoft SQL Server、Oracle Database、SUSE Linux Enterprise Server。
• 需要實體硬體隔離的法規合規 — 特定政府、醫療或金融法規。

Dedicated Hosts 以每主機-小時計費（非每執行個體），提供以下方案：

• On-Demand Dedicated Hosts — 按小時付費，無承諾。
• Dedicated Host Reservations — 1 或 3 年，比 On-Demand Dedicated Host 費率最高可享 70% 折扣。

Dedicated Hosts 本身並非成本最佳化工具——它們為授權和合規而存在。但在 SAA-C03 中，若情境在成本考量旁提及「每插槽授權」或「實體隔離」，Dedicated Host Reservations 就是成本最佳化運算的答案。

SAA-C03 情境模式 — 成本最佳化運算應對手冊

以下是 SAA-C03 反覆輪換出題的成本最佳化運算情境原型。學習這些對應關係。

穩定的 24/7 正式 workload，3 年內 instance family 不變

答案： 3 年 Standard Reserved Instance（全額預付）或 3 年 EC2 Instance Savings Plan，兩者最高折扣均達 72%。確定執行個體設定不會改變時，RI 略為便宜。

穩定的 24/7 workload，但可能更換 instance family、加入 Fargate 或 Lambda

答案： 3 年 Compute Savings Plan（最高 66% 折扣，涵蓋 EC2 + Fargate + Lambda）。

中斷後可重試的容錯批次 workload

答案： Spot Instances 搭配 price-capacity-optimized 分配策略和多種 instance type 的 ASG。容器則使用 ECS 上的 Fargate Spot。

穩定基底混合突發高峰

答案： ASG 混合執行個體方案，搭配 N 個執行個體的 OnDemandBaseCapacity（由 Compute Savings Plan 涵蓋）、OnDemandPercentageAboveBaseCapacity = 0%，其餘跨多種 instance type 使用 Spot。

需要在不改變採購模型的情況下降低 30-40% 運算成本

答案： 遷移至 AWS Graviton（c6g、m6g、r7g、Lambda arm64）。可與現有 Savings Plans 並行使用。

許多過大的 EC2 執行個體，不確定哪些需要縮小

答案： AWS Compute Optimizer — 根據 CloudWatch 指標提供機器學習型 right-sizing 建議。

穩定的 Lambda 呼叫量，每月 $5,000，希望獲得承諾折扣

答案： Compute Savings Plan（唯一涵蓋 Lambda 的 Savings Plan 類型）。同時將 Lambda 切換至 arm64 可額外節省約 20%。

在 us-east-1a 保證 EC2 容量作為 DR，且不需要承諾

答案： 在 us-east-1a 建立 On-Demand Capacity Reservation。

Microsoft SQL Server 搭配每插槽 BYOL 授權

答案： Dedicated Host（可選搭配 3 年 Dedicated Host Reservation 進行成本最佳化）。

短期 2 週負載測試或概念驗證

答案： On-Demand — 對於短於任何承諾期限的 workload，沒有任何採購方案比 On-Demand 更合適。

SAA-C03 必記數字與關鍵事實

• On-Demand — 基準，無折扣。
• Compute Savings Plan — 最高 66% 折扣，涵蓋 EC2 + Fargate + Lambda。
• EC2 Instance Savings Plan — 最高 72% 折扣，限一個 family + 一個 region。
• Standard Reserved Instance — 最高 72% 折扣。
• Convertible Reserved Instance — 最高 66% 折扣，可交換。
• Spot Instance — 最高 90% 折扣，2 分鐘中斷通知。
• Graviton — 相較同等 x86，效能價格比高達 40%。
• Lambda arm64 — 相較 x86，每 GB-秒成本最低可降 20%。
• Lambda Compute Savings Plan — 執行時間最高可享 17% 折扣。
• Fargate Spot — 比 Fargate On-Demand 最高可省 70%（僅限 ECS）。
• Compute Optimizer 增強指標 — 分析回溯期 93 天 vs 預設 14 天。
• Spot 中斷行為 — terminate（預設）、stop、hibernate。
• ASG 混合執行個體分配策略 — price-capacity-optimized（建議）、capacity-optimized、lowest-price。
• Savings Plans 承諾期限 — 1 年或 3 年。
• 付款方式 — All Upfront（全額預付）、Partial Upfront（部分預付）、No Upfront（無需預付）（適用於 RI、Savings Plans、Dedicated Host Reservations）。
• Dedicated Host Reservation — 比 On-Demand Dedicated Host 費率最高可省 70%。

成本最佳化運算 vs 彈性運算擴展 — 範疇邊界

SAA-C03 Task 4.2（本主題，成本最佳化運算）涵蓋運算的成本視角：如何透過選擇正確的採購方案、執行環境、處理器和規格來降低成本。Task 3.2（elastic-compute-scaling）涵蓋效能視角：EC2 instance family、放置群組、Auto Scaling 政策、Lambda 並發調校和 Batch。兩個主題在 ASG 設定上有重疊（兩者都關心擴展政策），但主要最佳化軸線不同。

若問題問「哪種 instance type 提供最佳的 GPU 價格效能比用於 ML 推論？」，那是成本最佳化運算。若問題問「哪種 instance type 提供最佳的持續運算效能？」，那是 elastic-compute-scaling。兩個主題共用 AWS Compute Optimizer 作為跨領域工具——right-sizing 同時是成本最佳化和效能調校活動。

與 CLF-C02 定價模型主題相比，後者在入門等級涵蓋相同的採購方案。SAA-C03 成本最佳化運算更為深入：ASG 混合執行個體模式、Spot Fleet 分配策略、Graviton 遷移手冊和 Lambda 記憶體-執行時間數學，都是 SAA 獨有的考點。

FAQ — 成本最佳化運算前 6 大問題

1. 什麼時候應該選擇 Compute Savings Plan 而非 Reserved Instance？

當你更重視彈性時——更換 instance family、切換 region、遷移至 Fargate、或加入 Lambda 的能力——勝過那額外 6 個百分點的折扣（72% RI vs 66% Compute SP），就選 Compute Savings Plan。只有當你完全確定 instance family、region、OS 和租用方式在整個 1 年或 3 年承諾期間都不會改變時，才選 Reserved Instance（或 EC2 Instance Savings Plan）。在混合 EC2、Fargate 和 Lambda 的現代架構中，Compute Savings Plan 幾乎總是在風險調整後的成本最佳化運算中勝出，因為它的彈性能吸收可能導致 RI 承諾擱置的遷移決策。

2. 無狀態 Web 層的最佳成本最佳化運算模式是什麼？

在 3 個 AZ 的 4 到 6 種 instance type 上，使用搭配混合執行個體方案的 EC2 Auto Scaling group，以 OnDemandBaseCapacity 作為穩定基底（由 Compute Savings Plan 涵蓋），並在基底以上使用 price-capacity-optimized Spot 分配。搭配一個能優雅進行健康檢查和排空連線的 Application Load Balancer，以及監聽 Spot 中斷通知的優雅關閉處理器。混合節省通常可達純 On-Demand 的 60 至 75%。將 instance type 遷移至 Graviton（c6g、m6g）可額外獲得 30 至 40% 的效能價格比提升。

3. 如何在 ASG 中安全地處理 Spot Instance 中斷？

三個層次：(1) 在 ASG 中設定跨多種 instance type 的混合執行個體方案，降低任何單一 Spot 資源池中斷的影響範圍；(2) 設定 price-capacity-optimized 分配策略，讓 AWS 選擇中斷機率最低的資源池；(3) 附加 lifecycle hook 或監聽 EC2 Spot Instance Interruption Warning EventBridge 事件，收到後從 ALB 目標群組取消註冊、將狀態刷新至外部儲存，並優雅退出。許多團隊也設定最低的 On-Demand 基底容量，使整個叢集完全被驅逐成為不可能。這是 SAA-C03「如何在正式環境使用 Spot？」的標準成本最佳化運算答案。

4. 為什麼增加 Lambda 記憶體有時會降低總成本？

因為 Lambda 依比例分配 CPU 給記憶體——將記憶體從 512 MB 加倍至 1024 MB，會使 vCPU 分配加倍，對 CPU 密集型工作而言，這可能使 function 執行時間縮短超過一半。由於 Lambda 執行時間成本是記憶體 × 執行時間，若記憶體加倍時執行時間縮短超過 50%，總成本就會降低。這就是為什麼 AWS Lambda Power Tuning 是建議的工具：它在多種記憶體設定下執行你的 function，並繪製實際的成本對記憶體曲線，讓你選出最低成本的配置。對於更多 CPU 沒有幫助的 I/O 密集型 function，這個邏輯不適用，額外記憶體只是浪費的成本最佳化運算支出。

5. Graviton 對正式的成本最佳化運算 workload 安全嗎？

對於絕大多數現代 workload 而言，是安全的。每個主流語言執行環境（Java 11+、Python 3.8+、Node.js 14+、Go 1.15+、Ruby 2.7+、.NET 6+、PHP 7.4+）都有原生 ARM 版本。幾乎所有 AWS 官方容器映像都是多架構的。主要開源資料庫（PostgreSQL、MySQL、Redis、MongoDB、Kafka）都提供官方 ARM 版本。遷移手冊是：使用 docker buildx 為 linux/arm64 重建映像，以 10% 容量將 Graviton 節點池部署在現有 x86 旁進行測試，完成基準測試後逐步擴大。40% 的效能價格比提升是在不改變採購方案的情況下最大的單一成本最佳化運算槓桿。Graviton 不適合的情況很少——僅限於專有的 x86-only 二進位檔、手動調校的 x86 組語，或在不支援 ARM 的舊版 Windows Server 上運行的 workload。

6. 如何在容器化的成本最佳化運算 workload 中選擇 Fargate Spot 與 EC2 Spot？

選擇 Fargate Spot（僅限 ECS）的條件：你想要零節點管理，且你的容器 workload 是無狀態的、可容忍中斷的，並且符合 Fargate 的 task 大小限制（每個 task 最多 16 vCPU、120 GB 記憶體）。你可節省最高達 Fargate On-Demand 的 70%，且閒置容量不需付費。選擇 EC2 Spot 搭配 ECS 或 EKS 受管節點群組的條件：你需要更大的 task、GPU 執行個體（Fargate 不支援 GPU）、自訂 AMI 或 kernel 功能，或更深的折扣（EC2 Spot 折扣可達 90%，相較 Fargate Spot 的 70%）。對於 EKS，Fargate Spot 不可用——必須透過受管節點群組或 Karpenter provisioner 使用 EC2 Spot 進行 Spot 型成本最佳化運算。SAA-C03 常考這個 EKS-Fargate-Spot 陷阱。

延伸閱讀

• Amazon EC2 Pricing — https://aws.amazon.com/ec2/pricing/
• Amazon EC2 Reserved Instances — https://aws.amazon.com/ec2/pricing/reserved-instances/
• AWS Savings Plans — https://aws.amazon.com/savingsplans/
• Compute Savings Plans Pricing — https://aws.amazon.com/savingsplans/compute-pricing/
• Amazon EC2 Spot Instances — https://aws.amazon.com/ec2/spot/
• Auto Scaling groups with mixed instance types — https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html
• AWS Graviton Processor — https://aws.amazon.com/ec2/graviton/
• AWS Compute Optimizer — https://aws.amazon.com/compute-optimizer/
• On-Demand Capacity Reservations — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html
• Amazon EC2 Dedicated Hosts — https://aws.amazon.com/ec2/dedicated-hosts/
• AWS Fargate Pricing — https://aws.amazon.com/fargate/pricing/
• Fargate Capacity Providers (Fargate Spot) — https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html
• AWS Lambda Pricing — https://aws.amazon.com/lambda/pricing/
• Lambda Computing Power and Memory — https://docs.aws.amazon.com/lambda/latest/operatorguide/computing-power.html
• AWS SAA-C03 Exam Guide — https://d1.awsstatic.com/training-and-certification/docs-sa-associate/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf