Step 1：先釘出暴增時間與型態（不要直接衝去看所有 instance）
你要先確認它是「某一天跳起來」還是「慢慢變陡」。跳起來通常是變更造成：部署、Auto Scaling、Instance type 改了、Spot 中斷後回到 On-Demand。 慢慢變陡常常是遺留或膨脹：磁碟變大、snapshot 越留越多、流量/請求逐步上升。
- 突然跳起來：先回頭找那天的變更、事件、或擴容。
- 慢慢變陡：先找「會每天累積」的東西：EBS、Snapshot、log、資料搬運。
Step 2：常見原因清單（按命中率排序）
（A）多跑了一份：多一台、或同一個服務跑了兩套
這是最直覺的一種：測試環境忘記關、某個 stack 重複建立、或是同一個服務在不同環境各跑一套卻沒人認領。 特徵是：費用有明顯階梯、而且從那天開始就維持在更高水平。
（B）Auto Scaling / Capacity 調整：你以為是保險，結果變成常態
你把上限拉高是為了防爆流量，但如果你的 scaling policy 或指標設錯，擴上去之後就回不來。 很多「成本異常」其實是「擴容變成日常」。
（C）Instance 規格或家族變更：小改一下，月費就差一截
有時候是有人把機器升級救火，救完沒降回來；或是改了家族/平台（例如不小心換成更貴的選項）。 這種特徵是：台數沒變，但單台成本變了。
（D）Spot 中斷/改動：原本省錢，後來默默回到 On-Demand
你原本跑 Spot 很便宜，但中斷後 fallback 到 On-Demand（或策略改了）， 成本就會突然變得像「你沒做什麼，但就是變貴」。
（E）你以為是 EC2，其實是周邊：EBS / Snapshot / Data Transfer / NAT
這種最常讓人走冤枉路：你盯著 instance 看半天，最後發現真正的大頭是磁碟容量增加、 snapshot 沒清、或流量繞路（NAT、跨 AZ/跨區）。 EC2 常常只是「載體」，錢花在它身邊。
Step 3：第一輪排查 Checklist（用這份先把範圍縮小）
- 那個暴增時間點，有沒有新增/重建 stack、或多跑一套環境？
- Auto Scaling 的 desired/max 是否被拉高？是否擴上去後不回縮？
- 台數沒變但費用變高：是否有人改了 instance type / family？
- 近期是否改了 Spot/混合策略？是否 fallback 到 On-Demand？
- EBS 容量有沒有變大？I/O 有沒有變？Snapshot 是否一路累積？
- 是否有 NAT/跨 AZ/跨區流量增加，讓你誤以為是 EC2？
Step 4：常見誤判（避免你浪費一整晚）
最常見的誤判是「只看 CPU」。CPU 低不代表省錢；很多機器是記憶體/網路型、或是備援用途。 第二個誤判是「急著縮小」：你還沒釐清是不是週期性尖峰，就把規格砍到剛好，結果一遇到尖峰就爆。 省錢當然重要，但你要先確定你省的是浪費，而不是省掉穩定性。
- 誤判 1：只看 CPU 就下結論（至少交叉看 Network / Disk / 使用週期）。
- 誤判 2：把一次性尖峰當成常態（先看 2～4 週 pattern）。
- 誤判 3：忽略周邊成本（EBS/Snapshot/Transfer/NAT）。
下一步：用掃描先列出「最可疑」的 EC2 成本來源
手動排查一定做得到，但最花時間的是：你不知道該先看哪一台、哪一個 AZ、哪一個 cost driver。 掃描的好處是先把可疑來源用一致的格式列出來，讓你直接從 top 幾項開始追，而不是在清單裡盲找。