Elite Cloud

AWS 成本優化分析報告

一、三大成本問題(按優先序)

🔴 問題 1:EC2 過度配置與無彈性(月支出約 $21,690,佔 45%)

• 症狀:m5.xlarge always-on,推測為 On-Demand 計價
• 核心問題:
• 未使用 Reserved Instance (RI) 或 Savings Plans,溢價約 30~50%
• always-on 表示沒有依負載自動擴縮(尤其非營業時段)
• m5 為上一代機型,m6i/m7i 性價比更高 10~20%
• 判斷依據:12,000 用戶的 SaaS 通常有明顯日夜流量差,卻 24/7 滿載,代表資源利用率偏低

🟠 問題 2:S3 缺乏 Lifecycle 管理(月支出約 $7,230,佔 15%)

• 症狀:大量舊版資料 + 未設 lifecycle policy
• 核心問題:
• 所有資料停留在 S3 Standard ($0.023/GB),即使是冷資料
• Versioning 啟用但無過期清理,舊版本永久累積
• 可能有未完成的 multipart upload 殘留
• 典型情境:60~70% 物件超過 30 天未被存取,卻支付熱儲存價格

🟡 問題 3:RDS Multi-AZ 未優化(月支出約 $10,604,佔 22%)

• 症狀:Multi-AZ 但未提及 RI 或實例規格優化
• 核心問題:
• Multi-AZ 成本為單 AZ 的 2 倍,若非 Production 環境(如 staging、dev)用 Multi-AZ 是浪費
• 未使用 RDS RI(可省 40~60%)
• 未檢視 CPU/連線數利用率,可能 over-provisioned
• 儲存可能仍用 gp2 而非更便宜的 gp3

二、三步節費建議(90 天執行路線)

Step 1:快速止血(Week 1~2,零風險)

✅ S3 Lifecycle Policy 立即建立:
   - 30 天後 → S3 Standard-IA
   - 90 天後 → S3 Glacier Instant Retrieval
   - 365 天後 → Glacier Deep Archive
   - 非當前版本 30 天後刪除
   - 啟用 Incomplete Multipart Upload 7 天清理

✅ 開啟 S3 Storage Lens 與 Cost Explorer Rightsizing Recommendations
✅ 非 Production RDS 關閉 Multi-AZ

Step 2:承諾型折扣(Week 3~4,需財務簽核)

✅ 購買 Compute Savings Plans(1年期 No Upfront):
   - 涵蓋 EC2 基準負載的 70%(保留 30% 彈性給尖峰)
   - 折扣約 27%,跨機型/區域彈性高

✅ RDS Reserved Instance(1年期 All Upfront):
   - 針對 Production Multi-AZ 實例
   - 折扣約 40%

Step 3:架構優化(Month 2~3,需工程投入)

✅ EC2 升級 m5.xlarge → m6i.xlarge 或 m7i.xlarge(同價更強或更便宜)
✅ 導入 Auto Scaling Group + ALB,設定非營業時段縮減 40% 容量
✅ 評估 Graviton (m7g) 遷移,額外省 10~20%
✅ RDS 儲存從 gp2 → gp3(直接省 20%,且效能更好)
✅ CloudFront 檢視 cache hit ratio,提升至 >90% 可降低 origin 流量

三、預估節省金額

⚠️ 關鍵假設與風險提醒

1. 假設前提:目前完全未使用 RI/SP、S3 全為 Standard、無自動擴縮
2. 若已部分優化,實際節省會落在區間下緣
3. 建議先做 2 週的 CloudWatch + Cost Explorer 數據盤點,確認 EC2 實際 CPU 利用率(若 <40% 可考慮降規而非僅買 SP)
4. RI/SP 是 1~3 年承諾,購買前務必確認業務成長曲線,建議覆蓋率不超過穩定基準負載

需要的話可以再針對單一項目(例如 Savings Plans 試算或 S3 Lifecycle 詳細規則)展開深入分析。

AWS 成本優化分析報告

現況摘要

一、三大成本問題（按優先序）

🔴 問題 1：EC2 全天候運行（Always-On）缺乏彈性調度

問題核心： m5.xlarge 採用 On-Demand 按需計費，全天 24 小時運行，但 SaaS 服務通常有明顯的離峰時段（夜間、週末）。

• 12,000 名用戶不可能均勻分布於全天 24 小時
• 若未使用 Reserved Instances 或 Savings Plans，等同於為「沒人用的時間」全額付費
• 缺乏 Auto Scaling 機制，資源長期處於高配低用狀態

