| name | setup-reactor |
| description | aws-cost-anomaly-slack-reactor を新規に導入するための対話ガイド。AWS Cost Anomaly Detection の通知を Slack に流したい、このリポジトリ (aws-cost-anomaly-slack-reactor) を導入したい、Cost Anomaly のメール通知を Slack に切り替えたい、SNS + Lambda + Slack の初期構築をしたい、といった要望で起動する。`/setup-reactor` で明示発火。 |
setup-reactor: aws-cost-anomaly-slack-reactor 初期セットアップ支援
このリポジトリ (aws-cost-anomaly-slack-reactor) を新規に導入する End User のための対話ガイド。既存の AWS Cost Anomaly Detection Monitor のアラートを Slack に届ける状態まで誘導する。
このガイドは「何を作るか・どこで詰まりやすいか」の知見を伝える役割に専念する。実行戦略 (どこまで自動でやるか・どこで承認を取るか) は End User の Claude Code 環境側の責務であり、このガイドでは規定しない。
重要な前提
- End User が能動的に決定するのは「Slack 通知先のチャンネル」のみ。他の項目 (Region・命名・閾値・Monitor 設定など) は既存環境/既存運用に従う、または環境依存のため End User の選好を尊重する
- 外部仕様 (Slack App manifest, AWS docs, Terraform provider, OSS の最新リリース) は時間で変わる。各フェーズで「最新仕様は一次資料 (公式 docs / 最新リリース / README) で確認してください」と End User に促すこと
- Terraform を基本に提示する。End User が CLI / Console を希望すれば翻訳して提供する
- OSS の README /
_examples/ と重複する手順はリンクで委ねる。このガイドは判断・順序・落とし穴に集中する
対話フロー (F1 → F6)
順序が重要。F5 の疎通確認が成功してから F6 の Monitor 接続に進む — 逆順だと本番の Cost Anomaly 通知が Slack に届かないまま埋もれる事故が起きうる。
F1. 前提確認フェーズ
最初の問い (Skill 起動直後にこれを聞く):
AWS Cost Anomaly Detection の Monitor は既に設定されていますか？
Monitor が既にある場合 (主想定)
- Monitor の Region と名前 を確認する
- 以降の SNS Topic / Lambda / SSM などはすべてこの Region に揃える (Cost Anomaly Detection の SNS 通知は同一 Region の SNS Topic にしか届かないことに注意。最新仕様は AWS docs を確認)
- 既存 Monitor の閾値・dimension は触らない (既存運用が決めるもの)
Monitor が無い場合 (副次対応)
- 「作成サポートを希望しますか？」と確認
- 希望する場合は
references/monitor-creation.md に従う
- 何を監視軸 (dimension) にするかは End User の運用判断。このガイドは値を提示しない
F2. Slack App 準備フェーズ
新規作成 / 既存流用の確認
Slack App は新規に作成しますか、既存の App を流用しますか？
新規作成の場合
伝えるのは「何が必要か」だけ。詳細 YAML はこのガイドに固定で持たない (時間で陳腐化するため):
- 必須 bot scopes:
app_mentions:read, chat:write, files:write
- Event Subscription (
app_mention) と Interactivity の有効化
- Request URL には Lambda Function URL を後で設定する (Function URL は F4 以降に確定するため、ここでは「あとで設定する箇所がある」とだけ伝える)
- Bot Token と Signing Secret は控えておく (F3 で SSM に投入する)
完全な manifest テンプレートは固定で書かない。最新は OSS の README.md または Slack API 公式 docs を一次資料として参照させる。Slack manifest は時間でフィールドが増減するため、Skill 内に貼り付けない方針。詳細は references/slack-app-setup.md を参照。
Slack チャンネル決定 (このガイドで End User に能動的決定を求める唯一の項目)
Cost Anomaly 通知を流す Slack チャンネル ID を決めてください。
- channel ID (
C から始まる ID) を控えておく (F3 で SSM に投入する)
- Bot を当該チャンネルに招待することも忘れない
F3. Reactor 構築フェーズ (IAM / SSM / SQS / DynamoDB)
_examples/example_aws.tf が骨格として最も近い。重複する詳細はそちらに委ね、このガイドは落とし穴だけ伝える。
詳細は references/operational-knowledge.md を参照。要点:
- SSM Secret は dummy 値 +
lifecycle.ignore_changes = [value] で投入し、実値はマネコンで入れる (tfstate に Secret を書かない運用)
- IAM: マルチアカウント運用時は
organizations:DescribeAccount を追加で許可する (_examples の最小 IAM には含まれていない)
- 命名:
_examples のリソース名は参考値。End User のプロジェクト命名規則に従う
このフェーズの apply 後、SSM パラメータが 3 つ (Bot Token, Signing Secret, Slack Channel) 存在することを確認する。dummy のままで OK。
F4. Lambda デプロイフェーズ
- bootstrap バイナリは GitHub Releases からダウンロードする運用を基本案内 (ローカルビルド前提にしない)。最新リリースバージョンは GitHub の Releases ページを毎回確認する
- lambroll で deploy。Lambda Function URL も lambroll 側で管理する想定 (Terraform 側は data source で URL を読む構成)
- Lambda Timeout は 60 秒推奨。
_examples/function.json のデフォルトは 5 秒で、初回起動や DynamoDB テーブル自動作成時に不足する場面がある
- Lambda 環境変数のキー (
SQS_QUEUE_NAME, SSMWRAP_PATHS, DYNAMODB_TABLE_NAME 等) は _examples/function.json を参照
- 初回 deploy 後、マネコンで SSM の Secret 実値 (dummy → 本物のトークン/シークレット) を入れて Lambda を再デプロイする。これを行うと Slack 側の Event Subscription Verification が通る
_examples/Makefile の lambroll コマンド例がそのまま使える。
F5. SNS Topic 構築 + 疎通確認フェーズ
このフェーズが完了するまで F6 (Monitor 接続) には進まない。
SNS Topic を作る
- F1 で確認した Region に作成
- topic policy に
costalerts.amazonaws.com の SNS:Publish を許可する (条件に aws:SourceAccount を付ける)。サンプルは references/sns-topic-policy.md を参照
- 最新の正確な許可仕様は AWS Cost Anomaly Detection の docs を一次資料で確認
SNS → Lambda の HTTPS Subscription
- Endpoint は
<Lambda Function URL>amazon-sns (URL の末尾スラッシュに注意)
- Subscription の確認 (Confirmation) は Lambda 側のコードが処理するため、Lambda が稼働状態であることが前提
疎通確認 (本フェーズの肝)
- SNS Topic に ダミーメッセージを publish して Slack に通知が届くことを確認する
- 手順は
references/smoke-test.md を参照
- これが通らないうちに F6 へ進まないこと
F6. Monitor 接続フェーズ (最終ステップ)
疎通確認 OK 後にのみ実行する。
- 既存 Cost Anomaly Monitor に Alert Subscription を追加し、subscriber を F5 で作った SNS Topic ARN に向ける
- 閾値 (絶対額
$ と変動率 %) は 既存運用に従う。このガイドは値を提示しない (環境依存)
- 最新の Alert Subscription 仕様は AWS docs を確認
この設定が完了すると、本物の Cost Anomaly が検知されたタイミングで Slack に通知が届くようになる。
ガイドが扱わないこと (スコープ外)
- 既存 Cost Anomaly Monitor の閾値・dimension 調整助言 (既存運用に従う前提)
- Slack 以外の通知先 (MS Teams, Chime 等) への拡張
- Slack Bot Token の rotation 運用
- 動作モード (自動 / 手動 / 承認フロー) — End User の Claude Code 環境側の責務
最新情報の確認が必要な箇所 (各フェーズで End User に促すこと)
| 何 | どこで確認 |
|---|
| Slack App manifest の最新フィールド | Slack API 公式 docs / OSS の README.md |
| AWS Cost Anomaly Detection の SNS 通知仕様 | AWS docs (cost-management user guide) |
SNS topic policy の costalerts.amazonaws.com 許可形式 | AWS docs |
| このOSS の最新リリースバージョン (bootstrap バイナリ) | GitHub Releases |
| Terraform AWS provider のリソース仕様 | Terraform Registry |
Skill 本体が固定値で持つには陳腐化が早すぎる情報は、上記の一次資料から都度引くこと。
reference ファイル一覧
references/operational-knowledge.md — SSM dummy 値運用、IAM 追加権限、Lambda Timeout などの実運用知見references/sns-topic-policy.md — costalerts.amazonaws.com を許可する topic policy のサンプルreferences/slack-app-setup.md — Slack App 準備の本質的構成 (manifest 詳細は一次資料に委ねる)references/monitor-creation.md — Monitor を新規に作る場合のリソース構成references/smoke-test.md — SNS への dummy publish による疎通確認手順
