AWS 賬單看不懂？2026 年雲成本最佳化 6 個可執行做法

AWS 賬單看不懂，通常不是賬單太複雜，而是你開啟的是付款檢視——它只告訴你這個月被扣了多少錢，卻不告訴你哪臺機器、哪個環境、哪塊磁碟在燒錢。要做 AWS 雲成本最佳化，第一步不是去申請折扣，而是把賬單切換成成本檢視：按服務、按用量型別、按標籤、按可用區一層層拆開。如果賬單是突然漲了、而你要先弄清是誰漲的，那是另一條路徑——見 AWS 賬單突然變高怎麼排查。

下面 6 個做法按「收益 ÷ 見效速度」排列，不是按理論難度。前 3 個通常就能吃掉你 30%–60% 的可最佳化支出，而且大多不需要任何架構改動。（順帶一句：折扣是賬單最佳化的其中一層，不是第一層——五家廠商的折扣機制差別很大，橫向對比見 五家雲廠商折扣機制對比。）

30 分鐘先把賬單切成成本檢視

AWS 自帶三層賬單介面，粒度完全不同。你要用的是 Cost Explorer，而不是賬單頁。

• Billing（賬單頁）：只有總額和發票。適合確認「我付了多少」，不適合找原因。
• Cost Explorer：按服務、用量型別、區域、標籤、賬號做多維拆解，支援自定義時間對比。這才是排查工具。
• Cost and Usage Report（CUR）：落到 S3 的原始明細資料，配合 Athena 可以寫 SQL 自助分析。團隊規模到「多人共用一個賬號」時，這一步最終都要做。

路徑是 Billing Console → Cost Explorer → Cost and Usage Report。前兩個免費；Cost Explorer 在前兩個賬單週期免費，之後按所跟蹤資源成本計費（量級是月支出的零點幾個百分點，最低約 $1/月，具體以官方實時報價為準）。

先找出真正吃錢的 5 個大頭

不要憑感覺最佳化。開啟 Cost Explorer，按下面四步拆，10 分鐘就能拿到一張成本大頭清單：

1. Group by 選 Service，時間範圍選上個月，看 Top 5 服務各佔多少。
2. 對佔比最高的 2–3 個服務，把 Group by 換成 Usage type（用量型別），看底是 DataTransfer-Out-Bytes、BoxUsage:m5.large 還是別的。
3. Group by 換成 Region + Availability Zone。很多賬單裡「同區域跨 AZ 流量」是一個不起眼但穩定增長的項。
4. 開啟 Cost allocation tags（成本分配標籤），按 Env、Owner、Service 分組。沒有標籤的支出會浮在 Untagged 裡，那本身就是第一優先順序問題。

拆完之後，絕大多數中小團隊會得到類似這樣的結構（以下是經驗區間，不代表任何一家公司的真實賬單）：

做法一：先關掉沒人用的東西

這是投入產出比最高的一步，也是最常被跳過的一步。很多團隊不是不知道有浪費，而是沒人真的去查。把下面的動作交給值班的人，或者寫進 IaC（Terraform/Pulumi）流水線，而不是靠人肉回憶。

• 未掛載的 EBS 卷：用 DescribeVolumes 按 State=available 過濾。卷按建立時的規格全額計費，掛不掛載都一樣。
• 閒置的 Elastic IP：未關聯任何實例的 EIP 仍按小時計費。
• 跨可用區的 NAT 閘道器：NAT Gateway 按每個可用區分別計費。多可用區架構如果在每個 AZ 都放一個，而其中一個 AZ 沒有真實流量，那是一整份按小時費用。
• 縮容到 0 的 Auto Scaling 組、已停機但未登出的 EC2、長期保留的 RDS 快照與舊 AMI。
• CloudWatch Logs 沒設保留期：日誌按 GB 長期累積，通常屬於「看一眼不心疼、半年後很貴」那一項。
• 閒置的負載均衡器，以及沒有任何快照依賴鏈的孤立快照。

做法二：給實例和磁碟瘦身

清理完之後，第二步是把仍在付全價但用不滿的資源改小。這一步的判斷標準要用指標，不要用直覺。

EC2：看 p95 和記憶體，不是平均值

開啟 Compute Optimizer（免費），它基於 CloudWatch 歷史指標給出降配、升配和遷移到新一代架構的建議；EC2 側的建議大約可以回看 12 周曆史，正好覆蓋工作日與週末的完整週期。具體怎麼按負載挑實例族和區域，見 EC2 實例型別與區域怎麼選。

• CPU 看 p95，別看平均值。p95 才 15% 的實例通常可以小一檔。
• 記憶體常常才是真瓶頸：Java / Node 服務堆配置很高但實際只用 30% 的情況非常普遍。
• 別按平均值裁：留 20%–30% 餘量。突發流量是常態，按平均值裁換來的是更高的重啟/遷移頻率和更差的 P99 延遲。
• 換機型常常比改尺寸更划算：同效能的新一代實例通常便宜 10%–25%；Graviton（ARM）在支援負載上通常便宜 20%–40%。遷移前務必確認依賴不是 x86 原生二進位制。

EBS：GP3 的 IOPS 和吞吐是可以降的

GP3 卷最常見的浪費是按峰值規格買滿。它支援在建立後單獨調整 IOPS 與吞吐（基線以上部分立即生效），所以先把規格降到基線，再按實際用量逐檔調高，比一步到位買滿便宜很多。判斷依據看 CloudWatch 的 VolumeReadOps / VolumeWriteOps 的 p95 用量。

另外兩件常被忽略的事：同一份資料被多個實例掛載時，舊實例上那份卷不會被自動合併，舊卷照樣全額計費；AWS 現在有 EBS Optimizer 會列出可最佳化的卷與預計節省，值得每月跑一次。

