1) Snapshot 成本怎麼累積？為什麼它常常變成「慢性肥胖」
EBS Snapshot 多數情況看起來不嚇人，原因是它不像 NAT 或流量費那樣跳很快。 但 Snapshot 會在你不注意的地方一直長：例行備份、測試環境、臨時快照、遷移前留一份、某次故障後留證據… 等你回頭看，已經是一堆「沒人敢刪」的歷史遺跡。
更現實的是，Snapshot 通常沒有「自然死亡」機制——除非你自己定策略、定規則、定責任， 不然它會一直在那裡，直到你某天被帳單提醒。
2) 一個好用的保留策略長什麼樣子？（不用完美，但要能落地）
我建議把 Snapshot 分成三種「性質」，然後每種只做一個簡單的保留規則。你不需要一開始就做得很細， 但你要讓團隊有一致的共識：哪些是短期、哪些是中期、哪些是長期。
（A）短期：用來救急/回滾（例如 7～14 天）
這種 Snapshot 目的很單純：今天更新出事、想回到昨天的狀態。它不是用來當「長期備份」的。 如果你短期都留一年，那通常代表你根本沒有長期策略，全部混在一起了。
（B）中期：配合變更節奏（例如 30～90 天）
有些問題是「過了兩週才發現」，例如資料被某個 job 慢慢寫壞，或某個設定改了才慢慢出問題。 這時候你要的是中期回溯能力，但同樣不需要無限留。
（C）長期：合規/稽核/特定里程碑（例如每月 1 份留 12 個月）
長期保留通常是為了合規或稽核，而不是「怕被罵」。常見的作法是做稀疏化（比如每月一份）， 讓你有歷史切片，但不會把每天都留著。
3) Checklist：你可以先用這些問題把 Snapshot 分類
- 這份 Snapshot 是自動產生的（例行備份）還是手動留下的（臨時快照）？
- 它對應的 volume / instance 還在嗎？如果已經不在，這份 Snapshot 是「有意義的保留」還是「孤兒」？
- 它有沒有清楚的命名/標籤？（例如用途、環境、owner、保留期限）
- 如果現在要還原，你知道要還原到哪裡、誰會做、需要多久嗎？
- 你的長期保留是「每天都留」還是「每月留一份」？（這兩個差很多）
4) 常見誤判：刪錯比不刪更可怕
Snapshot 的清理最怕的是「想省錢結果踩雷」。最常見的誤判是看到很多 Snapshot 就全刪， 但其中可能混著你真正需要的里程碑備份。另一種誤判是： 把 Snapshot 當成唯一備份，所以不敢刪任何一份。
- 誤判 1：看「建立時間很久」就刪（其實那份可能是某次重大遷移前的唯一回復點）。
- 誤判 2：只看 volume 不在就刪（有些 snapshot 是刻意留下來做取證/回溯）。
- 誤判 3：沒有先定「長期稀疏化」，就開始大砍（最後一定會有人說：早知道就留一份每月的）。
5) 下一步：清理順序（通常這樣做最安全）
如果你真的要動手清，建議順序是「先刪最不可能出事的」，把風險壓到最低：
- 第 1 步：先找出明顯重複、明顯沒有標籤、明顯是測試環境產生的。
- 第 2 步：把自動備份改成有 retention（例如只留 14 天），讓它不再繼續長胖。
- 第 3 步：建立「每月 1 份」的長期里程碑（或依你需求），然後才去刪「每天都留」的那坨歷史。