AWSコストを毎朝Slackで受け取る ─ 通知設計まで固定化した日次コスト通知

AWSのコスト異常は、気づくのが遅いほど高くつく。消し忘れたリソース、想定外のデータ転送、暴走したクエリ—— 月末の請求書で気づいた時には、30日分が積み上がっている。本稿では、毎朝のコストをSlackに流す小さな仕組みと、それを「読まれ続ける通知」にするための設計を解説する。

ページ構成

コスト管理の道具は揃っている。Cost Explorerを開けばいつでも見られるし、AWS Budgetsで閾値アラートも張れる。それでも異変に気づけないのは、人間が毎日ダッシュボードを開き続けることはないからである。

必要なのは「異常時だけ知らせる」ではなく、正常時も含めて毎日目に入ること。毎朝同じ時刻に金額が流れてくれば、「昨日はいつもより高い」という違和感を人間の側で検出できる。

構成要素	役割	設計上のポイント
EventBridge Scheduler	定時起動	cron式 + タイムゾーン指定（JSTの「毎朝9時半」をUTC換算せず書ける）
Lambda	Cost Explorer APIで前日分を集計	前日実績に加え、当月累計と月末着地予測も取得
SNS + Chatbot	Slackへの配送	通知基盤は既存のものに相乗りし、このモジュールでは作らない

Cost Explorer APIの呼び出しには少額の課金があるが、1日1回の集計であれば月数十円のオーダーに収まる。「コストを監視する仕組みのコスト」が問題にならない規模に設計しておくことも、この種の仕組みでは重要である。

この仕組みの本体は、実はアーキテクチャよりも通知設計にある。毎日流れる通知は、設計を誤ると数週間でミュートされる。

設計	理由
月単位でスレッドに集約する	毎日新規メッセージを流すとチャンネルが埋まり、ミュートされる。スレッドIDを「年月」から生成し、同月の通知を1スレッドにまとめる
親メッセージのサマリを毎日更新する	スレッドを開かなくても「最新日付と当月合計」がチャンネル一覧から見える
金額 + 前日比 + 月末予測を1行目に置く	スクロールせず判断できる。詳細（サービス別内訳）はその下
文面は運用者の言語で固定	通知文はモジュール側で日本語文面として固定化。呼び出し側がテンプレートを設計する余地をあえて残さない

最後の項目は割り切った設計である。通知文面をカスタマイズ可能にすると、導入時の設定項目が増え、チームごとに文面がばらつき、結局「どう書くのが正解か」の設計コストが利用者側に発生する。 文面設計まで含めてモジュールの責務とし、呼び出し側は宛先とスケジュールだけを渡せばよい形にした。

	内容
モジュールが作るもの	Lambda関数、実行スケジュール、必要最小限のインラインポリシー（Cost Explorer読み取り + SNS Publish）
呼び出し側が渡すもの	通知先SNS Topic、実行ロール、ロググループ、cron式とタイムゾーン、通貨、予測の要否

IAMロールとロググループを呼び出し側管理にしているのは、当モジュール群全体の設計方針（IAMとSecurity Group ─ 2つのアクセス制御レイヤーの設計参照）に合わせたもの。ロールの一覧性を保ちながら、このモジュールは「自分が必要とする権限だけ」をインラインポリシーで追加する。

設計判断	内容
異常検知ではなく定点観測	毎朝同じ時刻に流し、人間の違和感を検出器にする
通知設計こそ本体	月次スレッド集約・サマリ更新・文面固定で「ミュートされない通知」を作る
文面はモジュールの責務	カスタマイズ性より導入の軽さ。設定は宛先とスケジュール程度
監視の仕組み自体を安く	1日1回のAPI呼び出しに抑え、監視コストを無視できる規模に

コスト管理は「見える化」まで作って止まりがちだが、見える場所を作っても人は見に行かない。 情報の方から毎日届く構造にすることが、実際に機能するコスト管理の最短経路である。