Talk Summary

在 AWS Summit Taiwan 2023 分享如何在 AWS 自建 K8s 叢集的架構下，透過 Spot Instance 策略與自動化成本管理工具，在維持系統高可用性的前提下極大化節省雲端支出。從 K8s 混合實例配置、Spot 上運行狀態服務的挑戰，到 RI/Saving Plan 的採購邏輯與自動化 Cost Bot 的開發，完整呈現一套可落地的成本優化實踐方案。

涵蓋主題

Spot Instance 應用策略 — K8s 叢集的混合實例配置與風險控管
狀態服務上 Spot — 在 Spot Instance 上運行 OpenSearch 的可用性保障與數據持久化
RI / Saving Plan 採購邏輯 — 標籤驅動的採購需求判定與回收期計算
Cost Bot 自動化 — 以 Python + Lambda 打造跨帳號成本管理機器人

K8s 基礎架構與 Spot Instance 應用策略

叢集配置

帳號分離 — 區分 Production 與 Non-Production 帳號，將應用程式與管理組件分開存放
混合實例模式 — Production 應用叢集以 On-Demand 為主；Management 叢集與 Non-Production 環境則大量使用 Spot Instance
管理工具整合 — 在 K8s 中整合 Prometheus、Thanos、Argo、Grafana 與 Kubecost 等工具進行監控與成本追蹤

Spot Instance 核心心法

自動化配置 — 善用 Auto Scaling Group (ASG) 與 K8s 的 Service HA 機制來抵銷 Spot 被中斷的風險
大幅節省 — 正確配置下，Spot Instance 最高可節省達 90% 的費用

進階挑戰：在 Spot Instance 上運行狀態服務（OpenSearch）

可用性保障 — 透過彈性節點管理與故障恢復機制，確保 Spot 實例中斷時叢集仍能運作
數據持久化 — 利用 K8s PVC 掛載 Amazon EBS，確保數據不隨實例中斷而消失
自動化平衡 — 利用 OpenSearch 的分片重平衡（Shard Rebalancing）機制應對節點變動

成本管理策略：RI 與 Saving Plan 的採購邏輯

煮飯比喻法

將採購邏輯簡化為：「需要吃多少（Required）」減去「剩飯有多少（Active）」，得出「需要煮多少」。

標籤驅動管理

強制要求 EC2/RDS 資源打上標籤（如 SP_Required、SP_End、RI_Required）以判定採購需求。

採購回收期計算

資源類型	回收期門檻	說明
EC2	運行超過 7.44 個月	採購 Saving Plan 才具備經濟效益
RDS	運行超過 8.76 個月	採購 RI 才具備經濟效益

自動化解決方案：AWS Cost Management Bot

技術棧

開發語言 — Python (Boto3)
執行平台 — AWS Lambda + Serverless Framework
跨帳號協作 — 支援 AWS Organization 多帳號架構，透過 IAM Assume Role 獲取資訊

自動化三大關鍵

即時通報 — 透過 Slack Bot 每天推播採購建議（如：Need to buy USD $0.564 hourly commitment）
彈性採購 — 支援 RDS RI Size Flexibility，根據最小實例單位（Instance unit）計算需求
防呆機制 — 定期掃除「該省卻忘記省（未打標籤）」與「忘記關掉（標籤已過期）」的資源

管理儀表板重點

多區域支援 — 報表應涵蓋不同 Region（如新加坡 ap-southeast-1、美國西部(加利佛尼亞北部) us-west-1）的實例狀況
利用率優化 — AWS 會優先折抵採購該 RI/SP 的帳號，因此需各別查看各帳號的採購資訊以符合帳務需求

成效與展望

採購效率提升 — 採購週期從每季縮短至每天，並提供精確的會計帳務需求資訊
未來目標 — 邁向完全自動化的 RI/Saving Plan 採購流程

[B101] 多樣性運算平台選擇與成本優化工具的成功策略

🖥️ 投影片