EBSスナップショット肥大化『クラウド（AWS / Azure / GCP）の話⑦』
見た目、ストレージは足りている。
インスタンスも問題ない。
それでも 請求額だけが静かに増え続ける。
原因は EBS スナップショットの肥大化。
クラウド初学者が「差分だから大丈夫」で放置しがちな、気づきにくいコスト事故だ。
冒頭の一言要約
スナップショットは“無料の履歴”ではない。
消さなければ、ずっと課金され続ける。
症状（あるある）
ストレージ料金がじわじわ増える
使っていないスナップショットが大量
何のためのバックアップか分からない
削除していいか誰も判断できない
インスタンス削除後も請求が残る
月末にコストを見て青ざめる
原因と仕組み（なぜ起きるか）
EBS スナップショットは削除しない限り残る
差分保存でも、変更が多いと容量は増える
古いスナップショットが参照元になっている
自動バックアップの世代管理をしていない
検証用・一時用を放置
「使ってない＝消えている」と誤解
EBS スナップショットは
“世代チェーン”で管理される差分データ。
古いものを残すほど、
実体データは減らない。
図：スナップショット肥大の構造
[Volume]
│
[Snap1]──[Snap2]──[Snap3]──[Snap4]
↑
古いSnapshotが残ると
差分も消えない
切り分け（最短コース）
スナップショット一覧確認
所有者：自分
作成日時と用途確認
本番／検証／一時
参照元ボリューム確認
既に削除されていないか
世代数の確認
何世代残っているか
コスト内訳確認
スナップショット容量
今すぐ効く対処（テンプレ）
◆ 安全な整理手順
不要な古いスナップショットから削除
直近・必要世代は残す
いきなり全削除しない
※ 削除しても 必要な差分は自動で保持される。
◆ 推奨運用
世代数を明確化（例：7世代）
名前・タグで用途を明記
自動削除ルールを設定
恒久対策／再発防止チェックリスト
スナップショット世代数を決める
タグで用途・期限を管理
自動作成と自動削除をセットで導入
検証用は短期間で削除
インスタンス削除時に確認
月次でスナップショット棚卸し
コスト監視に含める
初期構築テンプレに組み込む
落とし穴（やりがちミス）
差分だから容量は増えないと思う
削除すると壊れると誤解
手動スナップショットを放置
用途不明のまま残す
本番と検証を混在させる
まとめ（行動指針）
EBS スナップショットは、
「消さない限り増え続ける資産」。
残す理由を決める → 世代を制限する → 定期的に削る。
この3点を回すだけで、
スナップショット由来のコスト事故は防げる。