⚠️ 風險等級：高｜潛在浪費比例：30–50%

🟠 問題 2：RDS Multi-AZ 規格可能過度配置

問題核心： Multi-AZ 本身設計正確（生產環境必要），但常見問題在於：

• 主要讀取負載未透過 Read Replica 分流，導致主節點規格被迫拉高
• 未評估是否有開發/測試用的 RDS 實例誤開 Multi-AZ
• 未啟用 Aurora Serverless v2（適合流量波動型 SaaS 工作負載）

⚠️ 風險等級：中高｜潛在浪費比例：20–35%

🟡 問題 3：S3 舊版資料無 Lifecycle Policy

問題核心： 未設定生命週期規則，所有資料統一存放於 S3 Standard（最貴儲存層）。

• 舊版資料（假設 60 天以上未存取）不應繼續用 Standard 計費
• 未啟用 Intelligent-Tiering 或 Glacier，長尾冷資料持續燒錢
• 若有版本控管（Versioning），舊版本檔案可能靜默累積，無人察覺

⚠️ 風險等級：中｜潛在浪費比例：40–60%（針對S3費用本身）

二、三步節費建議（具體可執行）

✅ Step 1：EC2 採購策略 + Auto Scaling（第 1–2 週執行）

立即行動：

1. 評估過去 14 天 CloudWatch CPU/Network 使用率
   → 目標：找出平均使用率 < 40% 的實例

2. 穩定基礎負載 → 購買 1 年期 Compute Savings Plans
   → 相較 On-Demand 節省 30–40%，無需綁定特定機型

3. 離峰時段（例如每日 22:00–08:00 及週末）
   → 非核心服務啟用 Instance Scheduler 自動停機

4. 尖峰彈性需求 → 設定 Application Auto Scaling
   → 混搭 Spot Instance（適合無狀態服務，省 60–70%）

工具： AWS Compute Optimizer、Cost Explorer 右尺寸建議

✅ Step 2：RDS 讀寫分離 + 規格右尺寸（第 2–4 週執行）

立即行動：

1. 開啟 RDS Performance Insights（免費層）
   → 確認讀寫比例，若讀取 > 60% → 新增 Read Replica 分流

2. 開發/測試環境 RDS
   → 關閉 Multi-AZ → 節省 50% 該實例費用
   → 設定非上班時間自動停止（RDS 停止最長 7 天需注意自動啟動機制）

3. 評估遷移至 Aurora MySQL/PostgreSQL
   → 相同效能下成本約低 20–30% vs 傳統 RDS
   → 流量波動大時考慮 Aurora Serverless v2

✅ Step 3：S3 Lifecycle Policy 全面部署（第 1 週，1 天可完成）

立即行動（可用 Terraform / Console 快速套用）：

Lifecycle Rules 建議設定：

Standard → Standard-IA :  存取後 30 天
Standard-IA → Glacier Instant Retrieval : 90 天
Glacier → Glacier Deep Archive : 180 天
過期刪除（視業務規定） : 365 天+

額外動作：
- 若開啟 Versioning → 設定非當前版本 30 天後移至 Glacier
- 啟用 S3 Storage Lens 確認各 Bucket 實際存取熱度

費用對比：

三、預估節省金額範圍

假設條件

• EC2：目前 100% On-Demand，平均使用率約 35–45%
• RDS：含 1–2 個測試環境誤開 Multi-AZ
• S3：約 50% 資料為 90 天以上冷資料，存於 Standard

節省試算

💰 預估每月可節省

保守估計：$9,000  （節省約 18.7%）
積極優化：$14,000 （節省約 29.0%）

📌 年化節省：USD $108,000 – $168,000 執行成本（工程師工時）：估計 2–3 人週，一次性投入

執行優先時程建議

Week 1  ▶ S3 Lifecycle Policy（低風險、一次設定、立即生效）
Week 1  ▶ Cost Explorer 開啟 + Compute Optimizer 建議匯出
Week 2  ▶ EC2 Savings Plans 購買（先確認用量基線再購買）
Week 2  ▶ RDS 測試環境 Multi-AZ 關閉
Week 3  ▶ Auto Scaling Group 設定 + Instance Scheduler
Week 4  ▶ RDS Read Replica 評估與部署
Month 2 ▶ Aurora 遷移評估（需完整測試，不急於第一個月）

本報告基於所提供之帳單結構與業務描述推估，建議實際執行前以 AWS Cost Explorer 與 Compute Optimizer 原始數據做二次驗證。

AWS 成本優化分析報告

一、三大成本問題（按優先序）

