1) 症狀：你通常會怎麼察覺到它
很少有人是因為看到 CPU 長期 1% 就立刻處理，更多是因為月結時發現： 「奇怪，我們明明沒有新增功能，怎麼 compute 這一塊一直很固定？」 Idle EC2 的症狀往往是「穩定、持久、很難被注意到」。
- 成本不暴衝，但每個月都固定一筆，久了加起來很有感。
- 團隊裡沒人敢關：怕關了出事、怕找不到 owner、怕某個批次 job 半夜會跑。
- 以為是 EC2 的錢，後來發現 EBS/快照也跟著一起在付。
- 環境越多（dev/stage/prod/feature env），遺留越容易長出來。
2) 為何會花錢：它不是「閒置才算」，而是「開著就算」
EC2 的基本邏輯很直接：只要 instance 在跑（running），不管你有沒有用到它的算力，都會計費。 所以 Idle EC2 其實有兩個面向： （1）真的沒在用但一直開著， （2）有在用但規格太大。 第二種更常見，因為大家都怕效能不夠，於是一路往上加，最後也沒有人回頭看。
3) 常見來源：閒置/過度配置通常從哪裡來
（A）臨時機器變常駐：救火用的，救完就忘了
這類最典型：某次壓測、某次事故、某次需要快速搬資料，先開一台大的； 事情結束後沒人把它降回來或關掉，久了就變成「反正一直都在」。
（B）多環境與重複部署：dev/stage 的存在感被你低估
你覺得 dev/stage 成本應該很小，但只要規格跟 prod 差不多，或是環境越疊越多， 這些成本加總起來就很可觀。尤其是「feature env」這種短期環境，最容易變成遺跡。
（C）Auto Scaling / Capacity 設太保守：上去之後不回來
有些不是「閒置」，而是「長期過量」。你把最小台數設高、或縮容條件太嚴格， 讓系統永遠維持在你以為的安全線上。安全沒錯，但你可能在買過多的安全。
（D）周邊成本一起長：EBS、Snapshot、EIP、Load Balancer
Idle EC2 常常不是只有 instance 費用。你開著它，通常也帶著磁碟、快照、甚至一些網路資源。 所以你以為你在省「一台小機器」，其實你在省一整套周邊。
4) 工具能提供什麼：掃描輸出會幫你把「猜」變成「清單」
右尺寸（right-sizing）這件事，最大的阻力通常不是技術，而是不確定： 你不知道哪台能動、哪台不能動；不知道 owner 是誰；也不知道它是不是真的閒。 掃描的目的不是替你按下關機鍵，而是先把可疑的候選清楚列出來，讓你更快做決策。
- 列出疑似閒置或過度配置的 instance（讓你先從 top 幾個看）
- 提示可能的風險與下一步（例如先觀察、先降規、或先標記 owner）
- 把「可省」變成可追蹤的工作項（不再只靠記憶）
5) 下一步：怎麼處理最不容易翻車
你不需要一上來就大砍。最穩的順序通常是： 先確認 owner → 先標記用途 → 先做低風險調整（例如排程停機或降規） → 再處理真正多餘的。 這樣你省到的錢，才不會用事故的代價還回去。
- 先從「非核心、可重建、可回滾」的環境下手（dev/stage、短期 env）。
- 能排程就先排程（下班停、週末停），通常最容易看到效果。
- 先降規再關：很多服務只需要一半規格就能穩定跑。
- 把 owner 設清楚：沒有 owner 的資源，永遠會再長回來。