Toranomon Tech Hub 第8回 S3のオブジェクトを15万件あの世に送った話

Toranomon Tech Hub 第8回 IT業界、本当にあった怖い話 での登壇資料
https://toranomon-tech-hub.connpass.com/event/395274/

1. Toranomon Tech Hub 第8回 IT業界、本当にあった怖い話 S3のオブジェクトを 15万件あの世に送った話 大嵩 洋喜 KDDIアイレット株式会社
2. アジェンダ 01 事の発端 02 発覚 ― 金曜、18時17分のアラート 03 復旧 ― 100万オブジェクトとの夜 04 原因 ― なぜ防げなかったのか 05 教訓 ― 供養に代えて
3. Profile 大嵩 洋喜 @rockyx0609 お お た け ひ ろ き KDDIアイレット株式会社 クラウド・イノベーション本部 サービスプラットフォーム事業部 経歴 2023年4月新卒入社 AWSの監視運用・構築を担当 2026 Japan All AWS Certifications Engineer 2026 Japan AWS Top Engineer(Service)
4. ブログ書いてます！ 4
5. 序章｜それは、平穏な木曜日でした
6. 舞台となったシステム CloudFront と S3 の 静的サイト まもなく役目を終える予定 お客様からの依頼 とある業務向け Web サイト。 静的コンテンツはすべて S3 バケットに格納されていた サイトは近日中に計画停止の 予定で、運用は最終盤。撤収 の準備が始まっていた 「CloudFront のログ用バケッ トの中身を削除してほしい」よ くある依頼だった 6
7. ログ削除に、ライフサイクルルールを選んだ 1 対象アカウントには S3 バケットが約 90 個。その うちログ用バケットの中身を空にする作業 2 オブジェクトが大量にあるため、直接削除ではな く S3 ライフサイクルルールによる削除を採用 3 ログ用バケット以外のすべてのバケットと誤認し てしまった。 7
8. 仕込んだルールは、三段構えだった 1日で期限切れ Expiration: Days 1 現行バージョンは1日で期限 切れ。バージョニング無効の バケットでは即完全削除 旧バージョンも 1日で削除 NoncurrentVersionExpiratio n: 1日「戻すためのデータ本 体」まで完全削除する設定 だった 削除マーカーも掃除 ExpiredObjectDeleteMarker: true すべて消えたあとには、痕跡 も残らない 8
9. 怖いポイント その1 仕込んだ夜は、何も起こらない ライフサイクルルールは即時実行ではなく、非同期 で発動する。設定を誤ってもサイトは正常に見え、 エラーも出ない。レビューも作業後確認も通り抜け た時限爆弾が、静かに時を刻み始めた。 9
10. 発覚｜金曜、 18時17分
11. その頃、本番環境では 1 CloudFront 5xx が急増 2 監視アラートが発報し、MSP からエスカ レーション。作業から約 24 時間後の検 知だった 3 削除対象は約 100 万件 静的コンテンツ・画像・処理用ファイルを 含む大量のオブジェクトに削除が実行さ れていた サイト表示不能 約 11 時間 業務サイトが閲覧できない状態に。金曜 18:17 から翌朝 05:09 まで続いた 4 約 15 万件は復元不可 バージョンの残り方によっては戻せな い。153,062 件のオブジェクトが完全に 消失した 11
12. 復旧 ― 100万オブジェクトとの夜戦 削除マーカーを消 して復元 一括復元 API は 無い メインコンテンツ を最優先 翌朝 5 時、表示 回復 バージョニングが有 効なバケットは、削除 マーカーの削除で元 のオブジェクトを復活 できる 1 件ずつ消すしかな い。100 万件のリスト を 4 分割し、並列実 行で処理を加速した ユーザーが最初に見 るページから復旧。 「何時に表示回復し たか」を報告できるこ とが信頼につながる 深夜も目視で監視を 続け、翌朝 05:00 に メインコンテンツの復 元を確認した 12
13. なぜ、15万件は戻らなかったのか 復元はマーカー頼み 旧バージョンも 削除対象 残っていたのは マーカーだけ 削除マーカーを消すと、下に 残る旧バージョンが現行に戻 る。それが今回の復元手段 だった 仕込んだルールは毎日発動 し、非現行バージョンを1日で 完全削除。復旧は時間との勝 負だった 発動に間に合わなかった 153,062 件は、マーカーの下 に何も残っていなかった 13
14. 怖いポイント その2 「バージョニング有効です」 それ、戻せますか？ バージョニングが有効でも、残っているのが最新バージョンだけな ら、消えたものは戻らない。バージョニングはバックアップではない。 「戻せるかどうか」は、消える前の設定がすべてを決めていた。 14
15. 検証｜なぜ、防げなかったのか
16. 原因は、ひとつではなかった 作業対象の誤認識 レビューをすり抜けた 気づけない削除手段 「ログバケットの中身」のはず が「それ以外の全バケット」と 取り違えた レビューは実施していたが、 対象範囲の誤りまでは検出で きなかった ライフサイクルは非同期発動 のため、作業直後の確認では 異常が見えなかった 16
17. 再発防止 対象は論理名で 特定する 切り戻し手順に 復元可否を書く 復旧手法をナ レッジ化する 監視は 最後の砦 バケット名の羅列で はなく「静的コンテ ンツ格納バケット」 のように用途で明 示し、認識を合わせ る 削除系の作業は 「戻せるのか・どう 戻すのか」を手順 書に必ず記載する ようルール化した 削除マーカー復元 や並列処理の手法 を社内共有し、次の 対応速度を上げる 今回の検知も監視 アラートから。人が 気づけない失敗を 拾う仕組みを維持 する 17
18. まとめ ― 供養 • ライフサイクルルールは、忘れた頃に発動する • バージョニングはバックアップではない • 消す作業こそ、対象の明確化と切り戻し手順を • 起こったことは仕方ないが、二度と起こらないようにアウトプットを 18
19. ご清聴ありがとうございました