🔴 問題 1：EC2 Always-On 架構低效（月成本 ~$21,690）

• 症狀：m5.xlarge 持續運行，無論業務尖峰或離峰
• 根因：缺乏自動擴展策略、無預留執行個體或 Savings Plans
• 影響度：最高（45% 成本占比 + 改善空間大）

🟠 問題 2：S3 存儲政策缺失（月成本 ~$7,230）

• 症狀：舊版資料無生命週期管理，長期存於 Standard 儲存類別
• 根因：未實施分層存儲策略，舊資料應轉移至便宜儲存類別
• 影響度：中等（15% 成本占比 + 快速見效）

🟡 問題 3：RDS Multi-AZ 過度配置（月成本 ~$10,604）

• 症狀：所有實例均 Multi-AZ，但部分非生產環境亦採用
• 根因：一刀切政策，未按業務層級區分可用性要求
• 影響度：中等（22% 成本占比，改善需謹慎）

二、三步節費建議（具體可執行）

✅ 第一步：EC2 自動擴展 + RI/Savings Plans（優先度：高）

具體措施： 1. 立即行動（0-2 週） – 盤點 EC2 使用模式，區分「必須 24/7」vs「有峰值」 – 購買 1 年期 Savings Plans（推薦比例 50-70% 尖峰負載） – 啟用 Auto Scaling Group，設定： – 最小 50% 當前執行個體數 – 尖峰時段 ±30% 彈性

1. 執行細節 “` 假設：12 台 m5.xlarge (always-on)
2. 當前月成本：12 × $0.192/hr × 730hr = $1,684/月
3. 總 EC2 預算：$21,690 → 推估實際需 15-18 台尖峰、6-8 台離峰

建議採購： • 8 台 1Y RI (@-30%，$1,180/月) • 7 台 Savings Plans (@-20%，$1,196/月) • 預留 On-Demand 彈性 (3-4 台 On-Demand) “`

1. 預期效益
2. 成本降幅：25-35%（$5,422 – $7,591/月）

✅ 第二步：S3 生命週期 + 儲存類別轉移（優先度：中）

具體措施： 1. 執行策略（1-3 週） – 掃描 S3 物件年齡分布（用 S3 Inventory） – 設定生命週期策略： 30天 → Standard-IA (-50% 成本) 90天 → Glacier (-80% 成本) 180天 → Deep Archive (-95% 成本)

1. 假設場景分析 “` 當前 S3 成本分析（月 $7,230）：
2. 存儲容量：~1,500 GB（以 $0.023/GB 計)

資料分布估計（假設）： • 30%（450GB）: 熱資料 → 保留 Standard • 40%（600GB）: 溫資料 → Standard-IA • 30%（450GB）: 冷資料 → Glacier

轉移後月成本： • Standard：450GB × $0.023 = $10.35 • Standard-IA：600GB × $0.0125 = $7.50 • Glacier：450GB × $0.004 = $1.80 → 新月成本：$19.65/GB = $29,475（原 $7,230 誤差調整） “`

1. 預期效益
2. 成本降幅：40-50%（$2,892 – $3,615/月）

✅ 第三步：RDS 優化（優先度：中-低）

具體措施（2-4 週）： 1. 分層策略 – 核心生產：保持 Multi-AZ（金融等敏感業務） – 次要生產：改為 Single-AZ + Read Replica（容量層） – 測試/開發：Single-AZ，僅工作時間啟用

1. 具體調整 “` 假設當前配置： • 2 台 Multi-AZ production (db.r5.2xlarge) • 1 台 Multi-AZ staging (db.t3.large) • 1 台 Multi-AZ 備份

優化後： • 2 台 Multi-AZ production(保留) • 1 台 Single-AZ staging (成本 -50%) • 移除備份實例 (改用自動備份) • 啟用 RDS Savings Plan “`

1. 預期效益
2. 成本降幅：15-25%（$1,591 – $2,651/月）

三、預估節省金額範圍

📊 綜合優化效果

保守估計

• 月度節省：USD $10,000 – $12,500
• 年度節省：USD $120,000 – $150,000
• 新月預算：USD $36,000 – $38,000

🎯 假設條件

1. ✓ EC2 實際使用率 50-60%（非 100% always-on）
2. ✓ S3 冷資料比例達 30-40%（合理假設）
3. ✓ RDS 無生產關鍵性約 40% 實例
4. ✓ CloudFront/其他無優化空間（保持現狀）
5. ✓ 1-2 個月實施期，無業務中斷

四、快速行動清單

建議由 FinOps/Cloud 架構師主導，分階段實施以降低風險。