🏷️「タグ付け忘れ」をなくす仕組みを作った — 個人・小規模チームのためのAWSガバナンス（Zennより転載）

あのリソース、誰が作ったんだっけ？

AWSを使っていると、こんな場面はないでしょうか。

• 前任者が作ったEC2が、いつの間にか動き続けている
• 「あとで消そう」と思って作ったテスト用のRDSが、そのまま残っている
• 名前を見ても、何のために作ったのか思い出せないリソースがある

一人や少人数で開発していると、こういう「迷子のリソース」は驚くほど簡単に増えていきます。誰かに怒られるわけでもないので、つい後回しになりがちです。

この記事では、そんな「迷子のリソース」を自動で見張って、安全に片付けてくれる仕組み——個人開発で作った TagWatchman というツールを、できるだけかみ砕いて紹介します。

---

そもそもタグって何？なぜ後回しになる？

AWSの「タグ」は、リソースに貼る名札のようなものです。「これは本番用」「持ち主は自分」「このプロジェクト用」といったメモを、Key=Value の形で付けておけます。

Env     = prod        （本番環境です）
Project = my-api       （このプロジェクト用です）
Owned   = backend      （バックエンドチームの持ち物です）

名札さえ付いていれば、後から見ても「これは何者か」が一目で分かります。コスト集計も、棚卸しも、ぐっと楽になります。

ところが——名札を付けるのは、忘れます。「タグを付けましょう」というルールがあっても、人は急いでいると飛ばしてしまう。これは意志の問題というより、仕組みがないと続かないという話だと思っています。

---

名札のないリソースは、地味に怖い

「名札がないくらい、別にいいのでは？」と思うかもしれません。でも、把握できていないリソースには、こんな弱点があります。

• アップデートやパッチの対象から漏れる
• 棚卸しや監査のときに見落とされる
• 何か起きても、誰の何なのか分からず対応が遅れる

つまり、「存在を把握できていないこと」そのものがリスクになります。コストの無駄になるのはもちろん、セキュリティの面でも穴になりがちです。極端な話、誰かが勝手に作ったリソースが紛れていても、名札で管理していなければ気づけません。

大きな組織なら、AWS Organizations の SCP という機能で「名札のないリソースは作らせない」と組織レベルで強制できます。でも個人開発や小規模チームには、これはちょっと大げさすぎるんですよね。

そこで、「SCPほど大掛かりじゃないけど、名札付けを実質的に強制できる」仕組みがほしくて作ったのが TagWatchman です。

---

TagWatchman は何をしてくれる？

一番のポイントは、いきなり消したりしないことです。

名札（タグ）のないリソースを見つけても、すぐに削除はしません。代わりに、こんな流れで「安全に」対応します。

名札なしリソースを検知
  ↓
まず隔離（動けない状態にする・でも消さない）
  ↓
7日間の猶予 … この間に名札を付ければ、自動で元通り
  ↓
7日たっても名札なし → 確認メールが届く
  ↓
人がメールのボタンを押して、はじめて削除

ポイントは2つあります。

ひとつは、「隔離」は「停止」でも「削除」でもないこと。たとえばEC2やRDSなら、通信だけを遮断して「悪さができない状態」にします。インスタンスを止めてしまうと再起動に時間がかかったり、削除してしまうと取り返しがつかなかったりするので、「無害化するけど中身は残す」という、いちばんダメージの少ない方法を選んでいます。

もうひとつは、削除を決めるのは必ず人間だということ。仮に名札の付け忘れ（＝誤検知）だったとしても、自動で消えることはありません。だから安心して導入できます。

名札を付ければ、自動で復活

隔離されたリソースは、正しい名札を付け直すだけで自動的に元通りになります。元の設定はちゃんと退避してあるので、手動で復旧作業をする必要はありません（一部のサービスは手動対応が必要ですが、その場合はメールで案内が届きます）。

---

サービスごとの「名札がないとどうなるか」

対応しているAWSサービスは幅広いのですが、サービスの性質によって対応の仕方が変わります。代表的なものをいくつか挙げると、こんなイメージです。

サービス	名札がないと？
EC2 / RDS	通信を遮断して隔離（7日以内に名札を付ければ自動で復旧）
Lambda	同時実行数を0にして停止（名札を付ければ自動で復旧）
S3	バケットを操作不可にして隔離（同上）
IAM ユーザー / ロール	権限を剥がして無害化（復旧は手動）
使われていない Elastic IP / NAT Gateway	条件付きですぐ削除（無駄コストの温床なので）
VPC など影響の大きいもの	削除はせず、通知でお知らせ

サーバーレス推しの方に補足すると、Lambda は「同時実行数を0にする」という形で止めます。関数を消さずに"動かないだけ"の状態にできるので、名札を付ければすぐ復活します。

このように、一律に消すのではなく、サービスごとに一番安全なやり方を選んでいるのがこだわりです。全サービスの細かい挙動は、技術寄りの記事（記事末尾にリンク）にまとめています。

---

実際に試してみると

試しに、名札（タグ）を付けずにS3バケットを作ってみました。すると1〜2分後に、こんな内容のメールが届きます。

• どのリソースか（ARN）
• どんな操作だったか（CreateBucket）
• 誰が作ったか（IAMロール）
• 足りない名札は何か
• 自動で隔離した旨
• 7日後に削除確認メールが届く旨

余談ですが、放っておいて作ったリソースがほぼリアルタイムで捕まえられて、ちゃんと隔離される——これが実環境で動くのを確認できたときは、かなり嬉しかったです。

※ S3 など一部のサービスでは、隔離時に元の設定を一旦置き換える都合で、自動復旧後に元の細かい設定だけ手動で戻す必要がある場合があります（その手順もメールに添えられます）。

---

使ってみるには

TagWatchman は オープンソース（無料） で公開しています。AWS SAM を使って、自分のAWSアカウントにそのまま導入できます。

👉 https://github.com/takada-neko/tag-watchman

導入してすぐは、実際の隔離・削除はせず「通知だけ」のお試しモードから始められます。まずは「どんなリソースが引っかかるか」を眺めてみて、慣れてから本番運用に切り替える、という流れが安心です。細かい設定の変え方や、導入の手順はリポジトリのREADMEに書いてあります。

あわせて、「自社のタグ設計をどう決めればいいか」から固めたい人向けに、詳細ガイドとすぐ使えるIaCテンプレートをまとめた**上位版（¥2,500・税込）**も用意しています。本体だけでも問題なく使えるので、こちらは必要に応じてどうぞ。

👉 上位版を見てみる

⭐ リポジトリへの Star も励みになります！

---

おわりに

個人開発や小規模チームだと、「ちゃんと管理しなきゃ」と分かっていても、つい後回しになってしまうものだと思います。TagWatchman は、その「後回し」を仕組みの側で防ぐことを狙って作りました。

「いきなり消さず、隔離してから人が判断する」という設計なので、誤検知があっても安全に運用できます。散らからないし、知らないうちに穴ができることも減らせる——そんな安心感を、小さなチームでも手軽に持てたら嬉しいです。

設計や工夫の詳細（なぜこの隔離方法にしたか、など）は、技術寄りに書いた記事があります。気になる方はこちらもどうぞ。

👉 この記事は Zenn にも掲載しています（初出: Zenn）。

👉 技術寄りの解説記事（Zenn）

フィードバックもお待ちしています！