Step 1：先把「暴增」釘在時間上（不要只看月總額）
月帳單暴增很容易誤導你，因為它把所有訊號都混在一起。你要做的是把它拆成「日」甚至「小時」的視角。 暴增通常有兩種型態：一種是某天突然跳起來（像事故或設定改動），另一種是從某天開始慢慢變陡（像流量變多或遺留資源）。
- 突然跳起來：優先懷疑變更（部署、路由、NAT、跨區、策略開關）。
- 慢慢變陡：優先懷疑成長（用量上升、資料累積、備份/日誌膨脹）。
Step 2：用「用量型態」分類，比用「服務名稱」更快
你看 Cost Explorer 時很容易被服務名稱淹沒。第一輪我更推薦用「用量型態」切： 你是在付「搬資料」、還是付「一直開著」、還是付「存著不動也算錢」、還是付「請求次數」？ 這樣分類後，你會更容易把排查方向對到正確的地方。
- 搬資料型：Data Transfer、跨 AZ/跨區、NAT 出網、對外流量突然變大
- 一直開著型：EC2/DB/Cache 長期 running、Auto Scaling 不小心放大
- 存著就算錢型：EBS / Snapshot / Log / Object storage 變大、保留策略失控
- 請求次數型：API 次數暴增、某個 job 重試、隊列/事件爆量
Step 3：先找「最大頭」，不要追每一筆小費用
第一輪只要抓大頭就好。原因很現實：小項目就算你找到原因，省下來也可能感受不大； 你把注意力放在前三名，通常就能解決 80% 的痛。
如果你看到某個項目明顯跟過去不同，問自己兩個問題就夠了： （1）它為什麼開始增加？（2）它是一次性事件還是會每天繼續？
Step 4：把「變更」跟「遺留」分開處理（動作完全不同）
成本暴增的兇手通常逃不出兩類：變更造成（今天改了某件事），或遺留造成（很久以前的東西慢慢累積）。 這兩類的處理方式差很多：
- 變更造成：回頭找變更點、對照前後差異、必要時先回滾或關閉新路徑。
- 遺留造成：找 owner、定 retention、建立清理規則，避免它繼續長。
Step 5：常見誤判（很多人就是卡在這裡）
我看過最常見的誤判是「把症狀當原因」：例如看到 EC2 費用變高就一直看 instance， 但其實是 NAT 出網或跨 AZ 把用量帶起來；或者看到 Storage 變貴就狂刪，卻沒先定保留策略，過兩週又長回來。
- 別只看服務名，先看用量型態（搬資料/一直開/存著/請求次數）。
- 先抓前三名，別被小項目拖住。
- 先判斷它會不會每天繼續（一次性 vs 持續性），動作才不會做錯。
下一步：用掃描把「可疑清單」列出來，省掉你在帳單裡迷路的時間
你當然可以靠手動排查把答案找出來，但老實說，最耗時間的是「你不知道從哪裡開始」。 掃描的價值是：把常見成本黑洞用同一個格式列出來，讓你可以直接從 top 幾項開始追，而不是盯著帳單猜。