クラウドは作成は簡単ですが、削除は忘れがちです。
その「忘れ」が会社の財務ガバナンスを崩壊させます。
>
この記事で扱うこと
- 実務エンジニアにとってリソース削除が単なる清掃ではない理由
- 未削除リソースが会社の財務に与える4つの構造的影響
- FinOpsの観点から見たリソースライフサイクルの意味
- 実務で即適用可能なガバナンス4つのパターン
導入 — あるインフラチーム長の月末
月末のクラウド請求書が届きます。インフラチーム長が奇妙な項目を発見します。dev-test-instance-aaron-temp-2。6ヶ月前に作成され、Aaronというエンジニアはすでに3ヶ月前に退職していました。毎月12万ウォンずつ、6ヶ月間で72万ウォンが静かに流出していました。
しかし、このような項目は一つや二つではありません。追跡してみると、部署全体のクラウド費用の約25%が出所不明、責任者不明の幽霊リソースから発生していました。
ここで私たちが直面すべき真実はこれです。
「リソース削除をしなかったこと」は清掃をしなかったのではなく、
会社の財務ガバナンスが一段階崩壊した兆候である。
実習/教育で「講義が終わったらリソースを削除しましょう」と教える本当の理由は、講義室の費用のためではなく、現場に出たそのエンジニアが会社の予算を守る人として成長しなければならないからです。
実務でリソース削除が予算管理の鍵である4つの理由
1. 予算予測の精度が崩壊する
FinOpsで最も重要な指標の一つは予算予測精度(Forecast Accuracy)です。CFOと財務チームは次四半期のクラウド支出を予測して全社予算を編成し、この予測に基づいて人材採用、設備購入、R&D投資が決定されます。
問題は、未削除リソースが毎月累積されるとコストベースライン自体が膨れ上がることです。昨年±5%の精度で予測していた部署が±25%に落ちると、財務チームはその部署のすべてのIT申請を疑い始めます。
予測精度は単なる数字ではありません。それは「この部署が自社のインフラを理解している」という信頼の尺度です。信頼を失えば予算を失います。
2. コスト責任の追跡が不可能になる
タグなしで作成されたリソース、退職者が残したリソース、どのプロジェクトに属するかわからないリソース — これらはすべて「共通費用(Shared Cost)」プールに落ちます。
共通費用が大きくなると、会社のShowback / Chargebackモデルが崩壊します。
- Showback: 「この部署がこれだけ使いました」と示すこと
- Chargeback: 「この部署がこれだけ負担してください」と請求すること
これが機能しないと、どのサービスが黒字でどのプロジェクトが赤字なのか測定できません。単位経済性(Unit Economics)分析の基盤が崩壊し、最終的には誤った事業意思決定につながります。
SaaS企業であれば、ユーザーあたりのマージンを誤って計算し、価格設定を誤り、
データ企業であれば、クエリあたりの原価を誤って算出し、損をする価格で営業します。
3. ガバナンスの信頼が崩壊し、承認ラインが長くなる
財務チームとセキュリティチームがIT部署に最も頻繁に投げかける質問は単純です。
「なぜこれだけの費用が発生したのですか？」
リソースライフサイクル管理が崩壊した組織は、この質問に答えられません。答えられないと、次の四半期に2つのことが起こります。
- 予算の自動削減
- すべてのリソース作成に事前承認を要求
2番目がより致命的です。セキュリティチームと財務チームがすべてのインスタンス作成に承認を要求し始めると、エンジニアリング速度は半分に落ち、会社全体のインフラの俊敏性が失われます。「きちんと削除する文化」がある組織だけが「迅速に作成する自由」を享受できます。
4. 直接的なコスト漏洩が累積する
最も目立つ部分ですが、実際には上記の3つに比べれば小さな問題です。ただし、累積すると決して小さくありません。
| 忘れられたリソース (1個あたり) | 時間あたりの費用 | 年間費用 |
| 未使用Elastic IP | $0.005 | 約$44 |
| アイドルNAT Gateway | $0.045 | 約$394 |
| 空のEKSコントロールプレーン | $0.10 | 約$876 |
| 忘れられたGPUインスタンス (g4dn.xlarge) | $0.526 | 約$4,608 |
| RDS db.t3.medium単独 | $0.068 | 約$596 |
100人規模のエンジニアリング組織で、1人あたりこのような残骸が平均1〜2個ずつ漂っているだけでも、年間数千万ウォンから億ウォン単位の直接的な損失が発生します。そしてこのお金は、新規採用やR&Dに使うことができたはずのお金です。
実務に適用するガバナンス4つのパターン
① タギングポリシーの強制 (Tag Enforcement)
すべてのリソースに4つのタグを必須化します。
- Owner — 責任者メールアドレス
- Project — 費用請求対象プロジェクトコード
- Environment — dev / staging / prod
- ExpireAt — 自動満了日時 (ISO 8601)
AWSはSCP(Service Control Policy)またはTag Policy、AzureはAzure Policy、GCPはOrganization Policyでタグなしリソースの作成自体を遮断します。
# Terraform — すべてのリソースにタグを強制注入
locals {
required_tags = {
Owner = var.owner
Project = var.project
Environment = var.environment
ExpireAt = var.expire_at
}
}
resource "aws_instance" "app" {
# ... 省略 ...
tags = merge(local.required_tags, {
Name = "app-server"
})
}② TTLベースの自動満了
ExpireAtタグを基準に、毎日1回Lambdaが満了したリソースを自動回収します。人が忘れてもシステムが削除します。PoC環境、学習用環境、デモ環境に特に効果的です。
③ コスト異常検知の有効化
AWS Cost Anomaly Detection、Azure Cost Management Anomaly、GCP Recommender — 費用急増を24時間以内に検知し、Slack/メールで通知します。事故が1ヶ月後ではなく翌日に発見されれば、損失は1/30に減少します。
④ アイドルリソースの週次レビュー
AWS Trusted Advisor、Compute Optimizer、Cost Explorer Rightsizingの推奨事項を毎週インフラチームが検討する習慣を作ります。「片付ける時間」をカレンダーに設定しなければ、誰も片付けません。
⚠️ 実務で最もよく見られる落とし穴
- 「私が作ったものではないから、私が削除しなくてもいい」 — 誰も削除しなければ会社が負担します。結局、全員の損害です。
- 「開発環境は小さな費用だ」 — 24時間稼働している開発クラスターが、運用環境よりも高価になる会社が意外と多いです。
- 退職者の引き継ぎでクラウド資産の漏れ — 幽霊リソースの最も一般的な原因です。人事プロセスに「保有リソース明細提出」を必ず含める必要があります。
- タグなしリソースの黙認 — 「急いで作ったから」が一度許されると、その文化は決してなくなりません。
- IaCで作成し、コンソールで削除する — 依存関係エラーで半分だけ削除され、残りは迷子になります。作成したツールで削除する必要があります。
✅ まとめ
- リソース削除は整理ではなく、財務ガバナンスの一部です
- 未削除リソースは4つの後遺症を生み出します — 予測の崩壊、責任追跡不能、ガバナンス信頼の損傷、直接的なコスト漏洩
- 実務の主要な4つのツール — タギング強制、TTL自動化、コスト異常検知、アイドル週次レビュー
- 次四半期の予算交渉で部署の立場を守る最も安価な方法は、今日使わないリソースを削除すること
講義で「実習が終わったら削除してください」と教える本当の理由は、その学習者が現場に出て会社の費用を守るエンジニアになるようにするためです。技術ではなく、運用文化の伝承です。
コメントを残す