做法三：Savings Plans、預留實例和 Spot 怎麼選

鎖定折扣的本質是用錢換靈活性。選錯的代價不是折扣小，而是接下來一年都在為一個根本用不滿的承諾付錢。三種方式各自的適用條件，完整版見 節省計劃與預留實例怎麼選。

實際的決策規則只有四條：

1. 能用 Spot 的先全部用 Spot。 配上自動伸縮和斷點續跑，把系統設計成「隨時可被打斷」，批處理成本可以降到接近按需的一成。
2. 主力 EC2 穩定在 2–3 個實例族 → 計算類 Savings Plans 1 年。 它對實例族不敏感，比 RI 更不容易買錯，是絕大多數中小團隊的正確選擇。
3. 不要一上來就鎖 3 年。 提前退出的代價是真金白銀：賣出售餘預留實例最高可能被收取預付額約一半的手續費，Savings Plans 的兌換與退出也有條件和費用。先買 1 年驗證負載穩定，第二年再決定要不要延。
4. 承諾金額只買「穩態基線」。 把最低那部分（通常是正夜間的最低負載）算作承諾量，彈性部分繼續按需或走 Spot。買多了不會退，這是最常見的虧損點。

做法四：資料傳出（egress）：最容易出意外的一項

在賬單裡，DataTransfer-Out-Bytes 通常是增速最陡、也最沒被主動設計過的一項。根因幾乎總是同一個：請求從哪個可用區的實例出去，就從哪個可用區的出口計費，而不是走 CDN 或統一出口。完整拆解（流量其實有六個計費邊界，以及每一條怎麼省）見 AWS 流量費為什麼這麼貴。

• 同 AZ 內實例間通訊免費；同區域跨 AZ 流量按每 GB 單價計費，雙向都會產生費用。
• 跨區域流量同樣計費，量級通常比跨 AZ 高一檔。
• NAT Gateway 除按小時外還有按 GB 的資料處理費——每個 NAT 都收一次，這是 NAT 流量的雙份成本。
• 網際網路出站：靜態資源、API 響應、圖片下載都算在內，而且通常佔大頭。

做法五：把預算告警設成剎車片

最佳化不是一次性專案，是持續動作。沒有告警的賬號，三個月就能把省下的錢花回去——新增資源、測試環境、誤配都會悄悄推高賬單。AWS Budgets 的價值不在報表，而在閾值觸發時能及時通知到具體的人。

1. 進 AWS Budgets → Create budget → 選 Cost budget，範圍先鎖定你負責的那個賬號。
2. 金額設成上月實際支出的 1.1–1.2 倍，不要設成理想值。否則第一週就天天報警，最後所有人直接忽略通知。
3. 同時設 50% / 80% / 100% 三個閾值，再加一個 Actual vs Forecasted 閾值，用來抓「按當前趨勢月底會超支」。
4. 通知渠道至少兩個：郵件 + 團隊聊天（SNS → Chatbot）。只有郵件的告警在實踐中等於沒有。
5. 開啟 Cost Anomaly Detection，它基於歷史模式做異常檢測，能在賬單明顯上漲之前發現「某個資源的使用方式突然變了」。

再補一條治理動作：成本分配標籤必須在資源建立時就強制帶上。 標籤如果靠人記得打，半年後 Untagged 通常會佔總支出的 15%–30%，你就永遠說不清這部分花在了誰身上。用 Organizations 的 SCP，或者在 IaC 裡加必填標籤來兜底。

做法六：讓成本變成團隊能管的事

以上六件事做完，剩下的瓶頸通常不是技術，而是「誰有權決定花多少錢」。這一步決定最佳化能不能持續下去。

• 按環境拆賬號：生產一個賬號、測試一個賬號。測試環境最容易失控，獨立賬號讓「先關測試環境」變成一個普通操作。
• 給測試環境加自動關停：工作日 19:00 定時停機、週末全天停機。一個 20 臺實例的環境每月能省掉幾十小時按需費用，幾個人的成本差就出來了。
• 上線前過一道成本評審：新服務要有預估月支出，超過某個閾值（比如 $500/月）需要架構評審說明。這比事後省錢便宜得多。
• 每週 30 分鐘成本例會：只看三樣——總支出趨勢、Top 5 服務、本週異常項。堅持三個月，效果通常超過任何一次性的架構重構。
• 把明細做成可查詢的資料：CUR 落 S3 + Athena（按掃描量付費，單價很低），讓業務方能自助查「我這個功能花了多少錢」，而不是每次都來問架構師。

30 天執行清單

把上面的內容壓縮成一個四周節奏，按這個順序做，收益基本線性累積：

1. 第 1 周 — 看清：在 Cost Explorer 裡按 Service / Usage type / AZ 三層拆一遍，輸出一張 Top 10 成本項清單；開啟成本分配標籤。
2. 第 2 周 — 清零：刪掉未掛載卷、閒置 EIP、冗餘 NAT 閘道器、過期快照；給所有 Log Group 設 30–90 天保留期；測試環境加定時關停。
3. 第 3 周 — 瘦身：跑 Compute Optimizer 與 EBS Optimizer，按建議改小一批實例、把主力卷遷到 GP3 並下調 IOPS/吞吐、評估一次 Graviton 遷移。
4. 第 4 周 — 鎖定：按「最低穩態負載」買 1 年計算類 Savings Plans；把批處理任務遷到 Spot；配置 50/80/100% 預算告警與 Cost Anomaly Detection 通知。

做完這四周，常見結果是把可最佳化支出壓掉 25%–50%，而且很多項是一次性的、會立刻體現在下一張賬單上。真正決定長期效果的是第 4 周之後：告警有人看、標籤有人填、閒置資源有人掃。