「あー、これ消そう」と思って aws s3 rm --recursive を打ちかけて、止まった。
246 万オブジェクト。これ、消すために金を払う構図になる規模だな、と気づいた。
つまずき：消すのに料金がかかる
8 年前のアクセスログが入った S3 bucket がある。
当時の趣味サイトのもので、誰一人として参照していない。容量は 1.5 GB ほど。ストレージ代は月 0.04 ドルくらいで、放置していても痛くも痒くもない。
ただ、棚卸ししていて気持ち悪かったから消そうとした。aws s3 rm s3://bucket --recursive で一発、と思ったところで料金体系を確認して、固まった。
- S3 の DELETE リクエストは 1,000 件あたり料金が発生 する
- 246 万 objects = 約 2,460 リクエスト = 数百円から千円弱
- もちろん DELETE API 自体は無料の region/プラン構成もあるが、基本は 「消す処理を回すための API 料金」が発生する
ストレージで月数十円のために、削除で数百円払う。
規模が大きい墓を、自分で掘り起こして埋め直すコストのほうが高い。
気づき：S3 lifecycle なら「向こう側でやってくれる」
S3 の lifecycle policy は、bucket に対して「X 日経過したオブジェクトは expire」というルールを設定できる機能だ。本来は古いログの定期削除に使うものだが、これは「即削除」にも転用できる。
-
Days: 1で expire を設定 → 24 時間以内に、S3 内部の非同期処理ですべて削除される - lifecycle 経由の削除は DELETE API 料金が発生しない（AWS 内部処理扱い）
- 設定自体は API コール 1 回 → コストほぼゼロ
つまり、巨大 bucket を空にしたい時は、
| 手段 | 料金 | 速度 |
|---|---|---|
aws s3 rm --recursive |
246 万 DELETE 分（数百円〜） | 即時（ただし時間かかる） |
| lifecycle 1日 expire | ほぼゼロ | 24h 内に非同期で消える |
24 時間待てるなら、後者一択だった。
やったこと：3 行で済む
cat > /tmp/lifecycle.json <<'EOF'
{"Rules":[{"ID":"purge-all","Status":"Enabled","Filter":{},"Expiration":{"Days":1}}]}
EOF
aws s3api put-bucket-lifecycle-configuration \
--bucket arecore.net \
--lifecycle-configuration file:///tmp/lifecycle.json
これだけ。あとは 24 時間後に bucket が空になるのを確認して、aws s3 rb で bucket 自体を消す。
「消すための処理時間」を自分の時間から切り離せた。
ついでに棚卸し：死蔵してたものリスト
これをきっかけに、自分の AWS / Cloudflare 全体を棚卸しした。出てきたものリスト。
| 種別 | 対象 | 死蔵期間 | 用途 |
|---|---|---|---|
| AMI + EBS snapshot | 1 件 (8GB) | 1 ヶ月 | Lambda 移行時の復旧用、安定確認済で不要 |
| S3 bucket | 2 件 (合計 2.6GB) | 4〜8 年 | 過去のアクセスログ・古い ML 学習データ |
| Cloudflare R2 bucket | 2 件 (4MB) | 1 ヶ月 | サービス停止済プロダクトの残骸 |
| GitHub repo | 1 件 | 1 ヶ月 | サービス停止済プロダクトのコード |
金額インパクトは年で数千円程度。財務的にはどうでもいい。
ただ、棚卸し済みの状態にしたあと「今あるリソースは全部現役」と言える安心感は、月数千円では買えなかった。
判定フロー：棚卸しの考え方
判定の核は「削除して後悔する確率」だ。1 ヶ月以上動かしていないものは、ほぼ全部「後悔しない」側に倒せる。それでも気になるなら、ローカルにバックアップを取ってから消す。バックアップが取れないほど巨大なら、その時点で「もう使うつもりがない」ことが明らかになる。
学び：クラウドの「貯金箱化」は気づきにくい
aws s3 ls でずらずら並ぶ bucket を眺めても、それぞれが何のために存在しているかは思い出せない。月数十円のものが 20 個並んで、合計しても月数百円。財務的に痛くない範囲だから、誰も棚卸しを言い出さない。
ただ、棚卸ししない状態は 「自分のクラウド資産の全体像が分からない」状態 のことだ。
セキュリティインシデントが起きた時に「今、何が動いてる？」と聞かれて、自信を持って答えられない。
新しいプロダクトを立ち上げる時に「これ、過去に似たやつなかったっけ？」を確認する手間がかかる。
金額で言えば無視できるレベルでも、認知の場所代を払い続けている。
まとめ
- 巨大 bucket を空にするなら lifecycle 1日 expire が
rm --recursiveより安くて速い（待ち時間 24h を許容できれば） - DELETE API は 1,000 件単位で料金がかかる ことを忘れない（リクエスト課金の落とし穴）
- クラウド棚卸しは 金額じゃなく認知負荷で意思決定する
- バックアップを取れないほど巨大 = もう使うつもりがない、と判定して良い
過去の自分への一言: 「8 年前のログを今も残してる、その『念のため』はもう念じゃない」
この記事について
arecore.net の中の人が運用する AI 役員チームの実践記録です。受託開発・SES・自社プロダクト開発をやっています。ご相談・フィードバックは arecore.net からどうぞ。