AWSのコスト異常には気づくのにも時間がかかる

Cost Anomaly Detection (CAD) 運用の効率化について発表しました。
CADは異常を「検知」してくれるが、それが報告すべき異常か静観でいい既知パターンかという「気づき」までは人手で毎回1時間かかる。この調査ギャップにAIを差し込むのが本セッションの提案です。

EventBridge → Lambda → Cost Explorer API → Amazon Bedrock (Claude Haiku 4.5) → Teams/Slack のサーバーレス構成で、生のCADアラートを構造化された判定通知(verdict / reason / next action)に変換し、1時間を数十秒に短縮します。

AWSの既存レコメンドが効く領域にAIは不要で、AIは「検知」ではなく「解釈」に使うとよい。

Transcript

1. opsmethod #2 AWSのコスト異常は 気づくのにもコストがかかる ― 調査1時間を⾃動化する ― ⾼⾥ 渉 Classmethod, Inc.
2. ⾃⼰紹介 ⾼⾥ 渉（たかさと わたる） 2025年 クラスメソッドオペレーション株式会社 ⼊社 カスタマーサクセスエンジニア‧沖縄オフィス所属 主な経歴 - 公務員（地⽅公共団体の情報システム部⾨） - Windows Server (オンプレ) 運⽤ - インフラエンジニア - 基幹システム (SAP) の運⽤‧監視設計 - 社内向けRAGチャットボット構築 趣味 - ゲーム全般 - なんでもやりますがローグライクが好み - 最近、スト6始めました - ドラム演奏 - 他多数
3. イベントテーマとの兼ね合い 今回のイベントテーマ： × ⾃動化‧効率化 コスト削減は範囲が広いので、特に Cost Anomaly Detection (CAD) の運⽤ に絞ってお話しします コスト削減
4. 想定視聴者と今⽇のゴール WHO · 想定視聴者 こんな⽅に向けて • AWSでコスト削減したい、ノウハウが欲しい • 社内のAWS利⽤を管理‧統制していて、利⽤者の過剰利⽤に気づきたい • 既にCAD（コスト異常検出）をやってるけど、意外と時間がかかって困っている GOAL · 今⽇のゴール 持ち帰ってほしい2つ • AWSのコスト削減⽅法を⼤まかに理解する • 数字の解釈にAIを差し込めることを学ぶ
5. 今⽇のメッセージ TODAY'S MESSAGE コスト異常を 「検知する」 のは AWS がやってくれる。 でも 「気づく」 （= これが何を意味するか分かる）までは、 毎回 1時間 かかっている。 → その1時間を AI で埋める。
6. AI は「検知」ではなく「解釈」に使う 「打ち⼿」が出る領域に、AI は要らない。 AWS が出すもの 数字 いつもと違う⾦額‧サービス名‧期間。 事実の通知まで。 ⾜りないもの 意味 報告すべき異常か、静観でいい既知パターンか。 解釈‧トリアージ。 AI を差し込むレイヤー Cost Anomaly Detection の出⼒を解釈してトリアージするレイヤー こそ AI の出番。
7. おさらい: AWSのコスト削減系サービスについて サービス 役割 Compute Optimizer リソース最適化（具体的なサイズ変更レコメンド） Trusted Advisor コスト最適化チェック RI / SP レコメンド 購⼊推奨額の提⽰ Cost Anomaly Detection コスト異常検出 Budgets 予算管理と超過⾒込みの通知 {
8. Cost Anomaly Detection ( コスト異常検出 / CAD ) とは 押さえておく3点 01 / DETECT ML で普段と違うコスト変動を⾃動検知 過去のコストパターンを学習。 閾値を⾃分で書く必要がない。 03 / ALERT EventBridge / SNS でアラート発⽕ 後段のワークフローに⾃然につなげられる。 02 / FREE 設定は無料、すぐ⼊れられる 数分で導⼊完了。 コスト管理のセーフティネットとして最初に。
9. 補足: 誰に報告するかで、困るポイントは変わる 報告先 が違えば、欲しい粒度も論点も変わる。 同じ CAD アラート1件でも、報告先が変われば 強調すべき情報 も 必要な粒度 も変わる。これが調査時間を膨らませる隠れた要因。 報告対象 一番気にすること 困るポイント 求められる説明粒度 自分 / チーム内 放っておいて大丈夫か 今すぐ調査すべき？ 後回しでいい？ ざっくりで良い、判断が早く欲しい 上司 / マネージャ 説明責任が果たせるか 何が起きたか / 影響範囲 / 対応方針 1〜2行で要約 + 必要なら詳細 顧客 / 利用部門 サービス影響・追加請求はあるか どのアカウントが原因か / 責任範囲は 平易な言葉、技術用語控えめ 経営層 / 経理 月次の予算インパクト 月末着地でいくら超過するか / 類似事例 金額と期間 + 原因の一行要約 セキュリティ部門 攻撃 / 不正利用の可能性 侵害サインか、通常運用の範囲内か リスク評価、原因サービスの性質 → 構造化された判定が手元にあれば、報告先に応じて切り出しやすくなる。
10. Before — CADから⾶んでくる⽣のアラート Before：⾃動化なしの状態 / CADが異常を検知すると、こういうメールが⾶んでくる BEFORE サービス名 / Usage Type / ⾦額 / 期間は揃っている。 でも、これだけだと 「報告すべき？静観でいい？」 が分からない。 → ここから⼈間の調査が始まる。
11. CADアラートが飛んできたあと、実際にやっていること 01 Payerアカウントにログイン 請求情報の取得経路に入る 02 対象アカウントにログイン スイッチロールで該当アカウントへ 03 リソース・コスト推移を確認 Cost Explorer / リソースタブを開く 04 アカウント種別を確認 基盤 / 運用 / 提供サービス 05 過去事例・既知パターンと照合 Wiki・チケット・Slack 検索 06 報告要否を判断 → 起票文を作成 関係者への展開まで含めて完了 これが毎日のように発生すると結構辛い アラート1件で 6ステップ の調査が⾛る。
12. 「検知」と「気づき」のギャップ CAD は 「検知」 までしかやらない 。 → 残りは⼈間が埋めている。このギャップ = 調査1時間 の正体。 AWSがやってくれること ⼈間がやっていること いつもと違う数字を⾒つける この数字は報告すべき異常か？ ⾦額‧サービス名を出す 静観でいい既知パターンか？ アラートを発⽕する どう対応すべきか？
13. やってみた — 全体構成 シンプルなサーバーレス構成
14. やってみた — 全体構成 シンプルなサーバーレス構成 CADの元情報 Teams / Slack のワークフ ロー Webhook URL 過去14⽇間のコスト推移
15. Before — CADから⾶んでくる⽣のアラート Before：⾃動化なしの状態 / CADが異常を検知すると、こういうメールが⾶んでくる BEFORE サービス名 / Usage Type / ⾦額 / 期間は揃っている。 でも、これだけだと 「報告すべき？静観でいい？」 が分からない。 → ここから⼈間の調査が始まる。
16. After — Teams / Slack に届く解釈付き通知 After：同じアラートの数⼗秒後に Teams / Slack へ届く AFTER VERDICT 要対応 / 静観 の判定 REASON そう判断した理由 NEXT 推奨されるネクストアクション 1時間 → 数⼗秒 Teams / Slack を開いた瞬間に調査が終わっている状態に。
17. After — Teams / Slack に届く解釈付き通知 After：同じアラートの数⼗秒後に Teams / Slack へ届く AFTER VERDICT 要対応 / 静観 の判定 REASON そう判断した理由 NEXT 推奨されるネクストアクション 1時間 → 数⼗秒 Teams / Slack を開いた瞬間に調査が終わっている状態に。 アカウント ID
18. このパターンは他にも効く 「AWS は数字を出すが、意味は出さない 」サービスすべてに転⽤可能。 脅威検知 GuardDuty Finding が⼤量に出る。 優先度判断に時間がかかる。 セキュリティ統合 Security Hub コントロール失敗が並ぶ。 影響範囲の解釈が必要。 監視アラーム CloudWatch Alarms 閾値は超えたが、原因と対応の判 断が要る。 「検知 → 解釈 → 通知」 のテンプレートとして使い回す。 EventBridge → Lambda → 各種 API → LLM → Slack
19. 注意点 — そもそも検知できないものは扱えない 今回の⾃動化は CADが「検知できた」ことが前提です （CAD⾃体にも限界がある） / 01 ⼩額のじわじわ増加は検知されない ML が「いつもと違う」を基準にするため、緩やかな増加は異常扱いされない。 / 02 不要リソースの垂れ流しは ML が「正常」と学習してしまう 継続的なコストは正常な定常状態として吸収される。 / 03 リソースIDレベルの特定はCAD⾃体ができない 原因特定の粒度は UsageType まで。リソースIDは別途調べる必要がある。 → これらは 別の仕組み（定期コストレポート等）で補う必要がある。
20. 3つのテイクアウェイ 持ち帰っていただきたい 3つのこと。 01 AWS の 既存レコメンド が効く領域に、AI は要らない Compute Optimizer 等で⼗分な場所まで差し込まない。 02 AI は「検知」ではなく 「解釈」 に使う 気づき(=理解)までの距離を縮めるのが本質。検知は AWS に任せる。 03 「気づくまでの時間」をコスト削減の指標に加える 削減した⾦額だけでなく、判断にかかる時間も改善対象
21. THANK YOU ご清聴 ありがとうございました ·
22. APPENDIX · A1 / DEEP DIVE 入力 — EventBridge → Cost Explorer → Bedrock A1 異常 単体 ではなく、過去 14日の推移 をセットで渡す REGION us-east-1 固定 RUNTIME Python 3.12 / 60s CE API GetCostAndUsage WINDOW ~14d × DAILY EVENTBRIDGE から抽出する 5項目 account_id detail.accountId 無ければ rootCauses[0].linkedAccount service rootCauses[0].service 例: Amazon GuardDuty usage_type rootCauses[0].usageType region rootCauses[0].region total_impact impact.totalImpact · USD 制約 · CAD の EventBridge イベントは us-east-1 でのみ発行 。 Lambda・SSM も同リージョンに置く。 COST EXPLORER CALL handler.py · _get_cost_trend() python ce_client.get_cost_and_usage( TimePeriod={"Start": start_14d, "End": today}, Granularity="DAILY", Filter={"And": [ {"Dimensions": {"Key": "LINKED_ACCOUNT", "Values": [account_id]}}, {"Dimensions": {"Key": "SERVICE", "Values": [service]}}, ]}, Metrics=["UnblendedCost"], ) # → [{"date": "2026-05-01", "cost": 0.06}, //.] x14 Next · このコンテキストを プロンプト4セクション （アラート内容 / 14日推移 / 判断基準 / 出力フォーマット）に 組み立てる → 次スライド
23. APPENDIX · A2 / DEEP DIVE プロンプト — Bedrock に渡す全文 A2 4セクション構成で JSON のみ を返させる HANDLER.PY · PROMPT 全文 _analyze_with_bedrock() · prompt python f-string AWSコスト異常のトリアージを行ってください。 以下の情報を分析し、 JSON形式のみで回答してください （前後に説明文不要）。 /# アラート内容 - アカウント ID : {anomaly['account_id']} - 異常サービス : {anomaly['service']} - Usage Type : {anomaly['usage_type']} - リージョン : {anomaly['region']} - コストインパクト : ${anomaly['total_impact']:.2f} /# 過去14日コスト推移（日次） {json.dumps(daily_costs, ensure_ascii=False)} /# 判断基準 - 1日で突発的に急増 → 要対応 - 数日かけて緩やかに増加（既知パターンに近い） → 静観 - GuardDuty/S3イベントが異常に多い → 要対応 /# 出力フォーマット（ JSONのみ） { "verdict": "要対応 or 静観", "reason": "原因推定（ 1〜2文）", "resolution": "収束見込みまたは対応方針（ 1文）", "next_action": "ネクストアクション（ 1文）", "confidence": "high or medium or low" } 各セクションの狙い アラート内容 CADイベントから抽出した 5フィールドを そのまま 渡す。「何が起きたか」の事実。 14日コスト推移 CE API の戻り値を json.dumps でそのまま埋め込み。 単発スパイク vs 段階的 増加 の判別根拠。 判断基準 3つのルール（突発急増 / 緩やか増 / GuardDuty・S3 多発）を 事前共有 。 Few-shot 的に振る舞いを揃える。 出力フォーマット JSON の各キーに 1文で書け と指示。長文を予防し、 Slack 整形を安定化。 Design · 「JSON形式のみで回答」「前後に説明文不要」を 冒頭で明言 。それでも ```json ... ``` ラップが返るケー スがあるため、handler 側でも剥がす保険を入れている。 注意 · 14日推移は ensure_ascii=False でそのまま埋め込み。プロンプト長は サービスの種類と桁数 に依存（典型 1〜3KB）。
24. APPENDIX · A3 / DEEP DIVE Bedrock 呼び出しと出力 JSON A3 Claude Haiku 4.5 を converse API で呼び、JSON で受ける BEDROCK CALL handler.py · _analyze_with_bedrock() python MODEL_ID = "us.anthropic.claude-haiku-4-5" \ "-20251001-v1:0" # cross-region resp = bedrock_client.converse( modelId=MODEL_ID, messages=[{"role": "user", "content": [{"text": prompt}]}], inferenceConfig={"maxTokens": 512}, ) text = resp["output"]["message"] \ ["content"][0]["text"] Robust parsing · Claude が ```json ... ``` で包んで返すケースに備え、 コードブロックを剥がして から json.loads() 。失敗時は verdict="要確認" にフォールバック。 SLACK に投げる PAYLOAD handler.py · _post_to_slack() python emoji = "✅" if verdict/="静観" else "🚨" conf = {"high":"高 🟢", "medium":"中 🟡", "low":"低 🔴"}[confidence] payload = { # Workflow Builder 3変数（例） "title": f"{emoji} 自動調査結果 — 判定: {verdict}", "account": f"{account} / {service}", "body": f"【原因推定】 {reason}\n 【収束見込み】 {resolution}\n 【次】{next_action}", } http.request("POST", webhook, body=json.dumps(payload)) TEAMS 通知は任意 TEAMS_WEBHOOK_SSM_PATH が空ならスキップ 有効時は AdaptiveCard v1.4 · FactSet + アクションリンク HTTP クライアントは urllib3 のみ（追加依存なし）
25. APPENDIX · A4 / DEEP DIVE SAM 構成 — IAM / EventBridge / DLQ / Deploy A4 最小権限と DLQ を最初から仕込む（ SAM で 一発デプロイ） IAM · 最小権限 ce ce:GetCostAndUsage Resource: * bedrock bedrock:InvokeModel Resource: * ssm ssm:GetParameter SSM パスに限定スコープ Win · Webhook URL は SecureString で SSM 管理。Bedrock も IAM ロール完結で、 外部 API キーゼロ。 LAMBDA GLOBALS Runtime: python3.12 Timeout 60s / Memory 256MB LoggingConfig: JSON + 明示 LogGroup（保持 30日） EVENTBRIDGE + DLQ template.yaml yaml CostAnomalyRule: Type: AWS/:Events/:Rule Properties: EventPattern: source: [aws.ce] detail-type: ["Anomaly Detected"] Targets: - Arn: !GetAtt TriageFn.Arn RetryPolicy: MaximumRetryAttempts: 2 MaximumEventAgeInSeconds: 3600 DeadLetterConfig: Arn: !GetAtt TriageDLQ.Arn TriageDLQ: Type: AWS/:SQS/:Queue Properties: MessageRetentionPeriod: 1209600 # 14d CAD の EventBridge イベントは us-east-1 のみ で発行。 --region us-east-1 でデプロイ必須。 DEPLOY & 動作確認 terminal bash # 1. SSM に Webhook 登録 # + Bedrock モデル access 確認 $ ./deploy.sh # 2. SAM build / deploy $ sam build $ sam deploy /-region us-east-1 # 3. サンプルイベントで Lambda 試打 $ aws lambda invoke \ /-function-name \ cost-anomaly-triage-dev \ /-payload \ file://tests/sample_event.json \ /tmp/output.json Stack: cost-anomaly-triage SSM: /cost-anomaly-triage/slack-webhook-url テスト: tests/sample_event.json 失敗時は TriageDLQ を CloudWatch から監視