AWSのコスト異常は、気づくのが遅いほど高くつく。消し忘れたリソース、想定外のデータ転送、暴走したクエリ—— 月末の請求書で気づいた時には、30日分が積み上がっている。 本稿では、毎朝のコストをSlackに流す小さな仕組みと、それを「読まれ続ける通知」にするための設計を解説する。
1. 課題: 請求書は遅すぎ、Cost Explorerは開かれない
コスト管理の道具は揃っている。Cost Explorerを開けばいつでも見られるし、AWS Budgetsで閾値アラートも張れる。 それでも異変に気づけないのは、人間が毎日ダッシュボードを開き続けることはないからである。
必要なのは「異常時だけ知らせる」ではなく、正常時も含めて毎日目に入ること。 毎朝同じ時刻に金額が流れてくれば、「昨日はいつもより高い」という違和感を人間の側で検出できる。
2. 構成: Scheduler → Lambda → SNS → Slack
Cost Explorer APIの呼び出しには少額の課金があるが、1日1回の集計であれば月数十円のオーダーに収まる。 「コストを監視する仕組みのコスト」が問題にならない規模に設計しておくことも、この種の仕組みでは重要である。
3. 「読まれる通知」の設計
この仕組みの本体は、実はアーキテクチャよりも通知設計にある。 毎日流れる通知は、設計を誤ると数週間でミュートされる。
最後の項目は割り切った設計である。通知文面をカスタマイズ可能にすると、導入時の設定項目が増え、 チームごとに文面がばらつき、結局「どう書くのが正解か」の設計コストが利用者側に発生する。 文面設計まで含めてモジュールの責務とし、呼び出し側は宛先とスケジュールだけを渡せばよい形にした。
4. 責務分離: モジュールが作るもの、呼び出し側が渡すもの
IAMロールとロググループを呼び出し側管理にしているのは、当モジュール群全体の設計方針 （IAMとSecurity Group ─ 2つのアクセス制御レイヤーの設計参照）に合わせたもの。 ロールの一覧性を保ちながら、このモジュールは「自分が必要とする権限だけ」をインラインポリシーで追加する。
5. まとめ
コスト管理は「見える化」まで作って止まりがちだが、見える場所を作っても人は見に行かない。 情報の方から毎日届く構造にすることが、実際に機能するコスト管理の最短経路である。